VPN Tunnel settings - MTU?

[steveredman]

Hello,

I have set up a VPN tunnel from my company to another. We have a Cisco 1801 and they have a Watchguard Firebox. The VPN is up fine, able to ping and laptop users can log on to their domain from here and vice versa.

The only thing that does not want to work over the VPN (that I've found so far) is SMTP. I can telnet from my mail server (on the Cisco side) to the other (on the Watchguard side) but not the other way. I noticed that when doing a large ping I can get bigger packets from the cisco to the watchguard than I can the other way without them needing to be fragmanted. ie:-

From server on cisco side:-
ping 192.168.1.9 -f -l 1417

Pinging 192.168.1.9 with 1417 bytes of data:

Reply from 192.168.1.9: bytes=1417 time=92ms TTL=127
Reply from 192.168.1.9: bytes=1417 time=90ms TTL=127
Reply from 192.168.1.9: bytes=1417 time=89ms TTL=127
Reply from 192.168.1.9: bytes=1417 time=68ms TTL=127

From server on watchguard side:-
ping 10.0.0.6 -f -l 1417

Pinging 10.0.0.6 with 1417 bytes of data:

Reply from 192.168.1.253: Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

Is there a way to drop the MTU from the cisco side (just for the VPN) to 1416 to match the watchguard? Is this likely to solve the problem?

Thanks

Stephen

 

[burtsbees]

on the outgoing interface

ip tcp adjust-mss 1376

or

ip mtu 1416

/

tim@tim-laptop ~ $ sudo apt-get install windows
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Couldn't find package windows...Thank Goodness!

 

[VinceWhirlwind]

If it is the MTU size that is upsetting your SMTP application, then changing the max allowed MTU size on your router changes nothing - your application will still be trying to send larger MTU sizes and all you will have done is change the source of the "fragmentation needed but DF bit set" ICMP messages.

It is on the SMTP server itself that you need to adjust the MTU size, BUT, the normal network behaviour should see this server adjust its size itself so don't change anything before checking your server's registry keys that determine MTU size.

All Windows OSs since NT support MTU size adjustment and Unix-based OSs should all mostly support it as well.

 

[burtsbees]

DrTCP is a great app for Windows. You will also maybe need to adjust the NIC in the registry...not sure how (can't remember)---likely, you'll not have to, but the option is there if you do need to.

/

tim@tim-laptop ~ $ sudo apt-get install windows
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Couldn't find package windows...Thank Goodness!

 

[VinceWhirlwind]

Yes to Burt - "likely you'll not have to".
It's one of my pet-hates, all this talk about MTU sizes - most "MTU size" problems are in fact very simply a problem with inappropriate firewall rules blocking ICMP.

*This* problem here though, let's call it "ONE-WAY SMTP", could also be a firewall problem?

Can the two servers SMTP each other over a non-VPN link?
(Can you connect them directly by ethernet to test them?
Does the Cisco-side SMTP server actually receive the SMTP connection request in the first place? (Obviously you're not getting as far as a HELO?)
Is there a security setting on the Cisco-side SMTP server set against particular classes of connection attempt origins?

 

[steveredman]

Good morning,

Thanks for all the replies.

The server on the receiving end of the problem (Cisco side) has an external IP mapped to it's internal address to forward SMTP from the outside world. The server at the other end can SMTP to it via this over the internet. The firewall list on the Cisco allows all IP traffic from the Watchguard network to come to the Cisco network, ie:

access-list 160 permit ip 192.168.1.0 0.0.0.255 10.0.0.0 0.255.255.255

Strange thing is I've just tried turning on all the logging for my access list 160 and nothing shows up in the logs at all for traffic between the internal addresses (over the VPN). Is this right? I know traffic is getting back and forth so am I looking in the wrong place?

Thanks

 

[steveredman]

Ok

Looks like it's down to some shoddy NAT translation going on. I'm still not 100% on what should happen here. I asked the question a while back on this forum as thread557-1556024 and made some changes.

I'll try to figure it now, guess I do need those route maps after all!

 

[steveredman]

I've added route maps on to my NAT rules and all seems to be ok now.

Thanks guys.

 

[burtsbees]

If you did sh ip nat trans *
and
sh access-list

You'd see how many matches on acl 160.

/

tim@tim-laptop ~ $ sudo apt-get install windows
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Couldn't find package windows...Thank Goodness!