[JonathanAnon]

Hi,

I have set up a VPN between a NetGear FVS114 and a Zyxel Prestige 650H/Hw
The link works fine. BUT there are two things.

1. I have an error in the Zyxel saying "Adjust TCP MTU to 1398"

and

2. I want to keep the link up all of the time. I have sent a keepalive checkbox to checked and put in an IP address on the other network as requested. Am I to assume that this will just ping the IP address to keep up the line.

thanks,

[O111111O]

Originally Posted by JonathanAnon

Hi,
I have set up a VPN between a NetGear FVS114 and a Zyxel Prestige 650H/Hw
The link works fine. BUT there are two things.
1. I have an error in the Zyxel saying "Adjust TCP MTU to 1398"

Baah, love "IPSEC compatible" stuff.

Ethernet and typical TDM medium use an MTU of 1500 bytes for raw frames. The problem is that you're encapsulating your payload (i.e. your "protected" traffic) in IPSEC. Your router is requesting the MTU adjust to keep from having to fragment packets. (This really kills CPUs on routers.) There's a very nice balancing act that's played in the IPSEC/MPLS world to keep hosts happy and path MTU detection working. (Again, otherwise the router has to fragment/reassemble the packet. Those little guys won't have enough CPU for it.)

Before you go hatching the MTU on all your interfaces down - I would suggest doing the following in Winders (lemme know if you're running something else) to try and figure out where the MTU is best adjusted.

ping -f -l 1500 xxx.xxx.xxx.xxx
(where xxx.xxx.xxx.xxx is host on other side of IPSEC tunnel, and try this for something like www.google.com. -f sets the "don't fragment" bit on the IP payload section of a packet, and -l xxxx sets the payload to transmit. Normally ping only sends a 64 byte packet.)

Pinging xxx.xxx.xxx.xxx with 1500 bytes of data:
Packet needs to be fragmented but DF set. << What you should see.

Move the -l number down to 1472 for anything, like www.google.com.

ping -f -l 1472 www.google.com
Pinging www.google.com [64.233.161.147] with 1472 bytes of data
Reply from 64.233.161.147: bytes=56 (sent 1472) time=11ms TTL=241 <- 11ms! woo hoo!

This means normal payload on wire is fine. So I would suspect it's just the IPSEC overhead.

Do the same method on each side of your VPN, first @ 1472, then down to a number that works. This shows you how much overhead IPSEC is taking.

Once this is done - ideally you would adjust the MTU of the INSIDE interface of your router to this. I don't think Linksys will let you do this - so you can try to adjust the MTU on the OUTSIDE interface... Not the most optimal way. (This means your MTU to rest of planet is low, and some dummies who's websites I won't name will not work because they drop ICMP.)

The other option is adjusting the MTU your hosts - but let's not go there.

Originally Posted by JonathanAnon

2. I want to keep the link up all of the time. I have sent a keepalive checkbox to checked and put in an IP address on the other network as requested. Am I to assume that this will just ping the IP address to keep up the line.
thanks,

Good question. Linksys/Xyxel I dunno. Normally a keepalive in the IPSEC world is on the IKE side. Key exchange on many devices defaults to 8 or 24 hours. With IKE up the actual IPSEC part of the payload just has to re-iniate it's SA (the crypto map) so the re-estabilshment is nearly instantaneous.

Is the IPSEC connection dropping?

[JonathanAnon]

I've got the link to stay up using keepalives. This is in the VPN section of the setup not IKE, but it works anyway. So it seems to be sorted.

I understand exactly what you mean regarding the fragmented packets. I will run those tests on the router and make the apt changes. Thank you very much for your help.