Dual Wan : how to ensure that IPSEC traffic is limited to one specific WAN ? (867VAE)

[FrederiqueCD]

Hello,

In order to resolve performance issue, my customer has purchased a second ADSL line and is requesting to dedicate each line to specific traffic. We are trying to achieve that particular configuration :

In order to filter the VPN trafic, I have first tried to isolate VPN packets using ACL (UDP 500/4500/1701/esp) but the VPN client is not connecting (cf debug crypto isakmp trace enclosed). In order to ensure that the method was correct, I have also tried to route all UDP packets to the second WAN interface but (as one could have expected) we encournter several other problem like DHCP failures.

Here is the configuration used today as a wordkaround (we have installed a DHCP server on a host), but I'm desesperate to find help on that matter in oder to achieve that target configuration. Access-lists 122 and 152 shows the different filtering options used :

crypto isakmp policy 3
 encr 3des
 authentication pre-share
 group 2
!
crypto isakmp client configuration group vpngroup
 key **********
 domain local
 pool vpnclientspool
 acl SPLIT-TUNNEL
 netmask 255.255.255.0
!
!
crypto ipsec transform-set ESP-3DES-SHA1 esp-3des esp-sha-hmac 
 mode tunnel
!
!
!
crypto dynamic-map dynmap 10
 set transform-set ESP-3DES-SHA1 
!
!
crypto map clientmap client authentication list vpn_xauth
crypto map clientmap isakmp authorization list vpn_group
crypto map clientmap client configuration address initiate
crypto map clientmap client configuration address respond
crypto map clientmap 10 ipsec-isakmp dynamic dynmap 
!
!
!
!
!
interface ATM0
 no ip address
 shutdown
 no atm ilmi-keepalive
!
interface Ethernet0
 no ip address
 shutdown
!
interface FastEthernet0
 no ip address
!
interface FastEthernet1
 no ip address
!
interface FastEthernet2
 no ip address
!
interface FastEthernet3
 no ip address
!
interface GigabitEthernet0
 description WAN2 pour Tunnel
 switchport access vlan 123
 no ip address
!
interface GigabitEthernet1
 ip address 192.168.1.2 255.255.255.0
 ip mtu 1492
 ip nat outside
 ip virtual-reassembly in
 duplex auto
 speed auto
!
interface Vlan1
 description $ETH-SW-LAUNCH$$INTF-INFO-HWIC 4ESW$
 ip address 10.0.2.111 255.255.255.0
 ip mtu 1392
 ip nat inside
 ip virtual-reassembly in
 ip tcp adjust-mss 1352
!
interface Vlan123
 description WAN2 pour Tunnel
 ip address 192.168.2.2 255.255.255.0
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ip mtu 1492
 ip nat outside
 ip virtual-reassembly in
 crypto map clientmap
 crypto ipsec df-bit clear
!
ip local policy route-map UdpData
ip local pool vpnclientspool 172.16.2.71 172.16.2.90
ip forward-protocol nd
no ip http server
ip http access-class 23
ip http authentication local
no ip http secure-server
ip http timeout-policy idle 60 life 86400 requests 10000
!
!
ip nat inside source static tcp 10.0.2.200 21 interface GigabitEthernet1 21
ip nat inside source static tcp 10.0.2.200 80 interface GigabitEthernet1 80
ip nat inside source static tcp 10.0.2.100 8888 interface GigabitEthernet1 8888
ip nat inside source static tcp 10.0.2.100 8889 interface GigabitEthernet1 8889
ip nat inside source route-map NoNat interface GigabitEthernet1 overload
ip route 0.0.0.0 0.0.0.0 192.168.1.1
ip route 172.16.2.0 255.255.255.0 192.168.2.1
!
ip access-list extended No-Nat-Vpn-Client
 deny   ip 10.0.2.0 0.0.0.255 172.16.2.0 0.0.0.255
 permit ip 10.0.2.0 0.0.0.255 any
ip access-list extended SPLIT-TUNNEL
 permit ip 10.0.2.0 0.0.0.255 172.16.2.0 0.0.0.255
!
access-list 152 permit udp any eq isakmp any eq isakmp
access-list 152 permit udp any eq non500-isakmp any eq non500-isakmp
access-list 152 permit udp any eq 10000 any eq 10000
access-list 152 permit esp any any
access-list 152 permit tcp any eq 4500 any eq 4500
access-list 152 permit udp any eq 1701 any eq 1701
access-list 132 deny   udp any eq bootps any eq bootps
access-list 132 deny   udp any eq bootpc any eq bootpc
access-list 132 deny   udp any eq tftp any eq tftp
access-list 132 deny   udp any eq domain any eq domain
access-list 132 deny   udp any eq time any eq time
access-list 132 deny   udp any eq netbios-ns any eq netbios-ns
access-list 132 deny   udp any eq netbios-dgm any eq netbios-dgm
access-list 132 deny   udp any eq tacacs any eq tacacs
access-list 132 deny   udp any eq nameserver any eq nameserver
access-list 132 permit udp any any

mac-address-table aging-time 15
no cdp run
!
route-map UdpData permit 10
 match ip address 132
 set ip next-hop 192.168.2.1
!
route-map NoNat permit 10
 match ip address No-Nat-Vpn-Client
!
privilege exec level 7 show
!
line con 0
 login local
 no modem enable
line aux 0
line vty 0 4
 access-class 23 in
 privilege level 15
 login local
 transport input telnet ssh
!
scheduler allocate 60000 1000
!
end

Thanks in advance for your help.

[Richard Burts]

I believe that this will turn out to be an issue with several parts and that we do not have enough information to address some of the parts. You show us the router and its config. Your drawing shows customer edge 1 and customer edge 2 but tells us nothing about them. What are they? How do they function?

You have a static route that sends all traffic for 172.16.2 to the second ADSL interface. If that is not sufficient for the outbound traffic then perhaps you might try using a route map to send the VPN traffic to the second ADSL link.

HTH

Rick

[FrederiqueCD]

(erased : duplicate post)

[FrederiqueCD]

Hi Rick

Both CE routers are basic ISP routers which are simply configured to send all traffic to the next router.

Let me rephrase what I've tried :

- I've created a static route to send all traffic from vpn addres pool (172.16.2.0/24) to the 2d link

- I've filterd the IPSec traffic (acl 152) + route-map UdpData

- I've routed the localy generated traffic to the 2d link (ip local policy route-map UdpData)

After your suggestion I've added a route-map on inteface Vlan1 to send traffic from 172.16.2.0/24 to the 2d link. but it is still not working. I think that thre is a problem maybe with the ACL 152, since when I enlarge the ACL (see ACL 132) the VPN clients connects and the tunnel is established.

I believe the problem stands in IKE Phase 1. As you can see in the debug traces I've added in the first message :

*Jan  6 13:41:56.347: ISAKMP:(1005): sending packet to xxx.xxx.xxx.xxx my_port 500 peer_port 57302 (R) AG_INIT_EXCH
*Jan  6 13:41:56.347: ISAKMP:(1005):Sending an IKE IPv4 Packet.
*Jan  6 13:41:56.347: ISAKMP:(1005):Input = IKE_MESG_FROM_AAA, PRESHARED_KEY_REPLY
*Jan  6 13:41:56.347: ISAKMP:(1005):Old State = IKE_R_AM_AAA_AWAIT  New State = IKE_R_AM2

*Jan  6 13:42:01.455: ISAKMP (1005): received packet from xxx.xxx.xxx.xxx dport 500 sport 57302 Global (R) AG_INIT_EXCH
*Jan  6 13:42:01.455: ISAKMP:(1005): phase 1 packet is a duplicate of a previous packet.

While when the ACL 132 is used (with the exact same conf) :

*Jan  6 13:45:17.895: ISAKMP:(1006): sending packet to xxx.xxx.xxx.xxx my_port 500 peer_port 62279 (R) AG_INIT_EXCH
*Jan  6 13:45:17.895: ISAKMP:(1006):Sending an IKE IPv4 Packet.
*Jan  6 13:45:17.899: ISAKMP:(1006):Input = IKE_MESG_FROM_AAA, PRESHARED_KEY_REPLY
*Jan  6 13:45:17.899: ISAKMP:(1006):Old State = IKE_R_AM_AAA_AWAIT  New State = IKE_R_AM2

*Jan  6 13:45:18.023: ISAKMP (1006): received packet from xxx.xxx.xxx.xxx dport 4500 sport 62280 Global (R) AG_INIT_EXCH
*Jan  6 13:45:18.023: ISAKMP:(1006): processing HASH payload. message ID = 0
*Jan  6 13:45:18.023: ISAKMP:(1006): processing NOTIFY INITIAL_CONTACT protocol 1

I hope I have clarified the problem.

[Richard Burts · Accepted solution]

I believe that I see the problem with access list 152. You are assuming that both the source port and the destination port will be ISAKMP

access-list 152 permit udp any eq isakmp any eq isakmp
access-list 152 permit udp any eq non500-isakmp any eq non500-isakmp

but the debug output is clear that the port used by the remote is not the ISAKMP port

Jan  6 13:42:01.455: ISAKMP (1005): received packet from xxx.xxx.xxx.xxx dport 500 sport 57302

I suggest that you revise access list 152 to only check on one port matching ISAKMP.

HTH

Rick

[FrederiqueCD]

Hi Rick.

You were right the ACL was to strict.

I really thank you for your help.

Best regards

Frederique

[Richard Burts]

Frederique

I am glad that my suggestion was helpful. It is easy to assume that for ISAKMP that both ends will use the ISAKMP (or nonISAKMP) port. But clearly that is not necessarily the case. Thank you for marking this discussion as solved. This will help other readers in the forum to identify discussions that have helpful information.

HTH

Rick