IPSec VPN Issue on Dual Internet link ISR Router

[Leelan Abeyarathna H.]

Hi All,

I am having an issue with a site to site IPSec VPN Tunnel. Setup is as follows

host(10.0.10.200)---- subinterface(10.0.10.1)   ----router (2921)  --- interface G0/0 ----- > NATted for internet use

                                                                                           --- interface G0/2 ---- IPsec VPN Site to Site ------ Router --- 10.1.10.1/24(loopback)

What i am trying to archive is using one Interface for Normal Internet access and the other interface to create a IPSec Tunnel to remote site. This is a tempory Tunnel to migrate VMs without effecting user bandwidth.

Current status is my tunnel is up and i can ping to loopback on remote network from the router with the command

ping 10.1.10.1 source 10.0.10.1

but cant ping from the host behind the LAN interface. Seems like a NAT issue. but i really cannot find anything on the config that can cause (obviously there is something :-)  ).

REally appriciate if any ideas guys.

Thanks

interface Port-channel1

description --- Channeled to the Core Swith ---

no ip address

!

interface Port-channel1.1

encapsulation dot1Q 1 native

ip address 192.168.1.1 255.255.255.0

!

interface Port-channel1.10

description --- Server Gateway ---

encapsulation dot1Q 10

ip address 10.0.10.1 255.255.255.0

ip nat inside

ip virtual-reassembly in

!

!

interface Embedded-Service-Engine0/0

no ip address

shutdown

!

interface GigabitEthernet0/0

description ---- Link to Internode WAN ---

ip address 52.187.5.13 255.255.255.248

ip flow ingress

ip flow egress

ip nat outside

ip virtual-reassembly in

duplex full

speed 100

!

interface GigabitEthernet0/1

description $ES_LAN$

no ip address

duplex auto

speed auto

channel-group 1

!

interface GigabitEthernet0/2

description -- Link 2 for remote Network --

ip address 194.137.190.15 255.255.255.252

ip nat outside

ip virtual-reassembly in

duplex auto

speed auto

crypto map SITE2SITE

!

crypto ipsec transform-set SET-TELSTRA esp-3des esp-sha-hmac

!

crypto map SITE2SITE 10 ipsec-isakmp

description - VPN to Remote Site -

set peer 58.162.52.158

set transform-set SET-TELSTRA

set pfs group2

match address 101

!

!

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 flow-export version 9

ip flow-export destination 10.0.10.200 9996

!

ip nat inside source route-map NAT interface GigabitEthernet0/0 overload

ip nat inside source route-map NAT1 interface GigabitEthernet0/2 overload

i

ip route 0.0.0.0 0.0.0.0 52.177.5.17

ip route 10.1.10.0 255.255.255.0 GigabitEthernet0/2

!

ip access-list extended PERFORM_NAT

deny   ip 10.0.10.0 0.0.0.255 10.1.10.0 0.0.0.255

permit ip 10.0.10.0 0.0.0.255 any

!

logging trap warnings

logging 10.0.10.200

access-list 101 permit ip 10.0.10.0 0.0.0.255 10.1.10.0 0.0.0.255

access-list 102 deny   ip 10.0.10.0 0.0.0.255 10.1.10.0 0.0.0.255

!

!!

route-map NAT1 permit 10

match ip address 102

match interface GigabitEthernet0/2

!

route-map NAT permit 10

match ip address PERFORM_NAT

match interface GigabitEthernet0/0

!

[cadet alain · Accepted solution]

Hi,

can you first edit ACL 102 like this:

access-list 102 permit ip 10.0.10.0 0.0.0.255 any

Also it would be best to change your static route like this:

no ip route 10.1.10.0 255.255.255.0 GigabitEthernet0/2

ip route 10.1.10.0 255.255.255.0  x.x.x.x  where x.x.x.x is the next-hop on G0/2

Regards

Alain

Don't forget to rate helpful posts.

[Richard Burts · Accepted solution]

I agree with Alain that there is an issue with access list 102. The main issue is that with only a single statement which is a deny then there will be no traffic permitted and therefore no nat performed through the route map NAT1. I am not sure that I agree with his suggested change for the access list. I am assuming that the intent is to not do translation for the traffic going through the VPN tunnel and the current access list does deny that traffic. But the version suggested by Alain would permit any destination - including the subnet reached through the VPN.

Before I make a suggestion of what I think the access list should be I would like some clarification from the original poster. Is it true that the intent of interface Gig0/2 is to provide access for this VPN (there will not be other traffic going out this interface other than the VPN)? If that is the case then I question whether address translation is needed on the interface at all.

I certainly do agree with Alain that the static route needs to be changed to specify a next hop. And I wonder a bit if the static route may be a major part of the problem. As it is configured for the static route to work would require that the router connected through that interface would have proxy arp enabled. If the next hop router does not have proxy arp enabled then no traffic for remote addresses will be forwarded out the interface.

HTH

Rick

[cadet alain]

Hi Rick,

if the OP enters the command I provided it will not override the statement he already has it will just replace the implicit deny all with this permit so that non VPN traffic is natted but I agree with you after thinking that it shouldn't impact the VPN traffic.

Thanks for pointing that out.

Regards

Alain

Don't forget to rate helpful posts.

[Richard Burts]

Alain

Thanks for the clarification. I had interpreted your post suggestion to edit the access list as a suggestion to replace the existing statement. I agree that adding the statement you suggest will not translate VPN traffic and will translate other traffic. But I still wonder if other traffic will go out that interface. The route statements in his post do not have anything else pointed at this interface.

HTH

Rick

[Leelan Abeyarathna H.]

Morning All,

Alain, Richard Thanks heaps guys. Sorry for late reply.

got it working.

Alain - About the ACL change i didnt wanna change it to permit as intention was to avoid NAT for the intersting Traffic through the Tunnel. But to make it more sense i change the Route Map to deny and Permitted the ACL   ( same thing ). the important point was pointing the static route to the Next hop of the ISP on that interface as you pointed. This was the Fix.

Richard - Answer to your question was Yes - i wanted only this traffic to pass through the tunnel. Reason behind this setup is to build a Temporary Tunnle to move vmware VMs to a remote site without using bandwidth of the main internet link.

Following is the extract of the working config now for reference.

Thanks again guys.

interface Port-channel1

description --- Channeled to the Core Swith ---

no ip address

!

interface Port-channel1.1

encapsulation dot1Q 1 native

ip address 192.168.1.1 255.255.255.0

!

interface Port-channel1.10

description --- Server Gateway ---

encapsulation dot1Q 10

ip address 10.0.10.1 255.255.255.0

ip nat inside

ip virtual-reassembly in

!

!

interface Embedded-Service-Engine0/0

no ip address

shutdown

!

interface GigabitEthernet0/0

description ---- Link to Internode WAN ---

ip address 52.187.5.13 255.255.255.248

ip flow ingress

ip flow egress

ip nat outside

ip virtual-reassembly in

duplex full

speed 100

!

interface GigabitEthernet0/1

description $ES_LAN$

no ip address

duplex auto

speed auto

channel-group 1

!

interface GigabitEthernet0/2

description -- Link 2 for remote Network --

ip address 194.137.190.15 255.255.255.252

ip nat outside

ip virtual-reassembly in

duplex auto

speed auto

crypto map SITE2SITE

!

crypto ipsec transform-set SET-TELSTRA esp-3des esp-sha-hmac

!

crypto map SITE2SITE 10 ipsec-isakmp

description - VPN to Remote Site -

set peer 58.162.52.158

set transform-set SET-TELSTRA

set pfs group2

match address 101

!

!

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 flow-export version 9

ip flow-export destination 10.0.10.200 9996

!

ip nat inside source route-map NAT interface GigabitEthernet0/0 overload

ip nat inside source route-map NAT1 interface GigabitEthernet0/2 overload

i

ip route 0.0.0.0 0.0.0.0 52.177.5.17

ip route 10.1.10.0 255.255.255.0  194.137.190.17

!

ip access-list extended PERFORM_NAT

deny   ip 10.0.10.0 0.0.0.255 10.1.10.0 0.0.0.255

permit ip 10.0.10.0 0.0.0.255 any

!

logging trap warnings

logging 10.0.10.200

access-list 101 permit ip 10.0.10.0 0.0.0.255 10.1.10.0 0.0.0.255

access-list 102 deny   ip 10.0.10.0 0.0.0.255 10.1.10.0 0.0.0.255

!

!!

route-map NAT1 deny 10

match ip address 101

match interface GigabitEthernet0/2

!

route-map NAT permit 10

match ip address PERFORM_NAT

match interface GigabitEthernet0/0

*******

[Richard Burts]

I am glad that you got it working and that our suggestions were helpful. Thank you for posting back to the forum and letting us know that it is working and how you got it to work. This kind of feedback will be helpful to other readers in the forum. Thank you for using the rating system and marking this question as answered. This signals to other readers that there is helpful information here.

HTH

Rick