MSS clamping, fragmentation and ICMP blocking by firewall

Installing and Using OpenWrt
#1

I've had an ongoing issue with Android devices randomly disconnecting with "Connected but no internet" messages. This generally happens a few times per day for each device. These devices are connected to my OpenWRT router (BT Homehub 5A).

Looking into it further I suspected that this is due to packet fragmentation, so I turned on MSS clamping. Sure enough, this fixes the problem.

But thinking about it further, perhaps the correct fix would be to adjust the firewall to allow ICMP Needs Fragmentation packets. It's unclear to me why the default firewall rules in OpenWRT drop all ICMP packets other than echo reply.

So, my question is: should the firewall allow ICMP Needs Fragmentation packets?

#2

No, if some icmp packet comes back in reply to a new or established connection, it will be allowed as related.

1 Like
#3

Oh, yes, of course! I had forgotten about conntrack.

So, I guess I am back to wondering why MSS clamping is needed to enable these android devices to remain connected (other machines on my network which are running Linux don't have a problem).

#4

All hosts in the lan should have an mtu of 1500, but the wan has usually lower value, 1492 for pppoe. So it needs to be adjusted. You might not notice it all the time for all the hosts if they send packets with small amount of data, for example ssh might work fine but scp will fail.

1 Like
#5

Right, but devices that try to send packets with size > 1492 should receive back a ICMP Needs Fragmentation packet, and adjust MTU accordingly, should they not?

#6

Yes they should, but it is no secret that path MTU discovery does not work reliably over the internet... Partly do to the pseudo-security of blocking ICMP messages in firewalls, and partly do to IP not having a better method for MTU truncation in the first place...

If IP had a bit to set for truncated packet, it could set that bit and simply transmit the largest packet it can transmit (it would need to recalculate checksums) the endpoint would get better/faster feedback of a full path's capability (sure the receiver would still need to tell the sender) without changing the protocol... I guess early internet protocol designers simply assumed that nobody in their right mind would block internet-control-message-protocol packets in the first place... and/or hops would simply fragment packets to fit their MTU...

2 Likes
#7

MSS clamping on the wan interface limits the TCP segment size the remote peer is allowed to send to you. If you wanted to disable it, an alternative would be path MTU discovery for the receive direction. This requires ICMP messages sent by your ISP's router to get unfiltered to the remote TCP peer. If this does not work, there is not much you can do to fix it, short of reenabling MSS clamping as a workaround.

1 Like