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?
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).
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.
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?
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...
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.
Does conntrack actually allow ICMP "Fragmentation Needed" response back through the firewall from the outside to the "inside" zone when the initial packet from the inside to the outside zone was not a ping? Say the initial packet is 1500 bytes long with SYN flag in the TCP header. An intermediate router is set to MTP 1300, so it sends the ICMP "Fragmentation Needed" response back to the originating host. Will OpenWRT allow this ICMP packet to get back to the originating host? In this case, the connection is not even established yet, but even if it was established, would ICMP "Fragmentation Needed" be allowed back through the firewall to reach the originating host?
First of all I have never seen a TCP SYN with that big payload. Second the case that the router will report back that fragmentation is needed is when you send the packet with no-fragment enabled, which is usually not the case.
In other cases the IPv6 firewall rules allow the packet-big to be relayed back to the lan host and in case of IPv4 there is usually no direct communication between the lan host and the internet host, as the router is masquerading.
OK, so let's forget a packet size with the SYN flag.
Let's say a TCP session has been already established. A 1500-byte packet is sent by the host. PMTUD is enabled on the host sending the packet, so the "do not fragment" flag is set in each TCP or UDP packet.
An intermediate router somwhere in the ISP network has MTU set to 1400. So, this intermediate router sends the ICMP response "Fragmentation needed" back to the host. This ICMP response arrives in the outside firewall zone of the OpenWRT. Will the firewall allow this packet in and forward it to the host in the inside firewall zone based on the ESTABLISHED conntrack entry without having a special rule that allows ICMP responses "Fragmentation needed" to be forwarded from the "outside" zone to the "inside" zone?
I think such ICMP errors will be classified as RELATED to an existing conntrack entry and actually passed back to the internal host that elicited that error in the first place. ICMP was always intended as a companion for IP....
That's the question. Will they be considered "related" or will a specific rule need to be created for this type of ICMP response so that it can traverse the firewall from the outside zone to the "inside" zone. ?
No they will be classified as RELATED by conntrack... you should be able to test that:
Create a filter that decreases the TTL of a TCP flow to something smaller than the number of hops to the endpoint, but large enough to leave your network. Then capture the traffic and see whether you get ICMP TTL exceeded messages for the original sender of the TCP flow.
I predict you will actually get such error messages, after all this is partly how traceroute and mtr (in TCP mode) operate.
In plain english, should WAN > ACCEPT firewall rule be set to Masquarading & MSS Clamping, but LAN > WAN not? Or should it? What are the specific settings that need to be changed?
Verizon uses an MTU of 1428, TM & ATT use 1400. In some cases, I want to use these settings for a tether through to the router situation.
In another situation, I have another network, unfortunately the device does not run OpenWRT, but DD-WRT, that has exactly the symptom described by the OP: Android devices having the same issue, only. I do not need the DD-WRT settings (although appreciated), but instead I am trying to figure out what is the general applied approach here. Not all the theory and details: What exact settings get changed on the router's firewall rules to prevent the errors (in Openwrt, I can further translate that to DD-WRT if need-be)?