Site-to-Site IOS VPN - Unable to route after VPN+NAT

[JurgenKobierczynski]

Hello,

I have issues with an VPN on 2 Cisco 8xx access routers: I am trying to configure a quick and dirty Site-to-Site VPN with a source NAT on the VPN tunnel endpoint. This setup is only intended to run for a day inter site only. I have managed to make the VPN working, and I've traced NAT translations on the VPN tunnel endpoint, but I could not make these translated packets that have to route outside the access router, because the network the VPN traffic intended for is not directly connected, to leave the router. However, I can ping the directly connected hosts to the access router through the VPN .

Something makes the routing not to work, I don't think the NATing, because I've tried removing the NAT, and I couldn't trace any outgoing packets that have to be routed, so I am suspecting this capability is not included in the IOS of the Cisco 8xx routers series.

Am I stretching the VPN+NAT+Routing capabilities to much, or is there a configuration error in my setup?

This is the setup on the Cisco 8xx router (I provided only the VPN endpoint, as the VPN endpoint works)

VPN endpoints: 10.20.1.2 and 10.10.1.2

routing to 192.168.2.0 is needed from 192.168.1.2, routed to 192.168.1.254

NATing from 172.31.0.x to 192.168.1.x

!

version 12.4

no service pad

service timestamps debug datetime msec

service timestamps log datetime msec

service password-encryption

!

hostname INSIDEVPN

!

boot-start-marker

boot-end-marker

!

enable secret 5 xxxxxxxxxxxxxxx

!

no aaa new-model

!

!

dot11 syslog

no ip cef

!

!

!

!

ip domain name xxxx.xxxx

!

multilink bundle-name authenticated

!

!

username root password 7 xxxxxxxxxxxxxx

!

!

crypto isakmp policy 10

encr 3des

authentication pre-share

crypto isakmp key xxxxxxxxxxxxx address 10.20.1.2

!

!

crypto ipsec transform-set VPN-TRANSFORMS esp-3des esp-sha-hmac

!

crypto map CRYPTOMAP 10 ipsec-isakmp

set peer 10.20.1.2

set transform-set VPN-TRANSFORMS

match address 100

!

archive

log config

  hidekeys

!

!

controller DSL 0

line-term cpe

!

!

!

!

interface BRI0

no ip address

encapsulation hdlc

shutdown

!

interface FastEthernet0

switchport access vlan 12

no cdp enable

crypto map CRYPTOMAP

!

interface FastEthernet1

switchport access vlan 2

no cdp enable

!

interface FastEthernet2

switchport access vlan 2

no cdp enable

!

interface FastEthernet3

switchport access vlan 2

no cdp enable

!

interface Vlan1

no ip address

!

interface Vlan2

ip address 192.168.1.1 255.255.255.248

ip nat outside

ip virtual-reassembly

!

interface Vlan12

ip address 10.10.1.2 255.255.255.0

ip nat inside

ip virtual-reassembly

crypto map CRYPTOMAP

!

ip forward-protocol nd

ip route 192.168.2.0 255.255.255.0 192.168.1.254

ip route 10.20.0.0 255.255.0.0 10.10.1.254

ip route 172.31.0.0 255.255.0.0 Vlan12

!

!

no ip http server

no ip http secure-server

ip nat inside source static 172.31.0.2 192.168.1.11

ip nat inside source static 172.31.0.3 192.168.1.12

!

access-list 100 permit ip 192.168.1.0 0.0.0.255 172.31.0.0 0.0.255.255

access-list 100 permit ip 192.168.2.0 0.0.0.255 172.31.0.0 0.0.255.255

!

!

control-plane

!

!

line con 0

no modem enable

line aux 0

line vty 0 4

password 7 xxxxxxxxx

login

!

scheduler max-task-time 5000

end

[JurgenKobierczynski]

This is the NATing trace I've captured on the VPN endpoint access router (no trace of routing of this packet found):

*Jun 15 13:39:02.721: NAT*: s=172.31.0.2->192.168.1.11, d=192.168.2.27 [3969]

*Jun 15 13:39:07.730: NAT*: s=172.31.0.2->192.168.1.11, d=192.168.2.27 [3970]

*Jun 15 13:39:12.723: NAT*: s=172.31.0.2->192.168.1.11, d=192.168.2.27 [3973]

*Jun 15 13:39:17.728: NAT*: s=172.31.0.2->192.168.1.11, d=192.168.2.27 [3975]

Jurgen

[shamax_1983 · Accepted solution]

Hi Jurgen,

First of all, when I went through your config I saw these lines,

!

interface Vlan2

ip address 192.168.1.1 255.255.255.248

!

!

ip route 192.168.2.0 255.255.255.0 192.168.1.254

!

With 255.255.255.248 subnet, 192.168.1.1 and 192.168.1.254 will fall in to different subnets. So I don't think you can reach  192.168.2.0/24 subnet from the local router at this point.I think you should correct that first.

May be have 192.168.1.2 255.255.255.248 on the connected router (instead of 192.168.1.254)

Once this is done. We will have to look at routing.

You are natting 172.31.0.2->192.168.1.11

Now in order for this to work, make sure the NAT'd source addresses(192.168.1.11) is out of the router-router connected subnet ( if you go with 192.168.1.0/29 subnet for router-router , with 192.168.1.1/29 on the local router and 192.168.1.2/29 on the connected router as suggested, this will be fine ). So in this case your NAT'd sources are falling in to 192.168.1.8/29 subnet.

Have a static route on the connected router ( 192.168.1.2) for the 192.168.1.8/29 network pointing 192.168.1.1,

!

ip route 192.168.1.8 255.255.255.248 192.168.1.1

!

So the return packets will be correctly routed back in to our local router.

*** If you have an interface on the connected rotuer which includes the NAT'd source address range, let's say 192.168.1.254/24 , even if you make your packets to somehow reach 192.168.2.0/24, the return packet's will never forwarded to the the local router (192.168.1.1) because the connected router sees it as a connected subnet, so it will  just time out

I hope I understood your scenario correctly. Pleae make changes and let me know how you went with it.

Also, please don't forget to rate this post if helpful.

Shamal

[JurgenKobierczynski]

Hello Shamal,

Thanks for the proposed ideas, unfortunately this is not the problem because I've obfuscated the ip adresses and did forget to update the netmask of this subnet with it, so it was correct in the original config it is a /29 network and the route is inside the /29 subnet.

I have found the solution myself: I could ping the host 192.168.2.27 if I natted to 192.168.1.1, and adding a secundary ip's for 192.168.1.11 and 192.168.1.12 on interface Vlan2 solved my problem.

Thanks for checking!

Jurgen

[shamax_1983]

Hi,

Thanks for the update.
Good to know you figured it out.

I guess having secondary IPs on the interface makes the router reply to arp request made by the connected router (for the NATed ips ) for the reply packets. So you can get it done without the route on the connected router. Make sense! good one :)

Shamal