Internet access via hairpinning for Spoke to Hub IPSec VPN

[worf359]

I have a hub and spoke configuration with a number of site-to-site IPsec VPNs from 857's terminating on an 1811 at the hub. Also in the mix is a client-to-site (EZVPN) which also terminates at the hub.

I need to ensure all traffic destined for the internet goes out through the hub 1811. I've looked at trying to use a form of hairpinning so that "interesting traffic" from remote sites gets NATted at the hub router to the internet.

I have seen a number of configurations (in these forums) where internet-directed traffic from EZVPN clients is forced via a hairpin out via the hub router. I am trying to emulate that feature with the site-to-site IPSec VPNs - where internet directed traffic from spokes must go through the hub router, and not be permitted to go directly to the internet from the spoke routers.

Attached are configs for the hub router and one of the spoke routers, and a pdf diagram.

I can get traffic to the internet (in my test lab) from the lookback connector (1.1.1.1) by extended command pings, I have connectivity from the spoke1 lan to the hub lan (pings again); but not from the spoke1 lan to the internet via the hub router.

Thanks in advance for any help

Phil

[dschuckman]

Phil,

If I am following you correctly you need to modify your interesting traffic lists between the hub and spokes... For example. ACL 120 on your spoke is only permitting traffic for the private network on the hub side. You need to modify this so that ACL 120 says something like permit source/24 to any and on the hub side make the coresponding ACL say something like any to /24. This will allow all traffic to be forced acorss the tunnel back to the hub.

If this is what you are looking for and you have more questions let me know.

[Farrukh Haroon]

As David said, you need to change the crypto ACL on both ends, you can make it like this:

no access-list 120 permit ip 192.168.8.0 0.0.0.255 192.168.0.0 0.0.255.255 log

access-list 120 permit ip 192.168.8.0 0.0.0.255 any

Also you need to remove NAT, there is no need for NAT on the spoke side to make this work. You are already doing NAT on the HUB (for the internet).

Thirdly you need to check ACL 110, is it really permitting traffic sourced from the LAN?

And also check ACL 102 on the HUB router, does it permit this internet traffic from the spokes?

Here is an example on CCO for VPN clients:

http://www.cisco.com/en/US/products/sw/secursw/ps2308/products_configuration_example09186a008073b06b.shtml

Regards

Farrukh

[worf359]

Thanks, guys. Yes, those two access lists did need some attention.

I've changed the access list on the spoke router from

access-list 120 permit ip 192.168.8.0 0.0.0.255 192.168.0.0 0.0.255.255

to

access-list 120 permit ip 192.168.8.0 0.0.0.255 any

which allows traffic from the spoke lan out to the internet via the hub router. I've also taken NAT off the spoke router.

But I also need to change the matching access list on the hub router. I changed the old access list from

access-list 121 permit ip 192.168.0.0 0.0.255.255 192.168.8.0 0.0.0.255

to

access-list 121 permit ip any 192.168.8.0 0.0.0.255

but I couldn't pass any traffic over the VPN. If I remove access-list 121 completely, then traffic does pass, but the crypto map on the hub router becomes "incomplete".

When the tunnel is up, and passing traffic, I can ping an internet address (in my lab), but not all traffic is getting through. Every second ping times out, often there are 3 or 4 pings that time out.

Any suggestions as to what to do with the access list (121) on the hub router, and what can I do to get more reliable results (i.e. get every ping to work)?

TIA

Phil

[dschuckman]

Phil can you repost the configs... There are a few possible things that could be happening... The first place I would be looking is to make sure that the device is not trying to arp for the destination before using the default route. This can happen if you just say ip route X.X.X.X to the interface, or if you have a route statement that points to the wrong next hop address...

Thanks,

David

[worf359]

Configs attached. Thanks for your help.

Phil