Solved: GRE Tunnel Partial Traffic Blockage

meballard · ‎03-10-2008

We outsourced the encryption part of a VPN, but I recently setup a GRE tunnel between a 6500 and a 1811 router that passes through the VPN for EIGRP and full routing control (instead of being reliant on the SonicWall's rules).

This is setup as a hub and spoke method, the 6500 on the main campus is connected to a SonicWall. At that point all traffic managed by the outsourcing company, and passes through a VPN on the Internet to the remote site, which has another SonicWall, and is connected to an 1811.

I setup the two remote sites exactly the same (except for a difference of ip addresses), and went through and compared the configs to make sure they were basically identical. In both cases, almost all communication is working fine, EIGRP is passing routes, all traffic to the Internet is fine (which passes through the main site). VoIP phones are working fine, I was able to use AFP against a server, DNS is fine, DHCP is fine, a number of other services are fine, but on just one of the sites HTTP/S to internal sites is only partially working.

I did a tcpdump on both ends on the connection (Mac to a Linux server), and the initial packets make it through just fine. After the initial packets (enough to verify a SSL certificate, and sometimes a bit more), the Linux server will try to continue sending packets, but the computer on the remote side stops receiving them. Everything else, including HTTP/S connections to the Internet works fine. I tested turning off the ACL on the server subnet (the only place where a ACL is applied for this test currently, on the 6500), and it didn't make a difference.

Any ideas on where I could potentially start troubleshooting this/things to check for?

Richard Burts · ‎03-11-2008

Matthew

My guess would be that you have a fragmentation issue. When running GRE (and also with IPSec) adding the extra header to packets may produce packets that exceed the maximum size and require fragmentation. But if the IP header has the dont fragment bit set then the packet can not be fragmented and will be discarded. One way to address this is to use the adjst mss command (I typically do it on the LAN interface where users or servers are conneted). Try configuring:

ip tcp adjust-mss 1300

on the interface and see if it improves your problem.

HTH

Rick

HTH

Rick

View solution in original post

Richard Burts · ‎03-11-2008

Matthew

My guess would be that you have a fragmentation issue. When running GRE (and also with IPSec) adding the extra header to packets may produce packets that exceed the maximum size and require fragmentation. But if the IP header has the dont fragment bit set then the packet can not be fragmented and will be discarded. One way to address this is to use the adjst mss command (I typically do it on the LAN interface where users or servers are conneted). Try configuring:

ip tcp adjust-mss 1300

on the interface and see if it improves your problem.

HTH

Rick

HTH

Rick

meballard · ‎03-12-2008

Thanks, that solved it. I applied the command to both ends of the Tunnel connection (on the tunnel interfaces), and that seemed to have resolved the issue.

I also played with the number a bit, and was able to set it to 1380.

Richard Burts · ‎03-12-2008

Matthew

I am glad that you got it worked out and that my suggestion was helpful. In my experience the number can vary depending on some of the configuration parameters chosen. I suggested 1300 because it is a safe number that should always work if it was a fragmentation issue. I have frequently got it up to 1370 and 1380.

Thank you for using the rating system to indicate that your issue was resolved (and thanks for the rating). It makes the forum more useful when people can read about an issue and can know that they will read a solution that resolved the issue.

The forum is an excellent place to learn about Cisco networking. I encourage you to continue your participation in the forum.

HTH

Rick

HTH

Rick