sl2tps, MRU, MTU, and MSS

[Brian Candler]

I've done a bit more debugging on the MSS problem I'm having with sl2tps
running with IPSEC transport layer security. The client is Windows XP
out-of-the-box.

Here's what happens:

1. PPP negotiates an MRU of 1400
2. However, ifconfig ng0 shows an MTU of 1376 (where does that come from?)
3. When the client opens a TCP connection, it offers an MSS of 1360
4. When the remote webserver responds, it offers an MSS of 1380 (?)
5. The client sends a HTTP request, the server responds (MSS1360 / MTU1400),
   but that's too large to fit ng0 (MTU 1376)

root at candlerb ~# ifconfig ng0
ng0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> mtu 1376
        inet 172.17.0.216 --> 192.168.100.100 netmask 0xffffffff
root at candlerb ~# tcpdump -i rl0 -n -s1500 tcp port 80 or icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on rl0, link-type EN10MB (Ethernet), capture size 1500 bytes
10:41:16.454720 IP 172.17.0.216.58826 > 212.100.234.54.80: S 1482417021:1482417021(0) win 16384 <mss 1360,nop,nop,sackOK>
10:41:16.464675 IP 212.100.234.54.80 > 172.17.0.216.58826: S 1193972421:1193972421(0) ack 1482417022 win 5840 <mss 1380,nop,nop,sackOK>
10:41:16.465486 IP 172.17.0.216.58826 > 212.100.234.54.80: . ack 1 win 17680
10:41:16.466490 IP 172.17.0.216.58826 > 212.100.234.54.80: P 1:522(521) ack 1 win 17680
10:41:16.477538 IP 212.100.234.54.80 > 172.17.0.216.58826: . ack 522 win 6432
10:41:16.485841 IP 212.100.234.54.80 > 172.17.0.216.58826: . 1:1361(1360) ack 522 win 6432
10:41:16.485983 IP 172.17.0.216 > 212.100.234.54: ICMP 172.17.0.216 unreachable - need to frag, length 36
10:41:16.487047 IP 212.100.234.54.80 > 172.17.0.216.58826: . 1361:2721(1360) ack 522 win 6432
10:41:16.487114 IP 172.17.0.216 > 212.100.234.54: ICMP 172.17.0.216 unreachable - need to frag, length 36
10:41:19.512030 IP 212.100.234.54.80 > 172.17.0.216.58826: . 1:1361(1360) ack 522 win 6432
10:41:19.512182 IP 172.17.0.216 > 212.100.234.54: ICMP 172.17.0.216 unreachable - need to frag, length 36

172.17.0.216 is the IP address of the FreeBSD box; the client's L2TP pool
address has been NATted to this using pf. And of course, being a private
address, the FreeBSD box is also behind a NAT firewall. And because of this,
the ICMP 'need to frag' message isn't getting back to the webserver, and
everything falls over.

So I have the following questions:

1. If the PPP MRU is 1400 (which appears to be correctly picked up on the
Windows side), why is the ng0 MTU 1376?

2. How can I fix this problem, without manually frigging the MTU at the
Windows client side?

I don't think the IPSEC transport header is anything to do with this: the
PPP session sits *within* the IPSEC encapsulation, and 1400 is plenty of
space for an IPSEC header to be added and still fit within Ethernet MTU.

Regards,

Brian.