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

Have firewall accept ICMP Fragmentation Needed

Development
#1

I opened a pull request.

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.

1 Like
sys-whonix 16 inconsistent connectivity issues (Q4.0 AND Q4.1)
Flushing iptables once, else no connection
ICMP support is required for networking in some cases
#2

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
#3

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.)

1 Like
Running Whonix on KVM in Linux containers
#4

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
ICMP support is required for networking in some cases
#5

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.

#6

To head off claims I didn’t check first, I’m just not sure what the rules for necroing are on this forum. There is a thread titled “Have firewall accept ICMP Fragmentation Needed” about this.

I recently had to deal with the infamous “Tor stuck at 45% forever and not connecting” problem. This turned out to be because of misconfigured hardware ISP-side advertising an MTU lower than Whonix assumes (1500).

If Whonix bothered to actually accept “Destination Unreachable” ICMP messages, it would have quickly noticed the need to fragment the packets so that Tor could even get started working. In fact, specifically adding a rule to accept those “miraculously” fixed the issue, as one would expect. It later turned out that my connection does support higher MTUs despite the ISP’s DHCP options, but that’s just luck.

This also means that Whonix is fundamentally unusable by users stuck on subpar networking links such as dialup when using its default settings (unless they know to manually adjust the MTU of interfaces in the Whonix VM), which is still in use in my country, especially in rural areas.

I think this qualifies as a crippling effect on usability.

#7

Does ICMP Fix help? Documented just now.

2 Likes
#8

I have since fixed the issue on my end by ignoring the ISP’s advertised limits, but if this does what I think and simply allows all ICMP messages, then that would have the same effect as my whitelisting of ICMP which I had found during debugging.

I think just whitelisting the specific messages related to link quality would also work with lesser security implications, but as noted that is not currently implemented. In any case, good to have it documented.

#9

How?

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