IPsec Tunnel over Cable

r.d.schnitzer · ‎02-08-2010

We have several remote sites, each of which have an 1841 router in place. Their primary connection is a T1, and one of the ethernet ports on each router is connected to a Comcast cable modem configured to be in bridging mode. The problem is occurring for two of the five sites. When they disconnect their T1, traffic should route over the cable connection and the VPN to the main office should come up over that connection. They are actually able to traffic over the Cable connection, but their ipsec tunnel is not behaving as expected. Looking at the ipsec stats, I can see that both phases have completed. Both of the 1841s in question are able to encrypt and decrypt packets with the peer over the Cable connection. However, when I look at the ipsec stats on the headend ASA 5510, I find that it is encrypting traffic to the new peer address, but it is not decrypting any traffic from the new peer. To make things more confusing, one of the sites that is able to use their tunnel properly over both the T1 and Cable is using the same configuration, IOS, router, etc. and just a different Cable modem and IP addresses. One other difference to note is that I cannot telnet to the two routers at the remote sites having trouble with their tunnels over their Cable connections on the Comcast IP address until I shut or disconnect the T1 interface. For the other three sites with the same configuration, I am able to telnet to the FastEthernet port of the 1841s with the Comcast IP addresses configured on them even while all of the traffic is being routed over the T1. I already had Comcast verify that the modems are in bridging mode. Any ideas? The configuration for the 1841 router can be found below. Thanks!

version 12.4
service nagle
no service pad
service tcp-keepalives-in
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname Router
!
boot-start-marker
boot-end-marker
!
logging buffered 51200 warnings
no logging console
enable secret 5 xxxxxxxxxxxxxxxxxx
!
no aaa new-model
!
resource policy
!
memory-size iomem 25
clock timezone EDT -5
no ip source-route
ip spd mode aggressive
ip cef
!
!
!
!
ip tcp selective-ack
ip tcp path-mtu-discovery
no ip bootp server
no ip domain lookup
ip domain name yourdomain.com
!
!
!
!
!
!
!
!
crypto isakmp policy 10
encr 3des
hash md5
authentication pre-share
crypto isakmp key 6 xxxxxxxxx address y.y.y.y
crypto isakmp key xxxxxxxxxxx address z.z.z.z
crypto isakmp keepalive 15
!
!
crypto ipsec transform-set myset esp-3des esp-md5-hmac
!
crypto map unitymap 10 ipsec-isakmp
set peer y.y.y.y
set transform-set myset
match address 160
crypto map unitymap 100 ipsec-isakmp
set peer z.z.z.z
set transform-set myset
match address 170
!
bridge irb
!
!
!
interface FastEthernet0/0
ip address v.v.v.v 255.255.255.252
ip nat outside
ip virtual-reassembly
duplex auto
speed auto
crypto map unitymap
!
interface FastEthernet0/1
description LAN
ip address 172.20.70.1 255.255.255.0
ip nat inside
ip virtual-reassembly
duplex auto
speed auto
!
interface FastEthernet0/1/0
!
interface FastEthernet0/1/1
!
interface FastEthernet0/1/2
!
interface FastEthernet0/1/3
!
interface Serial0/0/0
ip address u.u.u.u 255.255.255.252
ip nat outside
ip virtual-reassembly
encapsulation ppp
crypto map unitymap
!
interface Vlan1
no ip address
!
ip route 0.0.0.0 0.0.0.0 Serial0/0/0 t.t.t.t
ip route 0.0.0.0 0.0.0.0 FastEthernet0/0 s.s.s.s 2
!
!
no ip http server
ip http authentication local
no ip http secure-server
ip http timeout-policy idle 60 life 86400 requests 10000
ip nat inside source route-map vpn interface Serial0/0/0 overload
!
access-list 111 deny   ip host 172.20.70.120 host a.a.a.a
access-list 111 deny   ip host 172.20.70.120 host a.a.a.b
access-list 111 deny   ip host 172.20.70.120 host a.a.a.c
access-list 111 deny   ip 172.20.70.0 0.0.0.255 172.20.0.0 0.0.3.255
access-list 111 permit ip 172.20.70.0 0.0.0.255 any
access-list 160 permit ip 172.20.70.0 0.0.0.255 172.20.0.0 0.0.3.255
access-list 170 permit ip host 172.20.70.120 host a.a.a.d
access-list 170 permit ip host 172.20.70.120 host a.a.a.e
access-list 170 permit ip host 172.20.70.120 host a.a.a.f
no cdp run
!
!
route-map vpn permit 10
match ip address 111
!
!
!
control-plane
!
bridge 1 protocol ieee
bridge 1 route ip
!
line con 0
line aux 0
line vty 0 4
password 7 xxxxxxxxxxxxxxxx
login
transport input telnet
line vty 5 15
password 7 xxxxxxxxxxxxxxxx
login
transport input telnet
!
scheduler allocate 20000 1000
end

b.julin · ‎02-09-2010

I've had weird problems with cable providers' deep packet inspection

stuff getting into encrypted streams and misidentifying them, but never

with ipsec, just ssh/etc. The telnet thing sounds like it may not be happy

with an asymetric route, which might be the same beast.

Maybe try forcing ipsec/UDP instead of ESP?

r.d.schnitzer · ‎02-16-2010

Anyone have any other thoughts on this problem?

r.d.schnitzer · ‎02-25-2010

It appears that problem is being caused by either AT&T or Comcast blocking ESP (Protocol 50) on one of their routers. Comcast started looking into it, but I don't expect to hear back from them since they don't really care. The Cisco TAC engineer I'm working with is going to help me setup a Cisco Easy VPN between the two points, and through the use of cTCP, we should hopefully overcome this problem. For posterity, if anyone else tries to go this route, you'll need to update the IOS router to at least 12.4(20)T to be able to use cTCP for the Easy VPN tunnel. I upgraded to 15.0(1)M, and tonight we will work on the setup.