02-11-2014 07:34 PM - edited 03-04-2019 10:19 PM
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
!
Solved! Go to Solution.
02-12-2014 02:04 AM
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.
02-12-2014 07:36 AM
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
02-12-2014 02:04 AM
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.
02-12-2014 07:36 AM
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
02-12-2014 09:48 AM
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.
02-12-2014 10:12 AM
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
02-12-2014 02:52 PM
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
*******
02-12-2014 05:14 PM
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
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