[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

Have firewall accept ICMP Fragmentation Needed

I opened a pull request at https://github.com/Whonix/whonix-firewall/pull/7 but was told that the requested change needs to be discussed here first. So, here we go.

Let’s just start off with the commit message from my pull requests:

We want certain related packages to be accepted. In particular,
I’ve run into issues using a VPN in front of a Whonix Gateway. This
because the related Fragmentation Needed packages get dropped:

1780 280.196298 10.137.0.31 → 10.137.0.19 ICMP 590 Destination unreachable (Fragmentation needed)

With those packages not being delivered, a connection can be
established and works fine until a large package is sent. However,
once that happens no more packages can be delivered and the
connection times out after a while.

There is probably also a bunch of other, related packages that
we want to be delivered. ICMP host unreachable comes to mind, for
instance. Without it being delivered, one has to wait for
the connection attempt to timeout.

Note: Related connections appear to have been disabled in
414c2105149e02dcff82303e4c5b2dcd60ebbd29 but with no clear indication to why.

I do think it’s reasonable to adjust the firewall to ensure ICMP Fragmentation Needed packages are delivered. A hop with a lower MTU somewhere in the network should simply not break the network connection, at least in my opinion. Of course, there are other ways to allow Fragmentation Needed packages than just allowing RELATED packages but I’d like to hear any concerns about using this approach first before looking into how those concerns can be addressed.

We drop all ICMP by default anyhow.

Reason for removal of RELATED:

Reason to be cautious:

Reasons for not enabling RELATED by default:

//cc @HulaHoop

1 Like

Perhaps, we could create a more explicit rule. Something like:

iptables -I INPUT --proto icmp --icmp-type destination-unreachable -m state --state RELATED -j ACCEPT

Worst case, we’d let through a destination-unreachable package that’s not actually associated with a connection. In that case, it’d simply be discarded upon reception.

As for the danger of adding additional complexity because of the additional parsing required. As I understand it, this will happen here anyway in order for connection tracking to assign one of the NEW, ESTABLISHED, RELATED or INVALID states. Whether we use the state information doesn’t matter. (Of course, if connection tracking was disabled entirely or if additional conntrack helpers were in use, this wouldn’t hold true.)

Generally, using any ICMP opens users to the possibility of a sidechannel - CPU has a very visible effect on ICMP packet latency.

Second. If we have to make decisions based on security vs performance tradeoff we will choose security almost every time if there isn’t a crippling effect on usability.

We disable connection tracking by default so there would be added attack surface.

1 Like

The ability to customize Whonix firewall is pretty good already, I hope. It supports a configuration drop-in folder.

Related:

There is a setting GATEWAY_ALLOW_INCOMING_ICMP=1 which would prevent addition of this iptables rule:

$iptables_cmd -A INPUT -p icmp -j DROP

Also could could overwrite whole function ipv4_input_rules (or any other function) by supplying your own version in config.

As for ESTABLISHED vs ESTABLISHED,RELATED I would accept a patch to make that a variable in the usual script style. Default to ESTABLISHED and possibly overwrite as variable in config.

If you have other suggestions to make Whonix firewall easier customizable please discuss.

[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]