Re: [Pan-users] Pan2 doesn't work within the vpn environment?

[Duncan]

Hongyi Zhao posted on Fri, 03 Apr 2015 16:23:33 +0800 as excerpted:

> Are there any workarounds for this case if I want to use Pan2 under vpn
> environments?

I had a reply mostly composed earlier, but then decided I didn't know 
enough about your intent and was making too many unwarranted assumptions 
in the post as it was written, so I killed it without sending.  This time 
I'll use two questions and explain the results of both answers, for both, 
avoiding that problem.


I should however mention that I don't claim to be a routing expert and 
have basically no experience at all with VPNs.  Tho I know a reasonable 
amount about IPv4 basics including routing in general, see that you are 
on debian and can read the route manpage.  So this should at least help 
to point you in the right direction, tho I can't guarantee all the 
details are exactly correct.  This is exactly where I'd be starting were 
I in this situation, except that /were/ I in this situation, I'd probably 
already know more about VPNs as I'd have at least setup the VPN, already, 
something I haven't at this point actually ever done.  So you're ahead of 
me in that aspect. =:^)


OK, so the route table you posted earlier was this:

> address@hidden:~$ ip route
> 0.0.0.0/1 via 10.211.38.206 dev tun0
> default via 192.168.0.1 dev eth0  proto static
> 10.211.38.206 dev tun0  proto kernel  scope link  src 10.211.38.205
> 58.19.210.249 via 192.168.0.1 dev eth0
> 128.0.0.0/1 via 10.211.38.206 dev tun0
> 192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.3


The two link-scope routes are:

192.168.0.0/24 dev eth0 src 192.168.0.3
10.211.38.206 dev tun0 src 10.211.38.205

The 192. route is your ethernet/LAN route, standard 192.168.0/24 (256 IP 
subnet), with the .3 address being the assigned local machine ethernet IP 
address.

The 10. route is the point-to-point established over the VPN, .205 being 
the local machine tun0 address, .206 being the remote address.  The lack 
of a mask means it's point-to-point, the equivalent of a /32 or 
255.255.255.255.  Only packets to .206 specifically, get routed that way.


The other two routes on the raw ethernet 192.168.0/24 subnet are:

default via 192.168.0.1 dev eth0
58.19.210.249 via 192.168.0.1 dev eth0

192.168.0.1 is obviously the local gateway, likely your router.

The first route is the default route, taking anything not specifically 
routed elsewhere.  This would be your normal internet route.

The 58. route is point-to-point.  Based on your VPN config, 58.19.210.249 
is the VPN-external remote host IP of your VPN, the machine to which you 
connect to establish the VPN.


That leaves the other two routes on tun0, the VPN itself.

0.0.0.0/1 via 10.211.38.206 dev tun0
128.0.0.0/1 via 10.211.38.206 dev tun0

The .206 address is the VPN-internal remote host on the VPN, with these 
routes using it as their gateway.

The one-bit bitmask indicates that the network each of these routes is 
half the IPv4 address space, with 0.0.0.0 being the first address of the 
bottom half, while 128.0.0.0 is the first address of the upper half.  
Combined, therefore, these have the effect of overwriting the default 
route, so nothing that would have fallen back to it routes to it, as it 
is instead routed via one of these routes thru the VPN to the 
gateway .206 machine at the other end.

These two routes, then, are what is causing everything to route thru the 
VPN.


The big question is then, is this what you intended, use this VPN for all 
your not otherwise specifically routed access to the net, or not, all not 
otherwise routed traffic you still want using the default route?

In your original post, you said the problem occurs when you are using a 
VPN method to access the internet.  That implies that you INTEND to route 
over the VPN everything not otherwise specifically routed, in which case 
the above routes are correct.

If, however, you only want specific traffic routed over the VPN, with 
anything not specifically routed over it, routed over the previous 
default route instead, then those two routes are wrong and should be 
deleted, with a more specific replacement route for just what you intend 
to route to the VPN, created instead.

As I said I'm no expert, but for this second case, based on the logged 
route commands you posted and the route manpage, and assuming you want to 
route only traffic for the 10/24 network (mask 255.255.255.0) to the VPN, 
I can guess the route delete and add commands might look like this:

route del -net 0.0.0.0
route del -net 128.0.0.0
route add -net 10.211.38.0 netmask 255.255.255.0 gw 10.211.38.206

Of course you'd adjust that netmask as appropriate for the vpn.
If it were the entire 10/8, you'd use a netmask of 255.0.0.0.


Back to the (almost) everything-over-the-vpn case, since that's what your 
first post implied you wanted and I've not covered it yet.  In that case, 
there's another question, what about the nntp connection?  Did you want 
it over the vpn as well, or did you want it bypassing the vpn, direct on 
the ethernet connection?

If you wanted it over the VPN, then your vpn must be setup to allow nntp 
traffic, something that's apparently not the case now.  You'd have to 
contact the people who provide you the vpn connection service and ask 
them to enable it, out of scope for a post such as this.

If however you want nntp to bypass the vpn despite all your other traffic 
not otherwise routed being routed thru it, then you need to setup a 
specific exception route direct over the 192. ethernet connection.  
Again, while I don't claim to be an expert, based on the information 
available, the command for that might look something like this.

route add -host news.rusnet.ru gw 192.168.0.1

Of course, with this option the nntp connection will be in-the-clear 
direct over the normal ethernet connection, NOT over the encrypted VPN.  
If that's what you intend, as may well be the case if only supposed to be 
an employment related vpn or the like, great, but if for instance you're 
attempting to use the VPN to avoid local ISP level censorship or tracking 
of your nntp connection, you really must talk to the vpn service provider 
and arrange for them to allow it, instead, because this option won't 
cover it.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman