cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
967
Views
0
Helpful
3
Replies

NAT translation issue when using IPsec VPN

dhananjay95929
Level 1
Level 1

Hello,

 

I have a VPN router that I am using to connect to a remote peer 3.3.3.3 and passing subnet 192.168.10.0/24 NAT'ed to 192.168.126.0/24 through the crypto ACL encryption domain.

The remote subnet is 10.192.0.0/12 and when sending packets from 192.168.10.0/24 towards the remote subnet the data reaches the remote subnet just fine as NAT'ed subnet 192.168.126.0/24. The NAT translation from inside to outside shows up just fine and the data reaches the remote subnet.

 

However, when remote subnet 10.192.0.0/12 sends packets towards NAT'ed subnet 192.168.126.0/24 the data does not reach the real subnet 192.168.10.0/24 on my end of the tunnel. The NAT translation from outside to inside never shows up. However, "show crypto ipsec sa peer 3.3.3.3" reveals that the decaps do increment inside the tunnel meaning packets do reach this router but no reverse translation from outside to inside occurs.

 

Can anyone spot what I am doing wrong?

 

Thanks!

__________________________________________________________________________

VPN-comp1-1#show run
Building configuration...
Current configuration : 4648 bytes
!
! Last configuration change at 00:22:55 UTC Thu May 8 2014 by xxxx
! NVRAM config last updated at 00:23:20 UTC Thu May 8 2014 by xxxx
! NVRAM config last updated at 00:23:20 UTC Thu May 8 2014 by xxxx
version 15.1
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname VPN-comp1-1
!
boot-start-marker
boot-end-marker
!
!
!
aaa new-model
!
!
aaa authentication login default local
!
!
!
!
!
aaa session-id common
!
!
no ipv6 cef
ip source-route
ip cef
!
!
!
!
!
no ip domain lookup
ip domain name xxxxxx.com
!
multilink bundle-name authenticated
!
crypto pki token default removal timeout 0
!
!
license udi pid CISCO1921/K9 sn FTX155284P7
!
!
username xxxxx secret 5 xxxxx
!
redundancy
!
!
!
!
!
track 1 interface GigabitEthernet0/1 line-protocol
!
track 2 interface GigabitEthernet0/1 line-protocol
!
track 3 interface GigabitEthernet0/0 line-protocol
!
!
crypto isakmp policy 1
 encr aes 256
 authentication pre-share
 group 5
!
crypto isakmp policy 10
 encr 3des
 authentication pre-share
 group 2
crypto isakmp key xxxxxx address 1.1.1.1 no-xauth
crypto isakmp key xxxxxx address 2.2.2.2 no-xauth
crypto isakmp key xxxxxx address 3.3.3.3 no-xauth
crypto isakmp keepalive 10 periodic
!
crypto ipsec security-association lifetime seconds 28800
!
crypto ipsec transform-set comp1 esp-aes 256 esp-sha-hmac
crypto ipsec transform-set comp2 esp-3des esp-sha-hmac
crypto ipsec transform-set comp3 esp-aes 256 esp-sha-hmac
!
crypto map comp 1 ipsec-isakmp
 set peer 1.1.1.1
 set transform-set comp1
 set pfs group5
 match address comp1
crypto map comp 2 ipsec-isakmp
 set peer 2.2.2.2
 set transform-set comp2
 set pfs group2
 match address comp2
crypto map comp 3 ipsec-isakmp
 set peer 3.3.3.3
 set transform-set comp3
 set pfs group2
 match address comp3_CRYPTO_ACL
!
!
!
!
!
interface Embedded-Service-Engine0/0
 no ip address
 shutdown
!
interface GigabitEthernet0/0
 ip address 192.168.10.5 255.255.255.0
 ip access-group comp3_test in
 ip nat inside
 ip virtual-reassembly in
 standby 1 ip 192.168.10.4
 standby 1 priority 50
 standby 1 preempt
 standby 1 authentication VPNCOMP
 standby 1 track 1 decrement 10
 duplex auto
 speed auto
!
interface GigabitEthernet0/1
 ip address 4.4.4.5 255.255.255.0
 ip nat outside
 ip virtual-reassembly in
 standby 2 ip 4.4.4.4
 standby 2 priority 50
 standby 2 preempt
 standby 2 name WAN
 standby 2 track 2 decrement 10
 standby 2 track 3 decrement 10
 duplex auto
 speed auto
 crypto map comp redundancy WAN
!
ip forward-protocol nd
!
no ip http server
no ip http secure-server
!
ip nat pool comp3_POOL 192.168.126.1 192.168.126.254 prefix-length 24 type match-host
ip nat inside source route-map comp3_TRAFFIC pool comp3_POOL
ip route 0.0.0.0 0.0.0.0 4.4.4.97
!
ip access-list standard SSH
 permit 192.168.10.0 0.0.0.255 log
!
ip access-list extended comp3_CRYPTO_ACL
 permit ip 192.168.126.0 0.0.0.255 10.192.0.0 0.15.255.255 log
ip access-list extended comp3_TRAFFIC
 permit ip 192.168.10.0 0.0.0.255 10.192.0.0 0.15.255.255 log
ip access-list extended NONAT
 deny   ip 192.168.10.0 0.0.0.255 10.32.0.0 0.0.7.255 log
 deny   ip 192.168.10.0 0.0.0.255 10.227.112.0 0.0.15.255
 deny   ip 192.168.10.0 0.0.0.255 10.52.228.0 0.0.3.255
 deny   ip 192.168.10.0 0.0.0.255 10.192.0.0 0.15.255.255 log
 permit ip any any
ip access-list extended comp1
 permit ip 192.168.10.0 0.0.0.255 10.32.0.0 0.0.7.255 log
ip access-list extended comp3_test
 permit ip 192.168.10.0 0.0.0.255 10.192.0.0 0.15.255.255 log
 permit ip any any
ip access-list extended comp2
 permit ip 192.168.10.0 0.0.0.255 10.227.112.0 0.0.15.255
 permit ip 192.168.10.0 0.0.0.255 10.52.228.0 0.0.3.255 log
!
!
!
!
!
route-map comp3_TRAFFIC permit 10
 match ip address comp3_TRAFFIC
!
!
!
!
!
control-plane
!
!
!
line con 0
 privilege level 15
 logging synchronous
line aux 0
line 2
 no activation-character
 no exec
 transport preferred none
 transport input all
 transport output pad telnet rlogin lapb-ta mop udptn v120 ssh
 stopbits 1
line vty 0 4
 access-class SSH in
 logging synchronous
 transport input ssh
line vty 5 1370
 access-class SSH in
 logging synchronous
 transport input ssh
!
scheduler allocate 20000 1000
end

3 Replies 3

Hello.

If you meant that 10.192.0.0 can't originate connection to 192.168.10 [126].x, then you might need to add "reversible" keyword in you NAT statement.

Thanks Vasilii. I think I am one step closer to solving this issue. I did add the reversible keyword to the pool but still I am unable to receive a ping response from the remote end subnet host 10.192.255.1 from local subnet source 192.168.10.5. The remote and local ends should be pingable and there are no issues with firewall blocking.

 

The crypto ACL for IPsec matches local NATed subnet 192.168.126.0/24 to remote subnet 10.192.0.0/12.

 

when sending the ping from source 192.168.10.5 the translation should happen to 192.168.126.5, match the crypto ACL, reach the remote subnet host 10.192.255.1, the remote subnet initiates a response towards 192.168.126.5, reaches the local end, gets translated to 192.168.10.5.

 

I think the last translation is what is not happening. Am I missing an inbound ACL?

 

As previously mentioned, when sending data from inside to outside ie from 192.168.10.5 to 10.192.0.0/12, the packets do reach the remote subnet. However, from 10.192.0.0/12 to 192.168.10.0/24 the packets don't make it to local subnet 192.168.10.0/24. 10.192.0.0/12 can only see 192.168.126.0/24. It gets translated to 192.168.10.0/24 on my local router. Traffic does reach this local router as I can see decaps incrementing in the ipsec SA. Its just that the traffic never reaches the 192.168.10.x subnet due to translation issue maybe even after adding the reversible keyword.

___________________________________________________

VPN-comp1-1#ping 10.192.255.1 source 192.168.10.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.192.255.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.10.5
.....
Success rate is 0 percent (0/5)


VPN-comp1-1#sh ip nat trans
Pro Inside global      Inside local       Outside local      Outside global
icmp 192.168.126.5:18  192.168.10.5:18    10.192.255.1:18    10.192.255.1:18
--- 192.168.126.5      192.168.10.5       ---                ---

___________________________________________________

 

ip nat pool comp3_POOL 192.168.126.1 192.168.126.254 prefix-length 24 type match-host


ip nat inside source route-map comp3_TRAFFIC pool comp3_POOL reversible

 

ip access-list extended comp3_CRYPTO_ACL
 permit ip 192.168.126.0 0.0.0.255 10.192.0.0 0.15.255.255 log

 

route-map comp3_TRAFFIC permit 10
 match ip address comp3_TRAFFIC

 

ip access-list extended comp3_TRAFFIC
 permit ip 192.168.10.0 0.0.0.255 10.192.0.0 0.15.255.255 log

 

Could it be because of the NAT order of operations that when packet is coming from outside->inside the route lookup happens first and then the NAT occurs?. Therefore when route lookup occurs there is no route in the table and therefore the RIB uses the default route which points to the outside interface but in fact the translation should happen on the inside interface?

 

I added a static route towards 192.168.126.0/24 network to the Gi0/0 inside interface. Still having the same problem though, cannot ping from 10.192.255.1 towards 192.168.126.5 neither can I ping from the inside 192.168.10.5 towards the remote 10.192.255.1 destination.

 

S     192.168.126.0/24 is directly connected, GigabitEthernet0/0

Review Cisco Networking products for a $25 gift card