08-27-2009 12:54 AM - edited 03-04-2019 05:51 AM
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 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
Solved! Go to Solution.
08-27-2009 03:25 AM
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
08-27-2009 03:02 AM
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
08-27-2009 03:06 AM
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
08-27-2009 03:25 AM
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
08-28-2009 12:32 AM
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
08-28-2009 03:21 AM
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:
Specifically: "Object group-based ACLs are not supported with IPsec."
Best regards,
Peter
08-28-2009 03:25 AM
Duplicate post removed.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide