|
| From: | Hongyi Zhao |
| Subject: | Re: [Pan-users] Pan2 doesn't work within the vpn environment? |
| Date: | Fri, 3 Apr 2015 22:38:48 +0800 |
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
_______________________________________________
Pan-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/pan-users
| [Prev in Thread] | Current Thread | [Next in Thread] |