February 23 2019 21:31:09
· Home
· CV
· Articles
· Links
· News Categories
· Media Gallery
· Search


Forgotten your password?
Request a new one here.
The joys of PPPoE, MTUs and Blackhole Routers
PersonalI finally got around to setting my broadband up in my new house. I've come from having cable internet to now being forced to have ADSL as Virgin Media will not supply services to my street.

I was able to lift-and-shift my homebrew Linux router into my new setup with minimal changes required (I just had to add a PPPoE "dialler" and change the interfaces being referenced in the script). However, one thing had me stuck for a good few hours: some webpages simply didn't load through clients behind the router (though all websites loaded fine directly on the router itself).

I spent a lot of time playing around with my network configuration to see if any of my hardware was causing the issue. I removed my wireless bridge and connected directly to the router to no avail. I tried different computers, no luck.

Eventually, I broke out Wireshark and saw that a lot of my TCP packets were reported as being lost (missing segments). This triggered a memory of something I had read about blackhole routers (routers which will refuse to fragment a packet but instead of reporting back to the originator, they will silently discard the packet causing the connection to hang and then maybe timeout).

Ethernet (and cable) uses an MTU of 1500 while PPPoE has an MTU of 1492. All of my client machines were set to an MTU of 1500. After changing the MTU to match that of the PPPoE link, everything started working. Not a great solution, as I don't want to have to manually set the MTU on each of my clients. I did some research and found that DHCP can specify the MTU that all clients should use. However, it was clear that this wasn't a viable solution upon witnessing Apple equipment completely ignore the advice provided by the DHCP daemon.

Finally, I came across an IPTables rule that forces the MSS (maximum segment size) to a particular value for a given link: `iptables -t nat -A POSTROUTING -o ${EXTIF} -p tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1453: -j TCPMSS --set-mss 1452'

This must be added before the masquerade line (`iptables t nat -A POSTROUTING -s -o ${EXTIF} -j MASQUERADE'). Implementing this goes against everything that has been put in place on the internet to prevent this problem (MTU path discovery should allow participants in a conversation to determine the maximum segment size dynamically). However, while there are still blackhole routers in the world, hacky work-arounds like this will be required. For now, I'm just glad that my internet connection is working properly. DNS updates are pending, but I can see them propagating throughout the internet as I write this!
747,299 unique visits