Split Tunnel Problem.

[Soeren Rosiak]

Hi there.

Just started playing with split-tunnelling.

So far so good.

I can access the server when Split-Tunnel is disabled, and my route looks fine. But can't access internet.

I can't access the server when Split-Tunnel is enabled, my route looks wrong. But can access internet.

I think it's my access list there's the problem(Also tryed reversing it).

access-list split_test extended permit ip host 4.4.4.4 10.10.253.0 255.255.255.0

group-policy test_policy attributes

split-tunnel-policy tunnelspecified

split-tunnel-network-list value split_test

I've read that i can't filter on ports when using Split Tunnelling, is this correct?

I've attached a quick drawing of the setup.       

Regards, Søren.

[Jouni Forss]

Hi,

In the Split Tunnel ACL you should tell the network towards which traffic should be forwarded to the VPN.

At the moment it seems you have not even mentioned your local network of 10.10.0.0/24

I would suggest using a Standard Type ACL

group-policy test_policy attributes

  no split-tunnel-network-list value split_test

no access-list split_test extended permit ip host 4.4.4.4 10.10.253.0 255.255.255.0

access-list SPLIT-TUNNEL standard permit 10.10.0.0 255.255.255.0

group-policy test_policy attributes

  no split-tunnel-network-list value SPLIT-TUNNEL

Then relog with the VPN Client and try again.

- Jouni

[Soeren Rosiak]

Hi.

Thanks for the quick response.

Not sure i understand you.

The client that dial's in should not have anything to do with the 10.10.0.0 network.

It get's a IP in 10.10.253.0/24. Only traffic destined for 4.4.4.4 should be sent through the tunnel.

That's why i would like to use a extended acl.

Am i missing something?

[Jouni Forss]

Hi,

Why would you want the user to use VPN Client connection to a destination IP address that is located in the public network? Couldnt he/she directly connect to that server through whatever Internet connection he/she is using? As this destination IP address according to the diagram has nothing to do with your actual network?

Or does the VPN user need to be visible to the server with a public NAT IP address belonging to the central VPN device?

- Jouni

[Soeren Rosiak]

Hi,

Client's dial into a ASA. Then connects through the ASA to a server with a public address assigned in our network.

Instead of connecting directly to the server's public address(With no encryption).

Both devices got global assigned addresses from our global address space. But the traffic flows inside our network(Instead of over the WAN).

So yes I guess the client needs to be natted to the WAN ip belonging to the ASA so the traffic from the server have a path back again.

Sorry if my drawing wasn't clear enough.

Regards, Søren

[Jouni Forss · Accepted solution]

Hi,

Then you could use the following version of above suggest configurations changes

group-policy test_policy attributes

  no split-tunnel-network-list value split_test

no access-list split_test extended permit ip host 4.4.4.4 10.10.253.0 255.255.255.0

access-list SPLIT-TUNNEL standard permit host 4.4.4.4

group-policy test_policy attributes

  no split-tunnel-network-list value SPLIT-TUNNEL

The above configuration would basically configure the VPN Client connection so that ONLY connections destined to the IP address 4.4.4.4 would be forwarded to the VPN connection from the user.

If I understood you correctly, the users traffic to the destination server would only be encrypted between the Client and the ASA. From there on in it would be just like any traffic between hosts on the external network. Unless ofcourse your ASA has a separate L2L VPN connection to the site where the server 4.4.4.4 is located.

Even if the above Split Tunnel ACL configuration is correct you would still need to handle the NAT for the VPN Client users. To determine the correct NAT configuration I would have to know the software version of your ASA and the current Dynamic PAT rule for internal users for example if the VPN users are supposed to use the same public IP address for their NAT IP address.

Also you will atleast have to add this configuration on the ASA

same-security-traffic permit intra-interface

This will allow the VPN users connections to enter through the "outside" interface and head out through that same "outside" interface. Without the above command configured it will not be possible even if all other configurations were correct.

- Jouni

Message was edited by: Jouni Forss (Typos in the post)

[Soeren Rosiak]

Hi Jouni.

Absoloutely correct.

I changed to the standard ACL and now it works.

I just don't understand why my extended didnt work, any explanation for this?

I was aware of the nat and intra-interface.

But thanks for stating this.

Regards, Søren

[Jouni Forss]

Hi,

Your configuration format should be correct for the Extended ACL. Though I personally use the Standard type ACL since its simpler in these cases.

Are you sure that you logged out and logged back in with the VPN Client AFTER you had made changes to the Split Tunnel ACL? Otherwise they wouldnt be applied to the VPN connection.

I tested the Extended ACL on my own ASA and it seems to work just fine with that too.

Naturally check the Routing section of the VPN Client software to confirm that it lists the host 4.4.4.4 in there instead of the actual VPN Pool.

Please do remember to mark a reply as the correct answer if it answered your question.

- Jouni

[gkonheiser]

Sorry to interrupt but I have a basic question on split-tunneling that I haven't been able to find an answer too, is it possible to configure a router running an EZVPN Client so only certain hosts form a subnet go thou the tunnel and all other traffic to the outside interface?

[Soeren Rosiak]

Hi,

Just tried again with the extended list.

Still doesn't work.

Switched back to the standard ACL and works flawlessly.

Pretty odd.

Yup i logged out made the change to the ACL and attributes and logged in afterwards.

I just find it pretty odd that the extended won't work.

Im running 9.1(1)4 on the test box, reloaded the box still the same.

Upgraded to 9.1(2)8 still the same. Guess i have to go with the standard ACL then.

Regards, Søren.

[Jouni Forss]

Hi,

I would probably next try the same VPN Client connection with another computer to rule out problems with the actual device (and its software).

I would also monitor the counters on both the VPN Client software and the ASA with command

show crypto ipsec sa

or

show crypto ipsec sa peer

And confirm if any traffic is coming to the ASA even. If it is then I would monitor the logs or probably run some "packet-tracer" commands to see if there is anything special in its output.

Please do remember to mark a reply as the correct answer and/or rate helpfull answers

- Jouni