SSL VPN route table on MacOS and Linux troubles (Windows ok)

ankama_network · ‎06-03-2010

Hi,

We have enabled SSL VPN for externals users.

Everything is just fine for Windows users but Mac and Linux users have some troubles :

When the local network of the clients is a subnet of the tunneled routes, traffic destinated to the addresses of the client network does NOT go through the VPN adapter.

Example :

client network :

192.168.0.0/24 gw 192.168.0.1

tunneled routes (split tunnel):

192.168.0.0/16

VPN address pool :

10.1.2.0/24

If a VPN client talks to an address that is not in 192.168.0.0/24 but in 192.168.0.0/16, traffic is OK through VPN.

If a VPN client talks to an address that is in 192.168.0.0/24, traffic does not go through VPN adapter.

The route tables at VPN start indicates

default -> 192.168.0.1 (client interface)

192.168.0.0/16 -> 10.1.2.x (VPN adapter)

For example, if I try to ping 192.168.0.200, the route table adds an entry :

192.168.0.200 -> 192.168.0.x (client interface)

Wheras it should even not appear (because of the second line in the above list)

Is there any way to change that behavior (the device is an ASA 5510) ?

Thanks

m.kafka · ‎06-04-2010

I'm afraid that's exactly how it should be:

if the local lan of the client is 192.168.0.0/24 then those routes will have alonger prefix and win over the shorter prefixes of the VPN-injected route.

That's how IP routing is described.

I can only assume that you are operating overlapping IP-networks:

For example, if I try to ping 192.168.0.200, the route table adds an entry :

192.168.0.200 -> 192.168.0.x (client interface)

192.168.0.200 is on the same network as the client according tou your client's interface configuration. So the route points to its own IP - that's normal and it must be like that for IP to work.

If you have another network on the other side of the VPN-tunnel with the same prefix then you must configure outside-nat to resolve the overlapping address conflict.

rgds,

MiKa

ankama_network · ‎06-04-2010

It is quiet understandble. But the same tunnel does not behave in the same manner under Windows.

The client is also the same version, so Windows behave the way it should not ?!

That's not right, Windows uses metrics and the tie breaker when a packet matches several routing rules is the metric.

Using address translation could do the job, but this is burden. It would say I must also do some DNS rewriting just for Linux and Mac users.