ASA **L2L** VPN - Disable Split Tunnel on Spoke

[eridavis22]

Greetings, 

I am looking for a configuration guide, tip, technote or similar for a configuration we are trying to implement.

Our HQ site has a redundant ASA 5555-X firewall pair (9.x) which operates as a VPN HUB for remote SPOKE sites; across the public internet.
The HUB site has many private IP address ranges internal and acts as the inbound and outbound internet gateway.

Our remote (SPOKE) sites have an redundant ASA 5505 pair (9.x) which have a single class-c and access the HUB through an ipsec tunnel across the public internet.

We are trying to implement a configuration where **All Traffic** originating from the SPOKE is sent to the HUB.
The HUB will then pass internal private subnet traffic to our internal router and all other traffic to the internet.

Meaning if a SPOKE site accesses an **internet** destination; the traffic will travel the ipsec tunnel to the HUB, and the HUB will then direct that request back out to the internet. (why: pass all internet traffic through a WSA, traffic logging and compliance enforcement)

I know there is an option to select split-tunneling for end user client solutions (AnyConnect/SSL/ipsec/etc) - This is for L2L.

Thank You - Eric

[Puneesh Chhabra]

Hi Eric,

You'd have to use "any" keyword in the crypto access list and then enable hair pinning on the HUB ASA for the internet traffic.

Let me know if you need help with configs

Regards,

Puneesh

[Christine_Lane]

I am experiencing something of a similar problem, although this involves a client with multiple IPsec VPNs to remote sites.

When we implemented the second VPN using the 'any' clause in the crypto ACL we suddenly lost traffic to the first site, which also included an 'any' clause in the their crypto ACL.

The original tunnel remained up but no traffic was going through.  Eventually we had to roll back the changes on the second tunnel in order to restore traffic to the first VPN.

Any idea on what caused this to happen?  And what can we do to provide full tunnels to the sites while continuing to direct traffic to the proper sites?

[Puneesh Chhabra]

Hi Christine,

Can you provide your crypto related configuration and what configuration you added for the second tunnel ?

Regards,

Puneesh

Please rate helpful posts

[Christine_Lane]

Hi Puneesh.

I've attached a file with the pertinent crypto information.

Here is the chronological sequence of events:

Four sites were involved: Oregon (the hub) and the UK, N. Calif., and S. Calif. (spokes).  N. Calif. and S. Calif. are full tunnels so that Internet-destined traffic traverses the tunnel.  Remote sites could only access selected resources behind the hub firewall.

Everything was working fine up to the point of the change.  What the client desired was for the remote sites to be able to access resources at other remote sites and maintain connectivity to the Internet using the full tunnels.  (Generally speaking the clients within the company would be able reach any other resource within the company no matter where located).

The changes had been made to the UK a month ago and it was working properly. 

We commenced to make the changes to N. Calif. and it appeared to be working correctly (Users could reach corporate resources and reach Internet sites).

We then proceeded to make the changes to S. Calif. but the tunnel would not come back up.

Somewhere in here it was noticed that we had lost connectivity to the UK which, as I mentioned, had been working correctly to this point.  The tunnel to the UK was still up but no traffic was flowing across.  It was noted that traffic was flowing out from the UK but no return traffic (i.e. from Oregon to UK) was going across the tunnel.

At this point we rolled back the changes for S. Calif. and N. Calif. and the UK began receiving traffic again.  S. Calif. also began transmitting traffic using the pre-change configuration.

Our suspicion is that the NAT statements that we put in 'grabbed' all of the traffic and directed it towards N. Calif., but we were not able to diagnose since we had rolled back.

I am also a little suspicious of the sequence of the crypto ACLs but unable to confirm.

We proposed site-to-site VPNs but auditing requirements stipulate that Internet traffic go through an IPS located behind the hub firewall.

So, the question is: how can we allow site-to-site communications between the spokes yet allow Internet (any) traffic through the hub.

Thanks.

[rizwanr74]

Hi Eric,

I assume you have static IPSec tunnel configured on each and every spoke to hub ASA.

On spokes ASA & hub ASA, you need to change Interesting traffic ACLs which is map to static crypto instance and change the destination to "any" on both ends hub and spokes as well, nat-exemption for private address base traffic on hub.  Since your spokes do not need dynamic nat anylong you remove.

example.

my spoke site a: access-list cryto-acl extended permit ip 10.10.10.0 255.255.255.0 any

on my hub site: access-list cryto-acl-4-A extended permit ip any 10.10.10.0 255.255.255.0

Secondly in order for remote-spokes to access to Internet, you need to create dynamic-nat on your hub ASA alone.

Hope that answers your question.

Thanks

Rizwan Rafeek.