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 matthias@hm.edu 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 jac...@cybershroud.net:
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.
