Matthias, I'm not sure if you got an answer to your question, but I have found a workaround. I set up an IPIP tunnel using a gif interface on both sides of the IPSEC VPN. The ipsec vpn is now running between the two public IPs of the boxes with only a point to point flow defined. The gif tunnel is then setup to run over the ipsec tunnel. Appropriate routes are configured for the private subnets behind each side of the VPN. While adding another layer of encapsulation is not ideal, you can set the MTU on gif interfaces. This allowed me to set an appropriate MTU and now PMTU discovery works for all of my machines behind the VPN. The correct value is reported in the next-hop field.
I hope this makes sense. I think the original issue is likely a bug and this is the only way I've seen to get around it, at least temporarily. On Sun, May 13, 2012 at 3:48 AM, Matthias Vey <[email protected]> wrote: > Hi, > > nobody an idea? I have the same problem. Currently I set the MTU of the > internal networks to 1200. It's a workaround but actually it wastes a lot > of > bandwith. But without this the MTU of the VPN traffic falls down to > something > around 550 and that's really bad :-( > > Thanks > > Matthias Vey > > > Am 11.05.2012 um 23:06 schrieb Carlos Flor <[email protected]>: > > > I have an openbsd 5.1-release box configured with an ipsec vpn to another > > identical openbsd machine. I am trying to test PMTU discovery by sending > > packets, both TCP and UDP, with the DF bit set. I get an ICMP > Unreachable > > - Fragmentation needed packet as expected, however the "Next-Hop MTU:" > > field is set to 0. The RFC says this should never be below 68. I am > > wondering if the issue is related to the fact that you can no longer set > an > > MTU on enc0 (the ipsec tunnel interface). My first question is why am I > > getting 0 as the next-hop mtu? Secondly, why can I no longer set an MTU > > for my enc0 interface (when I try with ifconfig, I get : SIOCSIFMTU: > > Inappropriate ioctl for device)? > > > > Thanks.
