[GH-ISSUE #1669] Firejail breaks the network environment when sandboxing network

gitea-mirror commented

2026-05-05 07:30:18 -06:00

Owner

Originally created by @ghost on GitHub (Dec 8, 2017).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1669

Using firejail in the context of TorMiddlebox, I ran into this issue.

Pointers :
https://github.com/Bylon/TOR_Middlebox/wiki/Firefox---Middlebox-tricks
Bylon/TOR_Middlebox#3

This is even more scary than https://github.com/netblue30/firejail/issues/1668

When running firefox inside firejail as instructed in the TorMiddlebox Wiki, we are breaking vnet0 for VMs!

Steps to reproduce:

configure the middlebox
launch a VM and see that it works (the VM is attached to vnet0 as bridge)
now launch the firejailed firefox on vnet0 (option --net=vnet0), see that it works
exit this firefox and run the VM again: now it has stopped working. Even DHCP is erratic and your VM may or may not get an ip address!

( the firejailed firefox continues to work though!)

Workaround
If you do:

sudo ifdown vnet0; sudo ifup vnet0

Although you get error messages "Could not find vnet0", the VM will work again.

Leads
I said "even more scary", because same as the PulseAudio bug that was explained because PulseAudio was written way before namespaces existed in the kernel, same could happen here for:

bridgeutils
VirtualBox
... or could even be the kernel
... or the way firejail plays with networks!

Sorry I have not done further investigations, I am just reporting the symptoms.

That is because for my own use, I am fine with the easy workaround. But since Tormiddlebox+firejail+firefox is an interesting alternative to TorBrowser, with probably less leaks possibilities, I am not sure this workaround would suit all other users.

Originally created by @ghost on GitHub (Dec 8, 2017). Original GitHub issue: https://github.com/netblue30/firejail/issues/1669 Using firejail in the context of TorMiddlebox, I ran into this issue. Pointers : https://github.com/Bylon/TOR_Middlebox/wiki/Firefox---Middlebox-tricks Bylon/TOR_Middlebox#3 This is even more scary than https://github.com/netblue30/firejail/issues/1668 When running firefox inside firejail as instructed in the TorMiddlebox Wiki, we are breaking vnet0 for VMs! **Steps to reproduce:** - configure the middlebox - launch a VM and see that it works (the VM is attached to vnet0 as bridge) - now launch the firejailed firefox on vnet0 (option --net=vnet0), see that it works - exit this firefox and run the VM again: now it has stopped working. Even DHCP is erratic and your VM may or may not get an ip address! ( the firejailed firefox continues to work though!) **Workaround** If you do: `sudo ifdown vnet0; sudo ifup vnet0` Although you get error messages "Could not find vnet0", the VM will work again. **Leads** I said "even more scary", because same as the PulseAudio bug that was explained because PulseAudio was written way before namespaces existed in the kernel, same could happen here for: - bridgeutils - VirtualBox - ... or could even be the kernel - ... or the way firejail plays with networks! Sorry I have not done further investigations, I am just reporting the symptoms. That is because for my own use, I am fine with the easy workaround. But since Tormiddlebox+firejail+firefox is an interesting alternative to TorBrowser, with probably less leaks possibilities, I am not sure this workaround would suit all other users.

gitea-mirror closed this issue

2026-05-05 07:30:20 -06:00

gitea-mirror commented

2026-05-05 07:30:22 -06:00

Author

Owner

@netblue30 commented on GitHub (Dec 9, 2017):

I would suggest you move to the version here on mainline github. The LTS version is missing a lot of functionality. What we have on mainline is quite stable, and it will be released in the next few days. Of interest to you is some of the support we added a few weeks back for systemd-resolved service and some DNS bugs fixed for Ubuntu latest.

I am assuming vnet0 is a bridge device, something like:

# brctl addbr vnet0
# ifconfig vnet0 172.16.0.1/24

On 172.16.0.1 you run a dns resolver, and you correctly use --dns=172.16.0.1 for your sandbox.

One thing you are missing in this setup is a netfilter/iptable configuration on the main system. The problem is the router upstream from you doesn't know where 172.16.0.0/24 is. It will receive the traffic from you sandbox, forward it, but when the response comes back it has no idea what to do with it. You either add a static route on this router for 172.16.0.0/24, or you set up network address translation on you box. I have an example for NAT here: https://firejail.wordpress.com/documentation-2/basic-usage/#routed

I would say instead of sandboxing firefox start with a simple /bin/bash sandbox so you can ping to get some traffic going, something like:

$ firejail --noprofile --net-vnet0 --dns=172.16.0.1

(use --noprofile in this case otherwise the sandbox will kill ping program)

@netblue30 commented on GitHub (Dec 9, 2017): I would suggest you move to the version here on mainline github. The LTS version is missing a lot of functionality. What we have on mainline is quite stable, and it will be released in the next few days. Of interest to you is some of the support we added a few weeks back for systemd-resolved service and some DNS bugs fixed for Ubuntu latest. I am assuming vnet0 is a bridge device, something like: ````` # brctl addbr vnet0 # ifconfig vnet0 172.16.0.1/24 ````` On 172.16.0.1 you run a dns resolver, and you correctly use --dns=172.16.0.1 for your sandbox. One thing you are missing in this setup is a netfilter/iptable configuration on the main system. The problem is the router upstream from you doesn't know where 172.16.0.0/24 is. It will receive the traffic from you sandbox, forward it, but when the response comes back it has no idea what to do with it. You either add a static route on this router for 172.16.0.0/24, or you set up network address translation on you box. I have an example for NAT here: https://firejail.wordpress.com/documentation-2/basic-usage/#routed I would say instead of sandboxing firefox start with a simple /bin/bash sandbox so you can ping to get some traffic going, something like: ````` $ firejail --noprofile --net-vnet0 --dns=172.16.0.1 `````` (use --noprofile in this case otherwise the sandbox will kill ping program)

gitea-mirror commented

2026-05-05 07:30:24 -06:00

Author

Owner

@ghost commented on GitHub (Dec 9, 2017):

Thanks!

Yes, yes, I have all that. It is the whole point of TorMiddlebox (https://github.com/Bylon/TOR_Middlebox)

There was an ancient script on HowToForge that was half-broken with 14.04 and completely broken in 16.04.
So I fixed it and that is all on my github above.

There is no issue inside this firejailed-firefox, it work perfectly with my iptables (apart from "bug" on dbus, not having its "menus and actions").
There are indeed a lot of iptables rules that are put in place by the main script (middlebox).

Basically what these rules do is:

redirect all traffic (TCP) from vnet0 to 172.16.0.1 (address of vnet0 on our host) on port 9040 which where Tor is listening
redirect DNS the same to where Tor is listening for Tor-resolve (the dns is resolved by the Tor exit node, not ny our host, that would be a leak since we want to use Tor!)
allow DHCP to go through
optionally do a forward for those hosts/networks that are configured by the user as "non-tor"

All that works perfectly: either with a VM (VirtualBox) or with firejail.

Ad. note: you should try it! It a nice usage of your firejail to have that easily a firefox going through Tor.

The trouble here is that when firejail has been started... vnet0 does not work anymore for the VM, unless you apply the workaround explained in the first post.

Currently I am working on modifying the scripts so that I have separate networks (like vnet0 and vnet1) for use with VirtualBox and firejail, so that they don't interfere... hopefully!

The bug is very strange and scary though. Why on earth is vnet0 broken for the VM once we have used firejail on it, I can't explain!

@ghost commented on GitHub (Dec 9, 2017): Thanks! Yes, yes, I have all that. It is the whole point of TorMiddlebox (https://github.com/Bylon/TOR_Middlebox) There was an ancient script on HowToForge that was half-broken with 14.04 and completely broken in 16.04. So I fixed it and that is all on my github above. There is no issue inside this firejailed-firefox, it work perfectly with my iptables (apart from "bug" on dbus, not having its "menus and actions"). There are indeed a lot of iptables rules that are put in place by the main script (middlebox). Basically what these rules do is: - redirect all traffic (TCP) from vnet0 to 172.16.0.1 (address of vnet0 on our host) on port 9040 which where Tor is listening - redirect DNS the same to where Tor is listening for Tor-resolve (the dns is resolved by the Tor exit node, not ny our host, that would be a leak since we want to use Tor!) - allow DHCP to go through - optionally do a forward for those hosts/networks that are configured by the user as "non-tor" All that works perfectly: either with a VM (VirtualBox) or with firejail. **Ad. note:** _you should try it! It a nice usage of your firejail to have that easily a firefox going through Tor._ The trouble here is that when firejail has been started... vnet0 does not work anymore for the VM, unless you apply the workaround explained in the first post. Currently I am working on modifying the scripts so that I have separate networks (like vnet0 and vnet1) for use with VirtualBox and firejail, so that they don't interfere... hopefully! The bug is very strange and scary though. Why on earth is vnet0 broken for the VM once we have used firejail on it, I can't explain!

gitea-mirror commented

2026-05-05 07:30:26 -06:00

Author

Owner

@netblue30 commented on GitHub (Dec 9, 2017):

So, VirtualBox works fine on vnet0, you start a sandbox on vnet0 and VirtualBox stops working unless you bring vnet0 down and up again. I'll give it a try here.

@netblue30 commented on GitHub (Dec 9, 2017): So, VirtualBox works fine on vnet0, you start a sandbox on vnet0 and VirtualBox stops working unless you bring vnet0 down and up again. I'll give it a try here.

gitea-mirror commented

2026-05-05 07:30:27 -06:00

Author

Owner

@ghost commented on GitHub (Dec 9, 2017):

Exactly that!

Although I didn't have the courage to debug VirtualBox or bridgeutils (or firejail or the kernel) to investigate!

BTW (you probably know it), what we have in Ubuntu 16.04 repos is the LTS version of firejail:

$ firejail --version
firejail version 0.9.38.10

@ghost commented on GitHub (Dec 9, 2017): Exactly that! Although I didn't have the courage to debug VirtualBox or bridgeutils (or firejail or the kernel) to investigate! BTW (you probably know it), what we have in Ubuntu 16.04 repos is the LTS version of firejail: ``` $ firejail --version firejail version 0.9.38.10 ```

gitea-mirror commented

2026-05-05 07:30:28 -06:00

Author

Owner

@ghost commented on GitHub (Dec 9, 2017):

I can confirm that when we have 2 bridged interfaces (vnet0, vnet1) and that firejail and the VM are attached each to a different interface, all works fine.

So, that is a better workaround than having to donw/up the interface after having used firejail.

... the "bug" is still there, but you don't bump into it since you don't reuse the firejail interface with the VM.

@ghost commented on GitHub (Dec 9, 2017): I can confirm that when we have 2 bridged interfaces (vnet0, vnet1) and that firejail and the VM are attached each to a different interface, all works fine. So, that is a better workaround than having to donw/up the interface after having used firejail. ... the "bug" is still there, but you don't bump into it since you don't reuse the firejail interface with the VM.

gitea-mirror commented

2026-05-05 07:30:30 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Jul 24, 2018):

Is this still a problem?

@chiraag-nataraj commented on GitHub (Jul 24, 2018): Is this still a problem?

gitea-mirror commented

2026-05-05 07:30:32 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Dec 9, 2018):

Closing since the OP has left Github.

@chiraag-nataraj commented on GitHub (Dec 9, 2018): Closing since the OP has left Github.

Rows
Columns

[GH-ISSUE #1669] Firejail breaks the network environment when sandboxing network #1128