[vpn-help] local lan access

Matthew Grooms mgrooms at shrew.net
Sat Jan 15 12:31:11 CST 2011


On 1/15/2011 5:10 AM, Romain De Rasse wrote:
> Hi Kevin,
>
> thanks for your answer. Id did a traceroute and I'm sure that the ping
> doesn't enter the tunnel and then comes back in the local lan through
> the tunnel.
> The wireless adapter of my laptop is desactivated.
>
> I found a solution, but it's not a good one : in order to prevent the
> local LAN access, there must be a route with next hop in the tunnel
> (that is, an Include Topology Entry) which match more precisely the
> local traffic than the directly connected route I can see using the
> "route print" dos command.
>
> For example, a client in the 192.168.0.0/24 LAN must have this Topology
> Entries (or something like that I tried it at work yesterday I'm not
> sure about the details) :
>
> - Type : Include
> - Address : 0.0.0.0
> - Netmask : 0.0.0.0
>
> AND
>
> - Type : Include
> - Address : 192.168.0.0
> - Netmask : 255.255.255.0
>
>
> This is a bad solution for me because the clients will be located in a
> lot of different local LAN address plans, and the configurations of the
> clients has to be the same in order to perform simple remote automatic
> installation. Moreover the users are not administrators, it will cause a
> lot of problems if they have to perform this little part of the
> configuration.
>
> I should check the source code and try to adapt it :) but I'm running
> out of time.
>

Romain,

That's probably the best your going to be able to do using our client. 
Most client's that can prevent local LAN access do so by blocking the 
traffic using a integrated firewall security policy which is provided by 
the gateway ( ala, Cisco VPN client ). The Shrew Soft client has a 
firewall of sorts ( has the ability to block traffic, etc ) but it's not 
sophisticated ( IP v4 only and lacks state tracking ) and is not pushed 
to the client from a gateway. As a result , you can't install arbitrary 
block policies but it may be a feature we can add in the future.

You could try adding all RFC 1918 addresses to your list to your policy 
list to cover the vast majority of client connections, but that's not a 
perfect solution.

Hope this helps,

-Matthew



More information about the vpn-help mailing list