Can ISP still detect Linux (or Qubes) if sys-whonix handles everything except the physical NIC?

[abdullah]

Hello everyone,

I am in a region where using Linux is highly unusual. The only recognized use case for Linux here is security professionals or students running Kali Linux inside a VMware VM on a Windows host. A standalone Linux system, let alone Qubes OS, would be an immediate and glaring anomaly.

To protect myself, I have already implemented the following advanced configurations in Qubes OS:

1. sys-whonix is set as the UpdatesProxy for all templates and dom0. All system updates are forced through Tor.
2. sys-whonix is set as the ClockVM for all qubes. All NTP requests go through Tor.
3. All of my AppVMs use sys-whonix as their NetVM.

The Core Issue:
Despite these settings, the sys-net qube still handles the physical network interface (Wi-Fi/Ethernet). This qube is based on a standard Linux template (Debian or Fedora), so it is responsible for building and sending the raw TCP/IP packets to the ISP.

My specific questions to the community:

1. In this scenario, can the ISP still definitively detect that the underlying OS is Linux by analyzing the TCP/IP stack fingerprint (TTL, Window Size, TCP options) of the outgoing packets sourced from sys-net?

2. Or does forcing all other activities (updates, time sync, and user traffic) through sys-whonix effectively blind the ISP, making it impossible for them to determine the exact OS, leaving them only with encrypted Tor traffic coming from sys-net without a clear OS signature?

3. If detection is still possible via the sys-net fingerprint, what is the most reliable solution in my context?

   • Modifying sys-net settings (e.g., changing TTL to 128 to mimic Windows)?
   • Adding a VPN layer (sys-vpn) between sys-net and the internet?
   • Or are there alternative approaches that could completely change the visible fingerprint at the ISP level?

Alternative Approaches I am Considering:

Instead of modifying sys-net directly, I am thinking about changing how my entire system connects to the internet:

A) Using a router in WISP mode: The router connects to the external Wi-Fi and then forwards the connection to my laptop via Ethernet or its own Wi-Fi. In this case, the ISP would see the router (likely running Linux/OpenWrt) instead of my laptop. Would this effectively hide the sys-net fingerprint, or would the router’s own Linux fingerprint still be an issue? Could installing a VPN directly on the router provide complete obfuscation?

B) Using an Android phone with USB tethering: The phone connects to Wi-Fi (or mobile data) and shares the connection with my laptop via USB cable. The ISP would see the phone (Android) instead of my laptop. Would this be a better solution in my context, since Android is a common and expected OS? And if I run a VPN directly on the phone, would that hide everything (including the fact that tethering is happening)?

Why this matters:
Even a generic “Linux” fingerprint would be highly dangerous in my region, as it does not match the expected “Kali-on-VMware” pattern. I need to know if configuring sys-whonix as the Update Proxy and ClockVM is sufficient to make the outgoing sys-net traffic blend in, or if the sys-net Linux fingerprint remains the single critical leak that must be addressed separately. Additionally, I would appreciate feedback on whether the WISP router or USB tethering approaches are viable alternatives that could eliminate the problem entirely.

Thank you for your insights.

[kuhbs]

Your post sounds a lot like you could get into reasonably serious trouble if you get caught, so I’m a bit hesitant to answer…

Can I ask in which place on gods green earth you do NOT get in trouble for running windows + vmware + kali of all things, but you DO get in trouble if you run ubuntu? I know you most likely wont want to answer, but I’ve been thinking about this for the whole day now after seeing your post and I’d die to know the answer how THIS scenario is possible anywhere lol.

Without any accountability: I think the android phone sounds best to me. Make sure the VPN includes tethering. But if ubuntu gets you 10y in jail, and qubes 20, then I’m not responsible
Use a vpn before tor, vpn looks more normal than tor. Tor makes you light up like a xmas tree to most ISPs in most countries from what I know.

[corny]

You are worried about ISP knowing you use Linux but ok with them knowing you use Tor, is that correct ? Because Tor usage is easy for ISP to see without at least something like obfs4 proxy or VPN (VPN plus Tor creates other issues)

Usually Tor usage is a greater flag than Linux. With Linux there are lots of other use cases. I game on Linux, steam deck is on Linux, lots of people use Linux to get away from Mac or windows bs

[abdullah]

Thank you for your thoughtful response, and I appreciate your honesty.

Just to clarify: the issue isn’t that using Ubuntu or Qubes is legally prohibited here. The problem is uniqueness.

In my region, the vast majority of people use Windows. The only Linux users are security professionals or students running Kali inside VMware. That’s the expected Linux pattern.

If I run Ubuntu, or Qubes, I become the only person doing that. And when you’re the only person using a certain OS on a network that is being monitored, you become trivially identifiable. Not because it’s illegal—but because it’s unique.

It’s like being the only person wearing a red shirt in a crowd of thousands wearing white. The shirt itself isn’t illegal, but everyone notices you.

That’s the core of my threat model: not the OS itself, but the anomaly it creates.

I agree with your suggestion: Android phone + VPN + Tor seems like the most natural disguise. The phone gives me a common fingerprint, the VPN hides the traffic pattern, and Tor remains hidden inside.

Thank you again for your input, and I hope this clarifies my situation.

[abdullah]

You raise an excellent point, and I want to be completely transparent.

Yes, I am concerned about the ISP knowing I use Tor. That’s a real risk. Tor is easily detectable by most ISPs unless you use bridges or VPNs. But the reality is: Tor is the only reliable, free, and widely-audited anonymity tool available. I don’t have better options.

The problem is not Tor alone, and it’s not Linux alone. The problem is the combination: Tor + Linux.

In my region:

• Tor is suspicious.
• Linux is unusual (except Kali-on-VMware).
• Tor + Linux together is a massive red flag.
• Tails or Whonix? Even worse—they scream “anonymity system.”

This is exactly why I’m trying to understand the technical details. I have already configured everything (updates, time sync, apps) to go through sys-whonix. But the core question remains:

Even with all traffic routed through sys-whonix, does the ISP still see a Linux fingerprint coming from sys-net?

Because if the ISP sees Linux + Tor traffic, that’s the exact combination I’m trying to avoid. If they see only encrypted traffic without a clear OS signature, then the setup works. If they still see Linux, then I need an additional layer (like modifying sys-net, using a router, or tethering through Android).

So my question is purely technical: does sys-net’s TCP/IP fingerprint (TTL, Window Size, options) remain visible to the ISP even when all payload traffic is routed through Tor?

Thank you again for your thoughtful engagement. This is helping me refine my understanding.

[corny]

@abdullah

So my question is purely technical: does sys-net’s TCP/IP fingerprint (TTL, Window Size, options) remain visible to the ISP even when all payload traffic is routed through Tor?

My (limited) understanding is that sys-net mostly just serves as an interface for the network card to channel data to sys-firewall (which then sends it to sys-whonix). I’m sorry, my level of understanding is not sufficient to answer with any certainty.

This guide and related discussion might provide helpful information.

Prevent Qubes OS clearnet leaks

Introduction This setup is only useful for people who want to block non-VPN / non-Tor traffic. By default, Qubes OS checks for updates of qube’s templates using running qubes themselves generating traffic through their current netvm. To some people, this can be seen as a privacy issue because queries Qubes OS’s packages repository, which immediately flag the user as a Qubes OS user. Even if you use sys-whonix or a VPN qube for all your qubes, there are 3 qubes that could leak netwo…

Perhaps you could copy your questions over to the whonix forums ? The devs over there have been very helpful with my whonix on qubes related questions.

Qubes-Whonix

[kuhbs]

dont trust the default sys-net in your case, build your own. network manager is most likely spammy (I never looked at it in detail but its network manager, maybe it calls home to statistics.network-manager .org or some nonsense, no idea).

Also as said before, qubes has this “this template needs updates” thingy, where the info is gathered by AppVMs (or DispVMs) based on that template needing updates.
So your sys-net might be trying to apt update, which would NOT go through whonix.

So my question is purely technical: does sys-net’s TCP/IP fingerprint (TTL, Window Size, options) remain visible to the ISP even when all payload traffic is routed through Tor?

You are not routing sys-net through tor (or I got your net-chain wrong).

Perhaps you could copy your questions over to the whonix forums ? The devs over there have been very helpful with my whonix on qubes related questions.

Ah yes, that thread I meant (prevent clearnet leaks from solene).

Long story short you most likely want to build your own sys-net. Without taking responsibility: maybe debian-13-minimal and wpa_supplicant. And then carefully go through all the systemd services in that vm to make sure none of them feel chatty.
You can also setup your own nftables INSIDE of your new sys-net to make sure it is quiet - as in not allow it to send local traffic but establishing the connection and only forward from the netvm behind it and alike.

Long story short: wifi disabled on laptop with tethered android in front, android has vpn, might work.

This all smells a lot like “tech univeristy in Iran” to me lol. I’m sure its that direction, so yeah, better be careful.
I have the belly feeling to recommend you to use windows + vmware + kali

[NuageQubes81]

I would separate two things here: traffic generated by sys-net itself, and traffic that sys-net is only forwarding. If sys-net/template update checks or NetworkManager services make their own connections, those are not protected by sys-whonix and can expose a fairly normal Linux-ish client unless you disable/block them.

For the forwarded Tor connection, the ISP mainly sees a connection to a Tor guard or bridge, plus whatever survives NAT/routing. TCP fingerprinting may still look Linux-like, but I would not treat that as a reliable “this is Qubes” signal. If being unique is the risk, the safer test is practical: tcpdump in sys-net/on the upstream router while starting the setup, then remove every unexpected non-forwarded connection. For blending in, an ordinary router/phone hotspot or VPN/obfs4 bridge in front of Qubes probably matters more than tiny TTL/window differences.

[Rootman]

This is definitely a topic worth diving into, and I’d love to see more people jump into the discussion. One approach I’ve seen is tweaking your system’s network settings to spoof the user-agent, making you look like a Windows user in sys net. That said, it’s not a simple tweak and requires some advanced know-how. If anyone else has found smoother ways to pull this off, I’m all ears.

Another option that’s come up recently is using Mullvad’s local network sharing feature from your phone. Thanks to some recent updates, devices connecting through that method actually route straight through the VPN, bypassing your ISP entirely. The catch? It can sometimes drag down your network speed, so it’s a trade-off between privacy and performance.

Let me know if you’ve tried either of these or if there are other methods you’ve found effective.

[quietbadger27]

Small correction: user-agent spoofing will not change the TCP/IP fingerprint from sys-net. That header only exists inside HTTP(S) traffic after the connection is already made, and with Tor it is mostly the Tor Browser/app side that matters. I’d treat sys-net as two separate risks: block its own direct traffic, then test the forwarded path with tcpdump from sys-net or the upstream router. If the goal is blending in, a normal router/phone hotspot plus VPN or obfs4 bridge in front of Qubes is probably a bigger lever than tuning TTL/window values.

[qubist]

@abdullah

Research for “os detection through tcp/ip packets”.

As a possible workaround (in case you find you need that), you can install Windows and use it as a sys-net VM.

However, I highly doubt that Linux, even if watched for and detected, can be a problem for the simple reason that it is far less unlikely to find a home router or other network device not running any Linux kernel, and sys-net is doing the same. Android phones/tablets are also Linux-oids. So, consider the overall issue beyond a desktop/laptop.

Remember also that the Internet is owned, distrusted and so on, so various other attacks are possible.

[abdullah]

Thank you for this suggestion. I have already looked into it, and it’s interesting from a theoretical perspective.

Technically speaking, this is possible, but it is not a practical or secure solution for several reasons:

First: Engineering Complexity
It requires complex manual configuration inside a Windows HVM to route traffic between interfaces, along with manual IP settings. This is not officially supported, and any mistake could break the entire network.

Second: The Security Attack Surface (This is the most important point)
sys-net is the most critical qube in the system because it handles the physical network interface directly. Using Windows here—a system known for its many vulnerabilities—would massively increase the attack surface. Additionally, the Windows netfront driver is not hardened against attacks from the netback driver in the host. One forum member described this as “weakening security significantly.”

Third: It Fails the Core Objective (Hiding the Fingerprint)
Even if you successfully make Windows act as sys-net, it will still be a guest system (HVM) running on top of the Xen hypervisor. A sophisticated observer would still be able to detect the presence of Xen through virtualization fingerprints in the network packets. The goal of this setup would be to “avoid detecting Qubes,” but unfortunately, running Windows as a guest on Xen does not hide the fact that the system is running on Xen.

For this reason, I prefer the solution I mentioned earlier:
Using a router in WISP mode. This solution changes the device the ISP sees from the ground up (from a personal computer to a router), without compromising sys-net or dealing with the complexities of setting up Windows. It is a cleaner and much more secure approach.

I appreciate your suggestion, and I hope this clarifies why I am ruling out this option.

[kuhbs]

I’ve been to a place for a while where the gov had root@ on all the routers. Was kinda funny, bcs the root@ password was reasonably easy to google, so I logged in and changed it x)
Led to complaints lol.

if you build that router yourself, like a raspi or so, hm yeah maybe. But then what OS… If you run OpenBSD on that raspi, ok, but if you run a normal linux your gov will have root@ that pretty quickly too. Remember all your gov needs is a couple of million for funky spyware and it can own most common systems. One can assume that owning Qubes comes at a hefty pricetag, but I’m about 99% sure that there IS a pricetag for Qubes (pure belly feeling).

Running windows in sys-net I would say is less secure than running network-manager on a fedora or debian, but both are still bs security (I think, not know).

The thing that keeps all things reasonably secure is Xen and Qubes. Given that the VMs by default all have passwordless sudo, inside VM security seems to be a bit of a “whatever”. So you might as well run windows there.

From all the tings I’ve heared I still think android with tether + sth like mullvad might be the best answer here, as the Question is “I want to run Qubes, gov doesnt like to see that, so how do I not light up like a xmas tree when doing so”.

Btw, windows as sys-net with stuff behind it looks at least similar to windows on the laptop + vmware + kali in it - but similar is not the same ofc.

h4x0ring the router might not be the most anonymous solution. Hence, I still think android + tether + vpn would show up the least to the ISP, but this really isn’t my speciality… My region is “automating things”, not network anonymity (not in the slightest). So take all that with a grain of salt.
I think you might post your thread in the whonix forum, they might have the best angle on this I think.

[James369]

sys-net is the weakest link in your chain, I would never put windows on it. There is not much that can be done here as it is quite trivial to see if you are connecting from windows or linux as I just discovered for myself with openbsd. You could route everything through a home server / gateway that was windows on a seperate machine if you had an old laptop around.
I do something like this but with netbsd. I would say, having lived in many countries that sound very much like what you are in, that what I did was pay for my own vpn, just get a droplet somewhere, (they can be as cheap or cheaper than a corp-vpn like around 5$ a month) and use that as a tunnel for everything. I did this in China, Iran and other Asian countries without worry. There is a guide here from selene about reducing clearnet leaks which can show you that it is not as easy as just making a sys-vpn qube. I used ssh from sys-net last time I think

[Rootman]

Ah, thanks for the correction! I actually looked into this more and found you can also use a portable router with VPN built right in before you even hook up to Qubes. Stuff like the GL.iNet routers running OpenWrt work great for that, they handle the encryption on the hardware side, so your Qubes machine just sees a clean, already-secured connection. It’s a neat way to add another layer of separation without overcomplicating things.

[Zrubi]

@abdullah

• sys-whonix is set as the UpdatesProxy for all templates and dom0. All system updates are forced through Tor.
• sys-whonix is set as the ClockVM for all qubes. All NTP requests go through Tor.
• All of my AppVMs use sys-whonix as their NetVM.

This setup is seen by your ISP as a TOR traffic.
If you do it correctly, then that’s it, no other traffic should be seen by any observer outside of your Qubes OS device.

However doing it ‘correctly’ (means: there 101% no leaks) is really hard - if not impossible in practice.
So I would be not depending on the Qubes OS defaults for sure. See this topic for more:

Does my ISP see what operating system I'm using? I want to hide the use of Qubes OS

I’m using Qubes OS on my computer and I want to hide this fact from my ISP. My default template is Fedora(sys-net, sys-usb, sys-firewall are Fedora operating system). I’m using my own router (my own. Not the one I got from my ISP) and I have a VPN enabled on it. A computer with Qubes will always be used with the VPN enabled on the router. Other devices will also use the router (sometimes with the VPN enabled on the router and sometimes without the VPN enabled on the router). 1 In this situation…

Moreover, If you want to ‘blend in’ using TOR is very likely not the way to go.

[abdullah]

I tried Windows 10 LTSC, but it didn’t work as a netvm.

[corporateblush]

Disclaimer: I am strongly aware of the OP’s situation so none of my messages should be considered as suggestions, but just as contemplation.

It is obvious that the OP ignores it persistently and consistently, and @kuhbs was faster than me but I completely agree with him. There is no better way but to (try to) blend in, and nothing is more common then to generate internet traffic with Android, while behind its usb-tethereing is whatever the one would want to.

Here is how I would do it to further secure it.

Namely, I’d use a separate (old?) machine with a minimal Linux installation which would serve as a gateway, rather than a router because of a better manageability, to USB tether to with my phone.

Then, I’d connect Qubes machine to the first machine directly with ethernet cable, then setting IPs of the two manually or using dnsmasq, setting IP forwarding, setting up NAT with nftables (or iptables) and this should work well.

Why this? Well, further security is consisted in a fact that we are expected USB controller to be poisoned by and via Android, so we spare our Qube’s controller, and have it at our disposable, especially when modern laptops mostly have a single USB controller, and all other devices attached to it then would be endangered in a direct-to phone connection. On a gateway machine, when USB controller is poisoned, it is still needed malicious attack to escape to ehternet NIC, which is not that feasible, at least not yet without Mythos (this reference to anthoer topic is intended ).

Now, how would I further secure this setup? I still couldn’t find a way to run usb-tethering in it but I would without doubt use Second space. And when the OP lives where we all think he lives, then Xiaomi should be accessible to him too, in order to get this more than cool feature.

Since I couldn’t be able to use usb-tethering there, then I would move all of my apps there, and would strip my main space to a bare minimum needed for a phone to function properly. Of course, not being logged into a Google account on a phone and using only F-Droid and Aurora Store is a must as I see it.

When you don’t have ethernet card on your Qubes machine, or when the one would like to isolate hardware from sys-net (like we do with audio and VGA controllers via sy-sudio and sys-gui-gpu), the one could try something like this:

Running ethernet sys-net in PVH mode

After several months of learning Qubes, I realized that the ethernet sys-net (not to say wifi) is the weakest link in Qubes, only to find out that it was already been discussed here, which proves what I concluded: I decided to start a new topic due to its visibility and the idea I got, but please merge it with above if you find it more appropriate. Now, after thinking through and reading a lot, these are the facts: Ethernet is safer than internal or external wifi. Ethernet sys-net has t…

but the one then would have to rely on the USB to ethernet device itself not being malicious.

WiFi? Well even when I live in a country which ISP I am happy with (which I do - the least evil of all), I simply ever, never do use WiFi. That’s like my basic, general rule. No devices in my environments with WiFi, or WiFi enabled.

When I could live with WiFi, then I’d use phone’s Second space cleaned from all possible apps and connect the first machine to it via WiFi, and forward traffic to the second one via ethernet again.

I’d happy to further contemplate this setup to hear what do you think of it, and why you find it interesting or not.

[Rootman]

Hi @corporateblush, thanks for the detailed breakdown and the time you took to write that. It all clicks, except for one thing: why skip Wi-Fi?

Is it because the traffic is too easy to snoop on, or does it just open up a massive attack surface? Or is there a specific reason?

Asking because it’d help others map this out based on their threat model. Wi-Fi is literally everywhere, and for a phone, it’s basically impossible to escape. So what’s the real play here?

[corporateblush]

Hey @Rootman. Thanks for your appreciating response.

I wouldn’t want to hijack the topic, but just to drop another idea. By no means I am an expert, not because I can’t be the one, but because that’s not my life goal. At best I see myself as an advanced user.

Knowing this, and I am completely honest with this, extra caution is something that I practice regularly: I’d rather avoid a layer when it’s possible, than trying to study it and spend my life patching its holes.

So, basically, I avoid WiFi for that reason, and your question is kinda pleonasm: as I am aware of, WiFi is too easy to snoop on, thus representing massive attack surface, especially because it’s everywhere.

But it is possible to escape it even for a phone, I don’t see why it wouldn’t be? I am not using Wifi with my phone ever. Why and where would I use it? What do I miss by not using its WiFi that cannot be achieved by safer option?

I hope I answered your question. I will repeat, even if it would be perfectly safe to use it (and I think the most of us agree it’s not), I decided to focus on ethernet, because I don’t have the time to master WiFi setup