2

I have a linux (openSuse Leap 15.0) computer that's connected to a cable modem using PPoE (hopefully not relevant to this. EDIT the ppp0 interface has an mtu of 1492 but the eth0 interface it is "bound" to - I don't understand exactly how this works - has an mtu of 1500) on ppp0/eth0 (external) and with a local network (10.1.0.0/8) on eth1 (internal). EDIT It's running firewalld with masquerading enabled.

I'm also running named and dchpd on the local network and have a couple of wifi routers connected, a printer, etc.

Anyway, everything works perfectly if MTU is set to 1400. But if MTU is set to 1500 on a machine connected to the local network, things fail. In particular, requesting a web page will hang and, if I look at the traffic with wireshark, only part of the response to the HTTP request is being returned (the last part, as it happens, for the example I looked at).

This would still be OK - I can lower MTU on most connected devices - but I need to connect an un-rooted android phone. The only way I can get this to work currently is by using a wifi router with its own DHCP (ie its own little network) and adjusting MTU in the router settings.

My impression, then, is that I'm missing something in the rules above to handle fragments. Yet when I read around it seems like stateful connections should handle fragments correctly. I've also tried duplicating the rules with -f but it appeared to have no effect.

How do I make this work? More exactly, if the above is correct, how do I get iptables to forward fragments? Thanks.

EDIT Or, if this is a better way, why isn't anything that connects to the network doing PMTUD correctly? No ICMP messages are blocked by the firewall. If I run ping it works fine (and I see ICMP in wireshark). If I do an HTTP request, I see no ICMP message, which worries me. Currently I am trying to find a way to test whether fragmentation messages are being blocked somewhere else.

EDIT Had eth0 and eth1 swapped in the text. Fixed now.

andrew cooke
  • 121
  • 2
  • The current best practice is to deny fragments to avoid a fragment DoS attack. Most business configure the routers and firewalls to deny fragments. PMTUD should be used to predetermine the path MTU. – Ron Maupin Nov 18 '18 at 15:19
  • if that will fix things then fine - how do i do that? how do i make this work? (but this is a home network - i am not that bothered about DoS). – andrew cooke Nov 18 '18 at 15:22
  • # cat /proc/sys/net/ipv4/ip_no_pmtu_disc returns 0 which my initial hurried reading indicates means it's enabled on the main computer. – andrew cooke Nov 18 '18 at 15:24
  • PMTUD relies on ICMP, so you need to allow the proper ICMP messages. Unfortunately, many people block ICMP as a matter of course, which is really incorrect. You _can_ block some ICMP message types, but others need to be allowed for a network to properly work. – Ron Maupin Nov 18 '18 at 15:28
  • i can ping fine (on a client, connected to the local network, "ping google" scrolls happily up the screen) (i'm assuming that means ICMP is ok?) – andrew cooke Nov 18 '18 at 15:28
  • Ping only uses two ICMP message types (Echo and Echo Reply), which have nothing to do with PMTUD, but there are many other ICMP message types. Specifically, you need to allow the Fragmentation Needed ICMP messages. – Ron Maupin Nov 18 '18 at 15:34
  • if i look at firewall-config, in the ICMP filter window, for both internal and external zones *nothing* is blocked. so the firewall appears to be ok (it even says, the default is no limitation). and since ping works, they are going through the nat, right? – andrew cooke Nov 18 '18 at 15:37
  • Why haven't you set up masquerading in firewalld directly, instead of using manually created direct rules? – Michael Hampton Nov 18 '18 at 15:38
  • that's a good question. it was some time ago i first set this up. i've just enabled it now and it seems to make no difference. should i remove the rules, enable that, and restart firewalld? edit: i've now removed the rules and enabled masquerading in firewalld. i still have the same behaviour wrt mtu. – andrew cooke Nov 18 '18 at 15:41
  • You've definitely got a PMTU problem. But it's probably not with your router. Let's go back to basics: First, why on earth are you using PPPoE with cable? This is a bizarre setup. Who is the ISP? Why have they done this? PPPoE requires an MTU lower than 1500 and great competence on the part of the ISP (which is all too often absent). It's also almost always used exclusively with *DSL connections, not cable. – Michael Hampton Nov 18 '18 at 16:46
  • i live in chile. it's a mess. i have to work with what i can get. my ISP isn't going to fix anything. – andrew cooke Nov 18 '18 at 16:53

0 Answers0