I am trying to setup a IPSec hub at a colo center with multiple locations. The colo center has IOS 12.3 and all remote sites has 12.2. Most of the remote sites are on DHCP. Due to the hardware, 12.3 is not possible and DMVPN is not feasible. What I have come up with is to setup all remote sites on dynamic DNS with a loopback and setup a IPSec tunnel between the remote loopback host address and the central colo site loopback. On top of this loopback-loopback IPSec connection, I have the GRE tunnel turned on (as I now have a static host address which I can use for GRE). On the colo center, I have IP MTU 1400 on the GRE tunnel interface as well as "ip tcp mss-adjust 1360". On the remote sites, I only have IP MTU 1400 on the interface as "ip tcp mss-adjust" is not available on 12.2. The colo center assigned a /25 and I am doing NAT on the colo hub to "borrow" some official IP address for internal host for SMTP and HTTP. The physical interface (FE0/0) at the colo center has "ip nat outside" and all GRE tunnel has "ip nat inside". I have "ip nat outside source" to map all public Internet address to a local routeable /24 and then I have "ip nat inside source" to NAT the /25 colo assigned IP to my internal host. All the above worked great and ping/traceroute all passes. However, when public Internet is trying to accessing a NAT'd colo IP, the connection will hang after the first initialization. I did some tcpdump on all the network segment and it seems that all packet with DF bit set on the remote site were dropped silently by the remote routers on the ethernet interface. Those packet were never forwarded to the tunnel interface on the remote router. However, if I create a route-map to clear DF bit on the remote router for traffic with next hop interface on tunnel, everything works perfect. Can anyone help me out why the remote router is dropping packet with DF bit silently even the packet with DF bit is not large enough to break the MTU? Any suggestion is appreciated! Thanks!
The best solution to this problem is to have a properly set GRE IP MTU or GRE Path MTU in order to let network hosts (end stations) TCP stacks perform path-mtu-discovery. If this can't be reliably configured, a possible workaround is to force a low TCP segment size by either configuring a low MTU or a low MSS on the end stations or forcing the MSS negotiation to a low value with the command ip tcp adjust-mss along the path. This command is not supported by the Catalyst 6000 or c7600 family and must be deployed on a regular architecture.
DocumentationCode download linksGoalRequirementLimitationsSupported ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and UCS-E Blades:Step by Step ConfigurationConfigure one of the connectivity options to access the Cisco IMC from the n...
Firepower Threat Defense (NGFWv) on UCS E-series - Transparent Mode in HA
DocumentationCode download linksGoalRequirementLimitationsSupported ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and UCS-E Blades:Step by Step ConfigurationCo...
I am currently unable to specify "crypto keyring" command when configuring VPN connection on my cisco 2901 router.
The following licenses have been activated on my router :