
Hi Srijan,
There should be no problem in using the LPC across NAT or a site-to-site VPN - however, in some cases we have seen that the path MTU discovery inside VPN’s can fail (fx if ICMP communication is not allowed) - which can be critical as the MTU is often smaller inside the site-to-site VPN. Therefore we have added the option to specify the MTU in the opendoor dialog (on the LP which the LPC connects to). Depending on the MTU on your site-to-site VPN this will need to be reduced.
You can determine the MTU using ping through the tunnel - from the LPC towards the LP or the other way:
# ping -M do -s <MTU-28> <IP-of-other-end>
here’s what it would look like if you are above MTU:
# ping -M do -s 1472 10.20.30.40
PING 10.20.30.40 (10.20.30.40) 1472(1500) bytes of data.
ping: local error: Message too long, mtu=1438
this reveals the MTU to be 1438 in this case - we can test this by subtracting the size of the IP header (28 chars) from the 1438 and trying again:
# ping -M do -s 1410 10.20.30.40
PING 10.20.30.40 (10.20.30.40) 1410(1438) bytes of data.
1418 bytes from 10.20.30.40: icmp_seq=1 ttl=61 time=8.06 ms
which appears to be going fine without truncation.
So in this case the correct MTU to specify inside the opendoor VPN will be 1410 bytes.
If this doesn’t help - we may need to take a closer look at the system, and - in that case - recommend that you raise a support ticket.
Best regards
Peter Melsen
7 comments