ipsec vpn with redundant 1841 WAN interfaces - telnet packet routing proble

jagoe · ‎09-29-2008

I have worked on this brainteaser for a long time with no success, so any new perspectives will be appreciated. It's a challenging config - you'll see why.

Hardware: Cisco 1841 Advanced Security Bundle

Interfaces: fa0/0 (internal network)

fa0/1 (backup internet connection, SDSL line) - fixed ip

WIC-ADSL-DG (primary internet connection, atm0/0/0.1 point-to-point ADSL line) - fixed ip

IOS: Cisco IOS Software, 1841 Software (C1841-ADVSECURITYK9-M), Version 12.4(13b)

Comments: Config uses SLA and tracking objects to insure failover internet connection from the two internet interfaces. There are two separate vpn address pools and client configuration groups, and vpn traffic is statically routed to the corresponding WAN interfaces.

Background:

o atm0/0/0.1 (primary internet connection) has a public ip address of aaa.aaa.aaa.aaa

o fa0/1 (backup internet connection) has a public ip address of bbb.bbb.bbb.bbb

o Internet ping hosts 4.2.2.1 and 4.2.2.2 are used by sla monitor 100 and sla monitor 200, respectively, to track reachability (and thereby, the internet connectivity of interfaces atm0/0/0.1 and fa0/1). Traffic to these ping hosts is statically routed.

o Crypto map SDM_CMAP_1 contains two client configuration groups (vpn-client-group_1 and vpn-client-group_2), each one with its own unique address pool (10.10.10.0/32 and 10.10.20.0/32). SDM_CMAP_1 is applied to both fa0/1 and atm0/0/0.1 Each address pool's traffic is statically routed back out through its designated interface, i.e. myvpnippool_1 source addresses go out on the fa0/1 interface while myvpnippool_2 source addresses go out on the atm0/0/0.1 interface

o The ipsec vpn tunnels are established using the Cisco vpn client software.

The problem symptoms:

o ipsec vpn tunnels can be established from the internet on both wan interfaces, individually and simultaneously. This is not a question of being able to set up and tear down tunneled vpn sessions.

o If both wan interfaces are up and connected to the internet, vpn connections on one of the interfaces (either atm0/0/0.1 or fa0/1) will allow pings and telnet sessions to the inside interface (fa0/0). However, vpn connections to the *other* interface will not allow ping or telnet to the inside interface. In the case of the latter, packets from the client are properly encrypted and transported via the tunnel, but no packets return from the tunnel endpoint on the 1841 as evidenced by the statistic that 0 packets are decrypted.

o It appears to be random which vpn connection will return traffic at any given point in time. Both 1841 tunnel endpoints will successfully route traffic to the vpn client - just not at the same time. Simultaneous tunnels to the two wan interfaces can be established and the ability to ping the fa0/0 inside interface will randomly "flip" back and forth between the two tunnels.

Excerpts from the 1841 startup-config: (see attachment)

hadbou · ‎10-03-2008

The inability to pass data on an established IPsec tunnel between a VPN Client and a PIX is frequently encountered when you cannot ping or Telnet from a VPN Client to any hosts on the LAN behind the PIX. In other words, the VPN Client and PIX cannot pass encrypted data between them. This occurs because the PIX has a LAN-to-LAN IPsec tunnel to a router and also a VPN Client. The inability to pass data is the result of a configuration with the same access control list (ACL) for both the nat 0 and the static crypto map for the LAN-to-LAN IPsec peer.

jagoe · ‎10-07-2008

Thank you for your reply. I am familiar with the problem you describe. In Feb 2006 I posted a solution to practically your same scenario. It is in the General section with the title "solution: PAT interferes with VPN routing".

The present problem I describe does not involve a LAN-to-LAN IPsec tunnel. Rather, it is the inability to simultaneously route encrypted packets into IPsec tunnels established on the two WAN interfaces.

Only one tunnel at a time will successfully route the traffic, despite the application of separate vpn address pools, PBR, separate vpn client configuration groups and static routes.

Any further ideas or suggestions are welcome.

singhsaju · ‎10-03-2008

I think the return packets are decided by following two routes that you have on the router.

ip route 10.10.10.0 255.255.255.0 fa0/1 permanent

ip route 10.10.20.0 255.255.255.0 atm0/0/0.1 permanent

so if you connect only VPN group 1 to fa0/1 and VPN group2 to atm0/0/0.1 interfaces then you should not see problem.

HTH

Saju

Pls rate helpful posts

jagoe · ‎10-07-2008

Thank you for your thoughtful reply. As you suggest, I only connect VPN group 1 to fa0/1 and VPN group2 to atm0/0/0.1 interfaces.

As you also point out,

ip route 10.10.10.0 255.255.255.0 fa0/1 permanent

ip route 10.10.20.0 255.255.255.0 atm0/0/0.1 permanent

should determine the egress interface for each address pool. But I have made an interesting discovery that disproves this assumption.

If I connect VPN group2 (ip pool 10.10.20.0/24) to fa0/1, I am still able to establish the tunnel and ping inside hosts. This is not what one would expect; it shows that the static route entry is ignored. If the static route were followed, these return packets would be routed out atm0/0/0.1 and I would never see them because my tunnel is on fa0/1.

I have even gone so far as to create separate crypto maps to apply to each interface:

crypto map myclientmap_1 client authentication list aaa-authenticated

crypto map myclientmap_1 isakmp authorization list aaa-authorized

crypto map myclientmap_1 client configuration address respond

crypto map myclientmap_1 65535 ipsec-isakmp dynamic mydynamicmap

!

crypto map myclientmap_2 client authentication list aaa-authenticated

crypto map myclientmap_2 isakmp authorization list aaa-authorized

crypto map myclientmap_2 client configuration address respond

crypto map myclientmap_2 65535 ipsec-isakmp dynamic mydynamicmap

interface FastEthernet0/1

crypto map myclientmap_1

interface ATM0/0/0.1 point-to-point

crypto map myclientmap_2

But the exact same problem persists.

Additional ideas are welcome.