You are not logged in.
I have Arch running on a home server that works as our router, with iptables and dnsmasq. The interfaces are:
lo
enp0s6 - internet facing
enp0s4 - internal LAN (1.1.1.0/24)
This all works nicely (yes, even with my whack subnet) and I haven't had any problems. I'm attempting to add a VPN service that uses OpenVPN. I'm not an expert ip routing, so perhaps I have the wrong idea. I'd like to route traffic over the VPN, but not all traffic. I've heard that it is possible to route certain users traffic (via iptables), or certain applications (via binding to the VPN's TUN interface). Which is better or easier to configure?
So I've installed openvpn and configured it, and connected to the VPN service successfully, as far as I can tell. By default, it adds routes that seem to try to route all my traffic over the VPN, which broke at least DNS for the entire LAN. (See: https://bbs.archlinux.org/viewtopic.php?id=169130 ). I removed those routes for now so my internet works while I figure this out over the next few days.
One useful link I found was this one for splitting my internet access into two providers, which I'm currently going through and setting up for my specific case: http://lartc.org/howto/lartc.rpdb.multiple-links.html
But does that apply when the TUN device goes over my enp0s6 internet facing interface? Or is that part behind the scenes?
Offline
I'd start out by changing your LAN address range to a private, non-routable one. Once your router gets a packet destined for 1.1.1.18, how is it supposed to know on which IF to route it?
But still, never mind that. The instruction, within server.conf, that is responsible for routing all traffic through your OpenVPN router is
push "redirect-gateway def1"If you get rid of this, any client will route all normal traffic thru regular routing (i.e., outside the VPN), and only local traffic (i.e., that destined to your LAN) thru the
VPN.
Once again, when your client tries to route a packet to 1.1.1.18, how is it supposed to know that you mean to reach your private subnet, rather than the public one? It seems to me this is only a source of confusion, and possible error.
Also, in the long run, the instruction above will cause some problems. After some connection time, all pcs must renew their DHCP leases, which they do by contacting the local DHCP server. But, if you have the instruction above, the VPN client will route your lease renewal request over the VPN, and the rquest will never reach your local DHCP server, your lease will expire, and you will lose connectivity. In my opinion, this is the root of your DNS problems, not the routing problems which you mentioned in your separate post.
As for your last guide, it is just a guide to policy routing, nothing mysterious about that. In my lab, we have several routers connected thru dedicted OpenVPNs to sister labs to facilitate data exchange. Plus, there is another router handling all normal traffic. Routing is done by means of policy routing, with several independent routing tables. It's a common configuration.
Cheers
Offline
I will change my subnet back to a more sane one. It was fun as an experiment, but the novelty has worn off.
I do not have a server.conf, I am using the client.conf provided by my VPN provider. Also, I, ideally, want just a separate VPN interface that I can bind certain programs to use. Or, if that's not an option I'd like to setup iptables to route traffic from certain users through the VPN. Otherwise, I want all traffic not specifically bound to the VPN interface to go through my normal interweb interface. Do I need to set up openvpn as a server to do this?
Also, the DNS issues only appeared right after starting the openvpn service, and went away right after removing it. I'll know for sure when I change my subnet, but it looks like the 0.0.0.0/1 route overrides everything, no?
Last edited by krovisser (2013-09-05 14:06:55)
Offline
I will change my subnet back to a more sane one. It was fun as an experiment, but the novelty has worn off.
Good, I believe this is a sensible choice, at least it will clear the air of any remaining suspicion that your routing problems may arise from mismanagement of the local network configuration. I suggest you pick, for your LAN, something like 192.168.xxx.0/24, where xxx is 1 < xxx < 255, but something fancy. This will minimize the chances of conflict with other private subnets, should you connect to your home from an Internet cafe', a hotel, your school/job environment. Most private subnets are 192.168.0.0 or 192.168.1.0, and you want to avoid those numbering schemes.
I do not have a server.conf, I am using the client.conf provided by my VPN provider.
Thanks for pointing this out, I had not understood this. However, the one responsible for channeling ALL traffic through the VPN is your VPN provider, and I don't think there is anything you can do about that, from the client side. This is quite reasonable. If your provider did not push to clients the option "push "redirect-gateway def1", he would be providing access only to his LAN, which I am sure is not what you are paying top dollars for. By using that instruction, he ensures that you are using his internet access as a springboard for whole Internet access: what you get in exchange is that he makes it look like your traffic is coming from his IP, which, presumably, grants you access to services not otherwise available to you.
Also, I, ideally, want just a separate VPN interface that I can bind certain programs to use. Or, if that's not an option I'd like to setup iptables to route traffic from certain users through the VPN. Otherwise, I want all traffic not specifically bound to the VPN interface to go through my normal interweb interface. Do I need to set up openvpn as a server to do this?
The openvpn server would be useful to you to connect securely to your private LAN from outside, or if you wish to maintain secrecy and security while surfing the Net in potentially dangerous situations, like a hotel, an Internet cafe, and the like. The VPN provides this degree of secrecy and security by encrypting all your communication up to the VPN server, and then bouncing your requests from it to the world. A local attacker would see encrypted traffic, and she would be unable to snoop on you.
There are several solutions to the splitting problem you mentioned, which are however involved because there is no per application-routing in Linux (or any OS that I know). You may certainly have two distinct users, one routed entirely thru the VPN, the other entirely outside the VPN. Just make sure you start your VPN client aat login for the first user, while you do nothing of the kind for the second. If instead you need to have simultaneous connections with/without the VPN, you have three major solutions:
1) an LXC container, the simplest solution but alas, as I recently discovered, not working at the moment in Arch (works great on Debian, though).
2) a virtual machine (with, say, vitrualbox): this does work, but it is heavy on resources:
3) you may configure iptables or policy routing (or both) to send packets thru two different interfaces; this certainly does work, but you have to know before-hand which addresses will be routed thru which interface. I find this cumbersome, but others feel otherwise.
Also, the DNS issues only appeared right after starting the openvpn service, and went away right after removing it. I'll know for sure when I change my subnet, but it looks like the 0.0.0.0/1 route overrides everything, no?
Not sure what you mean. 0.0.0.0/1 is only shorthand for: "all addresses from 0.0.0.1 to 127.255.255.255'. If what you wish to know is how to reset your routing table, this is most simply accomplished by bringing down and then back up your interface (after having stopped the VPN application, of course, otherwise you will find yourself back to square one), and then re-establishing a connection the usual way, without VPN.
Offline
Thanks for your response. My server died, it looks like the motherboard/power supply took out my hard drives. Luckily not both at the same exact time so I have a backup. It'll be a while before I can play with this some more since I have to replace lots of parts. But I appreciate the detailed information.
Last edited by krovisser (2013-09-06 14:17:04)
Offline