Reverse Route

[Jimtron26]

Hi all,

I am trying to establish communication between multiple VPN spoke using the VPN hub as the centralised server.

The device I am using to terminate the VPNs at the central site is a 1751 cisco router running IOS 12.3(2). The clients all use Cisco VPN soft client programme installed on Windows machines.

The VPN protocol in use is IPSec. The router is configured to accept dynamic connections.

Once connected, remote peers can communicate with the central network with no problems, however, it they try to communicate with each other ie for a VoIP call, it does not work. I can not even get ICMP packets between two connected peers.

I researched into this and have come across a command to be entered in cyrpto isakmp client congiguration mode, which is the reverse-route command. Apparently this command is supposed to dynamically learn about connected peers and populate the routing table with the correct paths to reach them, however this does not seem to be working and I am ending up with multiple static routes dynamically entered into the routing table.

Does anyone have any knowledge of getting comms between remote connected IPSec clients?

Cisco`s site provides plenty documentation for PIX and concentrators however i cannot find anything on routers! Surely I am not the only person on the planet who wants two connected clients to be able to communicate via the VPN hub???!!!

Any thoughts more than welcome! If anyone knows a fix for this, I`ll buy them a pint!!

Regards

Jim CCNA

 

[burtsbees]

What is the WAN service?

Burt

 

[Jimtron26]

Hi Burt, thanks for replying, the WAN service is ADSL at both the VPN hub (1751 router end) and the remote peer.

A ping from a remote VPN connection to another remote connection ie 192.168.50.100 to 192.168.50.101 just seems to get swallowed up by the router

I read an article on Ciscos which said routers will not route traffic back out of the interface which it came in on, in this case a Dialer interface.

This is what Reverse Route Injection is apparently supposed to overcome!

Very frustrating

Many thanks,

Jim

 

[Jimtron26]

Situation seems worse!!

Changed reverse-route string to reverse-route remote-peer which adds 2 routes to the routing table. One for the connected peer via a public IP and a second stating how to reach the remote peer, via Dialer 1. Still cannot ping between connected hosts.

I now have 32 new static routes in my routing table which are all host addresses of IPSec clients from the IP VPN pool!! We have about 3 users who connect via VPN!! Cisco Command lookup tool advises that these routes should be removed as soon as an IPSec tunnel is torn down but this clearly isn`t the case, it is adding one whenever someone connects, and instead of deleting it, inserts a new one when they reconnect!

Also, a show crypto session command is showing the following

Interface: Dialer1
Session status: DOWN
Peer: X.X.X.X/500 (public IP of VPN client)
IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 host 192.168.50.138
Active SAs: 0, origin: dynamic crypto map
IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 host 192.168.50.138
Active SAs: 0, origin: dynamic crypto map
IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 host 192.168.50.138
Active SAs: 0, origin: dynamic crypto map
IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 host 192.168.50.138
Active SAs: 0, origin: dynamic crypto map
IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 host 192.168.50.138
Active SAs: 0, origin: dynamic crypto map
IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 host 192.168.50.138
Active SAs: 0, origin: dynamic crypto map
IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 host 192.168.50.138
Active SAs: 0, origin: dynamic crypto map
IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 host 192.168.50.138
Active SAs: 0, origin: dynamic crypto map

Multiple connection details for one connected host! It has never done this before!

Any ideas anyone?!

Thank you

Jim

 

[burtsbees]

Jim, I must admit, VPN's are not my strong point. I know that distance vector routing protocols, like RIP and IGRP, have split-horizon enabled by default, which is what will prevent routing updates to be sent out an interface in which the learned routes were received.
Two alternatives are disabling split-horizon (no ip split-horizon, on the interface level)---i.e.
router>en
router#conf t
router(config)#int di0(or whatever the dialer interface is)
router(config-if)#no ip split-horizon
Or the second alternative is to configure sub-interfaces, which the router sees as logical interfaces---this way, routing updates are sent out different sub-interfaces, but the same physical interface in both directions. For example, a route may be learned by an incoming update on interface dialer 0, but it can send the learned route via it's own update (every 30 seconds for RIP, 90 for IGRP) right back out interface dialer 0, but the router thinks it's interface dialer 0.1, or 0.2, or whatever. I can't remember how many sub-interfaces you can have, but I think it's at least 256. I don't even know if this is the issue, total shot in the dark. Are you using router RIP by chance, or IGRP, or EIGRP?

Burt

 

[helpdeskdan]

Split horizon will allow you to send routing updates out the interface it came in on, it's not for routing out the interface it came in on. No offense intended, Burt!

For static crypto maps, routes are always present if RRI is configured on an applied crypto map. We read that on:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123newft/123t/123t_14/gt_rrie.htm

So, I believe you need a dynamic crypto map.

http://www.cisco.com/univercd/cc/td...3/123newft/123t/123t_14/gt_rrie.htm#wp1027254

As we further read:
In the case of a dynamic crypto map, routes are created upon the successful establishment of IPSec SAs for those remote proxies. The next hop back to those remote proxies is via the remote VPN router whose address is learned and applied during the creation of the dynamic crypto map template. The routes are deleted after the SAs are deleted.

 

[Jimtron26]

Thanks for your responses guys, appreciated!

Burt, I am not currently implementing a routing protocol on our router (we only have one so no point!) but thank you.

Dan, the router is already configured for dynamic crypto maps as all remote users connect via the Cisco VPN client software on their PCs. An extract of the config is below:

crypto isakmp policy 15
hash md5
authentication pre-share
group 2
lifetime 43200
crypto isakmp keepalive 40 5
crypto isakmp nat keepalive 20
!
crypto isakmp client configuration group ********
key ********
pool VPN_IP_Pool
acl 143
!
!
crypto ipsec transform-set NCL_Tran_Set esp-des esp-md5-hmac
!
crypto dynamic-map NCL_Dyn_Map 1
set transform-set NCL_Tran_Set
reverse-route remote-peer
!
!
crypto map NCL_CMap client authentication list NCL_Authen
crypto map NCL_CMap isakmp authorization list NCL_Author
crypto map NCL_CMap client configuration address initiate
crypto map NCL_CMap client configuration address respond
crypto map NCL_CMap 20 ipsec-isakmp dynamic NCL_Dyn_Map
!

access-list 143 remark ISAKMP_ACL
access-list 143 permit ip 192.168.42.0 0.0.0.255 192.168.42.0 0.0.0.255
access-list 143 permit ip 192.168.51.0 0.0.0.255 192.168.51.0 0.0.0.255
access-list 143 permit ip 192.168.60.0 0.0.0.255 192.168.60.0 0.0.0.255

The NCL_CMap is applied on the Dialer 1 interface which terminates our ADSL. I have also tried adding 192.168.50.0 to the ACL above with no luck.

My RRI does not seem to be removing routes...

sh crypto sess
Crypto session current status

Interface: Dialer1
Session status: DOWN
Peer: 82.153.x.x/500
IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 host 192.168.50.138
Active SAs: 0, origin: dynamic crypto map
IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 host 192.168.50.138
Active SAs: 0, origin: dynamic crypto map
IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 host 192.168.50.138
Active SAs: 0, origin: dynamic crypto map
IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 host 192.168.50.138
Active SAs: 0, origin: dynamic crypto map
IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 host 192.168.50.138
Active SAs: 0, origin: dynamic crypto map
IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 host 192.168.50.138
Active SAs: 0, origin: dynamic crypto map
IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 host 192.168.50.138
Active SAs: 0, origin: dynamic crypto map
IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 host 192.168.50.138
Active SAs: 0, origin: dynamic crypto map

Interface: Dialer1
Session status: UP-IDLE
Peer: 86.134.x.x/50008
IKE SA: local 212.85.x.x/4500 remote 86.134.x.x/50008 Active

Only two SAs on the router and one of them is inactive yet I now have 37 new static routes in my routing table pointing at the IP addresses allocated to VPN clients!!

I wonder if it is a bug with the IOS im running - 12.3(2)... as you say, the command lookup tool states that routes will be removed when the SAs are torn down...

Thanks for your help, any further thoughts or comments would be appreciated

Kind regards,

Jim

 

[helpdeskdan]

As my friend Burt has said, we're mainly R&S guys here. We should have a pix/vpn forum. But, as we don't, and I'm enjoying learning new things, I'll try to help you.

In 12.3(14)T and later, they added the keyword "static" for routes to remain so when the SA went down. Maybe it is a bug in the IOS - I have to wonder if you upgraded to that version or later, perhaps that would help. Is that an option?

 

[Jimtron26]

Hiya Dan, and thank you for the post again

An IOS upgrade is an option however I have put a router in today and think (and pray) I have the answer!!

If I solve it, I will post on here and consider yourself and burtsbees one pint of lager better off!

Kind regards,

Jim

 

[helpdeskdan]

Well, if you don't solve it, be sure also to let us know so Burt and I can think about the matter further.

 

[plshlpme]

what does the routing look like for the clients when they connect? do they get a default route pointing to the tunnel?

 

[burtsbees]

Dan---split horizon says that a routing update cannot be sent out the same interface in which it came. But no offense taken.

Burt

 

[helpdeskdan]

Whoops! I meant to say "Split horizon will NOT allow you to send routing updates out the interface it came in on" However, if the next hop is out the same interface, I believe you can do that. It only applies to routing updates. Thanks for making me clarify that.

 

[Jimtron26]

hey plshlpme thanks for the reply,

The routing looks right according to RRI! Its just that they aren`t being removed from the routing table once IPsec sa`s are torn down

A static, (S), route appears in the routing table for the connected cliect, pointing at the public IP of the peer however there is also another route telling the router to get to the public IP via dialer 1 (internet interface).

I installed a router performing IPSec VPN the other day using DMVPN and RRI and this router is behaving itself but I have been unable to test ping between two connected peers. This router is removing the static routes as soon as the IPsec tunnel is torn down. This router is running 12.4(3g) as opposed to my 12.3(2) which is making me think an IOS issue here.

An upgrade is in order as well as further testing...

Thanks for the response

Kind regards,

Jim

 

[Jimtron26]

RESOLVED!!

Upgraded router to 12.4(12) IOS and RRI behaving as it should be. Now removing static IPSec routes when tunnels are torn down. My router had reached over 200 routes in the table for only 2 or 3 VPN clients!!! Not good!!!

To add to that though commands necessary are as follows:

Under dynamic crypto map:
#reverse-route remote-peer
This allows two routes - one for the VPN client`s VPN pool IP address pointing at the clients actual public IP address and the second for the clients actual public IP address pointing out of Dialer 1

On dialer interface:
#ip route-cache same-interface
Enables Fast Switching and allows for forwarding IP packets back out of the interface on which they were received (This has been the problem all along... by default IPSec will not allow an interface to route packets back out of itself, similar in a way to Split Horizon).

Under ISAKMP ACL
permit ip <remote VPN subnet> <remote VPN subnet>
Tells the connected client which subnets it can and can not access. This ACL is not a permit/deny ACL as such, more like a "if included then send encrypted packets through the VPN"

Well thats about it... it has taken me many painful months and several postings in this forum to get to the fix. Thanks to you both and everyone else for your thoughts!

Next time any of you are in Manchester, UK, please let me know and I will buy you that pint!

Thank you all very much and up the Reds!!!!

Jim