Hi misc@ We got notice from a customer who connects to us through an ipsec tunnel that loading websites on our site is really slow. On our site we use OpenBSD 5.0 i386 as ipsec gateway. On the other site of the VPN is a Linux StrongSwan gateway.
Our analysis showed that our webserver starts sending packages with an mtu of 1500. The OpenBSD ipsec gateway then drops the package and returns an icmp unreachable "fragmentation needed" with mtu next hop set to 0. The webserver then starts again sending the packages but with mtu 576. As a workaround we added this to our pf rules: match on enc0 scrub (max-mss 1334) Searching the mailing list I found this thread which describes the same problem with a different workaround: http://marc.info/?l=openbsd-misc&m=133677069826075&w=2 Is there a recommended configuration that allows PMTU discovery? I tried to understand why the OpenBSD gateway returns a next-hop mtu 0. In ip_input.c I found the code that gets the mtu from the next interface (line 1579). But the enc0 interface has no mtu. There is a "#define ENCMTU 1536" in if_enc.h but that is not used in if_enc.c. RFC 1191 (Path MTU Discovery) chapter 4 says this about the Next-Hop MTU field in the ICMP message: To support the Path MTU Discovery technique specified in this memo, the router MUST include the MTU of that next-hop network in the low-order 16 bits of the ICMP header field that is labelled "unused" in the ICMP specification [7]. ... This field will never contain a value less than 68, since every router "must be able to forward a datagram of 68 octets without fragmentation" Remi
