Solved: IPSec VPN

bjssccouser · ‎08-27-2009

Hi,

I have an 1812 router running v12.4 IOS. The router acts as the edge router and VPN endpoint for our office. As well as providing internet conectivity, the router also has a couple of VTI's setup to our remote office.

I've setup an IPSec tunnel to our client. All traffic for this VPN needs to be patted to the outside interface IP address. The config on the router is below. With this config when I enable the crypto map on the outside interface, all outbound connectivity stops working. I'm assuming there's some misconfig somewhere causing this, but I'm not sure what it is.

Please can you assist?

Thanks

boot system flash c181x-advipservicesk9-mz.124-24.T1.bin

boot-end-marker

!

logging message-counter syslog

enable secret 5 $1$mUcI$H1JmalLncKID0HDCtoExh1

!

no aaa new-model

!

ip source-route

!

ip cef

ip inspect name ...

object-group network internal_subnets

192.168.1.0 255.255.255.0

!

object-group network vpnmap20_hosts

host x.x.x.x

crypto isakmp policy 10

encr 3des

hash md5

authentication pre-share

group 2

crypto isakmp key key address x.x.x.x no-xauth

crypto isakmp key key address x.x.x.x

crypto isakmp keepalive 10

!

crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac

crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac

!

crypto ipsec profile ipsec_profile_SiteA

set transform-set ESP-3DES-SHA

!

crypto map vpnmap 20 ipsec-isakmp

set peer x.x.x.x

set transform-set ESP-3DES-MD5

match address acl_vpnmap20

!

archive

log config

hidekeys

!

ip ssh version 1

!

track 10 interface Tunnel0 line-protocol

!

track 20 interface Tunnel1 line-protocol

!

track 30 interface FastEthernet0 line-protocol

!

track 40 ip sla 10 reachability

!

track 50 list boolean and

object 10

object 20

object 40

!

interface Loopback1

ip address 1.1.1.3 255.255.255.255

!

interface Tunnel0

ip address 10.255.255.254 255.255.255.252

ip nat inside

ip virtual-reassembly

ip ospf message-digest-key 1 md5 7 153D19580A2D7871

ip ospf cost 11081

tunnel source x.x.x.x

tunnel destination x.x.x.x

tunnel mode ipsec ipv4

tunnel protection ipsec profile ipsec_profile_SiteA

!

interface FastEthernet0

description Outside

ip address x.x.x.x 255.255.255.240

ip access-group acl_outside in

ip nat outside

ip inspect txinspect out

ip virtual-reassembly

speed 100

full-duplex

!

interface FastEthernet1

no ip address

shutdown

duplex auto

speed auto

!

interface Vlan1

description Inside

ip address 192.168.1.253 255.255.255.0

ip dns view-group default-list

ip nat inside

ip virtual-reassembly

ip ospf message-digest-key 1 md5 7 11260B5119155859

standby 1 ...

!

ip forward-protocol nd

ip route 0.0.0.0 0.0.0.0 x.x.x.x

no ip http server

no ip http secure-server

!

ip dns view default

domain timeout 2

domain retry 1

domain name-server 194.73.82.242

domain resolver source-interface Vlan1

ip dns view-list default-list

view default 10

ip dns server

ip nat inside source route-map rmap_nat interface FastEthernet0 overload

!

ip access-list extended acl_nat

permit ip object-group internal_subnets any

ip access-list extended acl_outside

permit tcp any host x.x.x.x eq 22

permit esp host x.x.x.x host x.x.x.x

permit udp host x.x.x.x host x.x.x.x eq isakmp

permit esp host x.x.x.x host x.x.x.x

permit udp host x.x.x.x host x.x.x.x eq isakmp

permit esp host x.x.x.x host x.x.x.x

permit udp host x.x.x.x host x.x.x.x eq isakmp

permit icmp host 194.72.17.23 host x.x.x.x echo-reply

ip access-list extended acl_vpnmap20

permit ip host outside_ip object-group vpnmap20_hosts

!

ip sla 10

icmp-echo 194.72.17.23

timeout 500

frequency 3

ip sla schedule 10 life forever start-time now

!

route-map rmap_nat permit 1

match ip address acl_nat

Peter Paluch · ‎08-27-2009

Hello,

I see. Thanks for letting me know about those multicasts.

You are saying that after you apply the crypto map to the outbound interface Fa0, all outbound connectivity seems to stop. That would suggest that the crypto map actually catches all outgoing traffic and tries to encrypt it.

A couple of suggestions:

1.) Can you try to rewrite your ACL acl_vpnmap20 to use simple IP addresses instead of object groups? That might simplify troubleshooting a bit as it removes one layer of indirection. Also try to enter "deny ip any any" in that ACL on its end and see if it reports any matches in "show ip access-lists".

2.) Can you try removing the IP Inspect configuration from the Fa0 interface for a moment and see if the traffic starts flowing? Sometimes the IP Inspect does not go well with certain configurations.

3.) Is also the router-originated traffic affected (e.g., pinging from router) or just the transit traffic?

Best regards,

Peter

View solution in original post

Peter Paluch · ‎08-27-2009

Hello,

There are two things I would like to ask you about your configuration.

First, you have a Tunnel interface that is already IPsec protected, thanks to the crypto profile ipsec_profile_SiteA. This alone is completely sufficient to IPsec-protect the traffic routed through that tunnel interface. Why do you additionally want to apply a crypto map to your outside interface? I do not see a reason for that.

Second, I have noticed that your tunnel uses a pure IPsec mode - no GRE encapsulation is used. That is fine for unicast traffic but I noticed that you are running OSPF through that tunnel and I am not sure if the OSPF will work over it because it uses multicasts to discover neighbors and propagate routing information. I do not know this for sure but the combination of GRE+IPsec has always been used, among others, to solve the problem with multicasts, as the IPsec traditionally did not support multicasts (though I am not sure about the current state).

Best regards,

Peter

bjssccouser · ‎08-27-2009

Hi, the VTI interface is for connectivity to a remote company office, whereas the standard IPSec tunnel is for connectivity to a client site.

The VTI does route multicast traffic as I am currently running OSPF over these tunnels.

Thanks

Peter Paluch · ‎08-27-2009

Hello,

I see. Thanks for letting me know about those multicasts.

You are saying that after you apply the crypto map to the outbound interface Fa0, all outbound connectivity seems to stop. That would suggest that the crypto map actually catches all outgoing traffic and tries to encrypt it.

A couple of suggestions:

1.) Can you try to rewrite your ACL acl_vpnmap20 to use simple IP addresses instead of object groups? That might simplify troubleshooting a bit as it removes one layer of indirection. Also try to enter "deny ip any any" in that ACL on its end and see if it reports any matches in "show ip access-lists".

2.) Can you try removing the IP Inspect configuration from the Fa0 interface for a moment and see if the traffic starts flowing? Sometimes the IP Inspect does not go well with certain configurations.

3.) Is also the router-originated traffic affected (e.g., pinging from router) or just the transit traffic?

Best regards,

Peter

bjssccouser · ‎08-28-2009

Hi,

suggestion #1 looks to have done it. Having removed the object group from the acl and just specified a specific entry, the SA now forms. object groups look to work for the NAT acl's but just not for the interesting traffic acl's.

Thanks for your help with this. I'll now get Cisco to close the TAC case we've had opened for 2 weeks on this issue.

Regards

Peter Paluch · ‎08-28-2009

Hello Alyas,

I am very happy you got it running. About that TAC case - well, I feel complimented :) But nevertheless, I suggest not closing the case yet. Let the TAC team know about the cause of your problem so that they are able to solve similar incidents more quickly in the future.

And - oh, I have just found it in the documentation:

http://www.cisco.com/en/US/docs/ios/sec_data_plane/configuration/guide/sec_object_group_acl.html#wp1058359

Specifically: "Object group-based ACLs are not supported with IPsec."

Best regards,

Peter

Peter Paluch · ‎08-28-2009

Duplicate post removed.