05-07-2014 05:53 PM - edited 03-07-2019 07:22 PM
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
05-08-2014 02:28 AM
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.
05-08-2014 01:19 PM
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
05-08-2014 03:28 PM
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
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