Re: three privacy questions

["Etienne Zind" <etienne zind gmail com>]

2008/12/20 Chuck Anderson <cra wpi edu>:
> On Sat, Dec 20, 2008 at 09:21:50AM +0800, Etienne Zind wrote:
>> >> As iproute is already heavily used in NM, the blocking might be done
>> >> with `ip rule` or `ip route` ath can do `reject`,`unreachable` and
>> >> `prohibits` simulation.
>> >>
>> >> $ ip rule from all unreachable
>> >>
>> >> or
>> >>
>> >> $ ip route add unreachable default
>> >>
>> >> Should do the trick
>> >
>> > Interesting.  But it just occurred to me that we'd of course have to
>> > punch through so the VPN itself could re-connect, which might well be
>> > VPN-method specific.  OpenVPN can do both UDP or TCP, and the port # is
>> > specific to the server.  Thus, we'd have to know quite a bit about the
>> > VPN implementation to lock down the TCP/IP stack to only allow
>> > connections to the VPN server...
>>
>> Ok, you got me here, I don't know a lot about VPN's but here's my guess :
>>
>> As soon as we want to block the trafic remove all our default route(s)
>> and replace them with some "unreachable" or "reject" route according
>> to what kind of error we want to generate on outgoing trafic.
>>
>> Then we add a route to the VPN server, or all the IPs needed to setup the VPN:
>> $ route add $VPN_IP1 dev $VPN_DEV
>> $ route add $VPN_IP2 dev $VPN_DEV
>> ...
>>
>> And when the VPN is up and running, we add our default route(s) again
>
> Yes, VPN clients typically install a host-route to the VPN server.  It
> is definately worth implmenting the above, even if it is only a
> partial solution.  Many VPN servers have a unique IP address used just
> for VPN services--for those setups the above would effectively prevent
> non-encrypted traffic, since the VPN server wouldn't allow any traffic
> through until the VPN tunnel was set up.
>
> The rules could be locked down more for the cases where the VPN server
> IP is shared with other services, but I'm not sure how much sense it
> makes to put VPN-specific intelligence into NM.

Actually my concern here was more about avoiding to patch in some
`iptables` that could be a hassle to maintain, specially if the user
already uses it. Staying in the `ip route/rule` area just seemed a bit
less messy.

It's quite often people do not use `ip` at its full extent although it
is quite a powerful tool. Of course to filter connection port-wise
(the case you were describing where the VPN server offers other
services that should be blocked too) we reach `ip`'s limits. Here's
two possible workaround :

 `ip` can route according to TOS (I dunno if there is a standard TOS
for VPN setup connections)

 `ip` can route according to src IP (through a `ip add rule from
$MY_VPN_IP table $MY_TABLE) that does a jump to a specific MY_TABLE
routingtable if the host software (VPN client) did a bind on the
specific MY_VPN_IP address. Most of the applications do default bind
on "localhost" 127.0.0.1 so it should do the trick in most case.
Question remains, can we force the VPN client to bind on MY_VPN_IP ?


Etienne