Problems with frame sizes over VPN

[Admin32]

Greetings once more everyone,

I'm dealing with a Cisco powered VPN and I'm experiencing a few problems.

Here is the setup:


LAN---(eth0)GATEWAY(eth2)--VPN BOX----Internet--Customer

The above setup has been tested and works fine. Gateway is running redhat v8.

The problem I am having is when hosts from the LAN try to telnet to machines on the other side of the VPN.

The gateway is routing and masquerading their connections so this way all connections from the LAN seem to be coming from the GATEWAY host.

Since this is a VPN, the MTU is a very critical factor. Gateway;s eth2 interface, its been set to 1400. With this value everything works fine.
However, on eth0 its set to 1500 (default) and this is where the problems occur.

When I try to telnet from the LAN to the other side of the VPN, I can log in, but when I try to run Pine or do a 'ls', because the data to be transfered back to me is a lot, the session hangs.

At this point the only solution I can think of is to set eth0's mtu to 1400 but Im trying to avoid this. Is there any way I can setup the Gateway to perform its routing in a smarter way ?

Things to take in cosideration:

a)I do not want to chage the mtu's on any of the LAN hosts

b) I want to avoid changing Gateway's eth0 mtu to 1400.

Thanking you in advanced.

Chris P.

[Craig Gilmore]

This seems strange to me that the gateway is having problems breaking down and assembling the packets.

Have you run ethereal on the gateway to trace the activity? Just to confirm that the conversion is taking place.

Is there anything else running on the gateway that might take away CPU cycles from the network packet handling?

I'd want to confirm the behavior and then hammer redhat if it is not behaving as expected.

What you have described should work with the gateway rebuilding the large packets, and just passing through the smaller data from the customer.

[U.SivaKumar_2]

Hi,

Run these commands and see whether it makes any difference.

#echo "1" > /proc/sys/net/ipv4/ip_no_pmtu_disc

#echo "1" > /proc/sys/net/ipv4/ip_always_defrag

#service network restart

Try VPN again.

regards,

U.SivaKumar

[Ralf Puchner]

PMTU must be disabled on both sides behind the gateways. This mechanism tries to optimize the windowsize/packetsize and set the "don't fragment bit". This should be switched of if communication will be made over gateways/routers.

The other possiblity is to modify the route with a smaller packet size. You can modify this behaviour by assigning a specific packet size to the route command. So the packet size affects only this connection and not the whole adapter packet size.

[Tim Sanko]

Chris,

Our VPN is a Cisco, and we did go to 1400, when we had similar issues. It seemed the path of least resistance. I know that it is a major pain.

We had Cisco here to set up a demonstrator, and we bought into it. Last thoing I know we did was to change MTU to 1400 from 1500.

Tim

[Admin32]

Wouldn't it make more sence NOT to disable the Path MTU ?

This way a host or server can adjust their MTU size depending on the icmp notification they get.

Cheers,

[Ralf Puchner]

Lowering packet size and disabling pmtu is the right choice for connections outside of a local network. The pmtu algorithm is useless if using a router. Have a look into good network books for more information.

[Joost_4]

I have had this problem also. But i used OpenBSD as router. I fixed the problem by enabling 'scrub' in my pf filter configuration. This is a parameter to pf (packetfilter) that reorders packets and normalizes them.
I'm sure linux can do this too.