how to stop all my traffic going through openvpn on linux

[syncswim 1]

Hi All

I'm a new user of airvpn, and I must say I'm very impressed. Setup was easy, and the speeds are fantastic and stable, however I have a problem that I know isn't actually caused by airvpn, but I thought I'd ask here for help.

Without getting into too much technical detail initially, here's the situation.

I've set up openvpn to connect through airvpn on a headless debian box. This was painless, and I can confirm that the connection is being made through my selected airvpn server.

eg:

curl ifconfig.me returns my airvpn ip when openvpn is running, or my normal external ip when it's not

However, as soon as I start my openvpn client ALL traffic then goes through openvpn. The main reason this is a problem is that this linux box also has other services running, apache, ftp etc etc. I use no-ip to resolve my IP to my domain, so obviously then trying to access any of my services remotely is not possible.

All I want to do is bind Deluge (torrent client) to the VPN, while leaving everything else going normally through my router.

I have to admit that although I'm not a complete newb, I'm in well over my head here!!

Any help would be massively appreciated.

[syncswim 1]

So I've finally made a little progress.

I saw in my logs that the airvpn server is pushing new route settings back to my machine. So, I've added:

route-nopull

to my config, but now I have the opposite problem. Deluge daemon is now NOT using the vpn tunnel, even though it's set to use tun0 interface.

Help!

[Staff 9770]

Hello!

Splitting traffic to different NICs on a process basis is a serious challenge.

Our servers push routes and default gateway so that all the client traffic will be tunneled. OpenVPN client does not provide a built-in way to split traffic.

You can have your client refuse the push (nopull directive) and then build your own routing table(s) with appropriate gateways to split the traffic between tun0 and eth0 (or any other card you have).

A discussion about issues, troubleshooting and possible solutions of such a setup in an Ubuntu environment (check the links inside the thread as well):

http://ubuntuforums.org/showthread.php?t=1200601

Alternatively, if the programs have the appropriate function, you can bind all those that you don't want to be tunneled (Apache, ftp server...) to the NIC you wish.

Otherwise (this is an alternative, not a solution to what you have asked) your web and ftp services can be anyway reachable from the VPN server : (just forward remotely the appropriate ports and configure them in Apache and ftpd). This might give you the advantage to have a static IP address, making no-ip unnecessary.

About ftp servers some additional care is required for forwarded ports:

https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=1700&Itemid=142#1702

Kind regards

[moz2186 0]

I've done something similar. My solution was to setup a proxy server (daunted) that accept all (my) traffic on a port and forwards it over the tun0 (VPN) device. This works with Deluge by setting the proxies to a SOCKS5 with the IP the Daunted server is running on. I had issues with Deluge binding to the correct interface, this was corrected by setting the ip to 0.0.0.0 in the Deluge interface. I'm having touble connecting ATM ("Already connected" error that others are getting) otherwise it's been flawless. DHT works etc.

[syncswim 1]

Thanks for your advice guys. I've now got it set up so all traffic is going through the VPN. Admittedly that's not really what I wanted, but for now it'll have to do, as I've spent way too much time already on this, so maybe I'll come back another day when I understand things better and try a more advanced config. Networking is really not my strong point

My main concern with having all traffic going through the VPN is that I'm now relying on two services (my ISP + AirVPN), so if the VPN server gets overloaded, goes down etc, I'm gonna have problems.

One last thing that I don't quite understand is something you've referred to, in terms of setting Deluge's interface:

It seems that tun0 is always given the same IP by linux (although I haven't specified that anywhere), so I've entered that IP into Deluge's interface setting to force traffic only through the VPN. Although for a couple of minutes when I reboot I do get a message in the thinclient that 'no connections found', but that goes away quickly, and everything seems to work ok, and more importantly, http://checkmytorrentip.com does not report any leaks.

Does that make sense, and seem like a logical solution to you? I'm guessing it has problems initially because deluge tries to connect through this interface before the vpn is properly initialised.

Oooh actually, one more thing. I had problems forwarding the ports correctly for Deluge. In the end I configured a forwarded port in my airvpn account that forwards a specific port to the SAME port at my end. eg 55555->55555, then entered that port into Deluge's incoming and outgoing port settings. That seems to work ok, whereas all previous settings do not. I don't see how anything else could work as how could peers possibly send to the right port if I've redirected it to another port?

I'm finally feeling safe, but I'd appreciate more input if you think I'm not!

[syncswim 1]

Thanks for your advice guys. I've now got it set up so all traffic is going through the VPN. Admittedly that's not really what I wanted, but for now it'll have to do, as I've spent way too much time already on this, so maybe I'll come back another day when I understand things better and try a more advanced config. Networking is really not my strong point

My main concern with having all traffic going through the VPN is that I'm now relying on two services (my ISP + AirVPN), so if the VPN server gets overloaded, goes down etc, I'm gonna have problems.

One last thing that I don't quite understand is something you've referred to, in terms of setting Deluge's interface:

It seems that tun0 is always given the same IP by linux (although I haven't specified that anywhere), so I've entered that IP into Deluge's interface setting to force traffic only through the VPN. Although for a couple of minutes when I reboot I do get a message in the thinclient that 'no connections found', but that goes away quickly, and everything seems to work ok, and more importantly, http://checkmytorrentip.com does not report any leaks.

Does that make sense, and seem like a logical solution to you? I'm guessing it has problems initially because deluge tries to connect through this interface before the vpn is properly initialised.

Oooh actually, one more thing. I had problems forwarding the ports correctly for Deluge. In the end I configured a forwarded port in my airvpn account that forwards a specific port to the SAME port at my end. eg 55555->55555, then entered that port into Deluge's incoming and outgoing port settings. That seems to work ok, whereas all previous settings do not. I don't see how anything else could work as how could peers possibly send to the right port if I've redirected it to another port?

I'm finally feeling safe, but I'd appreciate more input if you think I'm not!

[Staff 9770]

One last thing that I don't quite understand is something you've referred to, in terms of setting Deluge's interface:

It seems that tun0 is always given the same IP by linux (although I haven't specified that anywhere),

Hello!

tun0 IP will be DHCP-assigned by our servers, unless you reject the push with nopull.

https://airvpn.org/specs

so I've entered that IP into Deluge's interface setting to force traffic only through the VPN. Although for a couple of minutes when I reboot I do get a message in the thinclient that 'no connections found', but that goes away quickly, and everything seems to work ok, and more importantly, http://checkmytorrentip.com does not report any leaks. Does that make sense, and seem like a logical solution to you? I'm guessing it has problems initially because deluge tries to connect through this interface before the vpn is properly initialised.

Yes, it makes sense, and if you notice no leaks you're just fine. The "no connection found" is probably correct (it should occur until your OpenVPN client receives the push from the server).

Oooh actually, one more thing. I had problems forwarding the ports correctly for Deluge. In the end I configured a forwarded port in my airvpn account that forwards a specific port to the SAME port at my end. eg 55555->55555, then entered that port into Deluge's incoming and outgoing port settings. That seems to work ok, whereas all previous settings do not. I don't see how anything else could work as how could peers possibly send to the right port if I've redirected it to another port?

Of course you're right, a remotely forwarded port for a p2p client must not be remapped to a different local port, as specified in our FAQ, otherwise the client won't be reached from the Internet (p2p is of course possible but with no incoming connections). This is a particular case for which a port remap is not desirable with our cone-NAT.

Kind regards

[moz2186 0]

Thanks for your advice guys. I've now got it set up so all traffic is going through the VPN. Admittedly that's not really what I wanted, but for now it'll have to do, as I've spent way too much time already on this, so maybe I'll come back another day when I understand things better and try a more advanced config. Networking is really not my strong point

My main concern with having all traffic going through the VPN is that I'm now relying on two services (my ISP + AirVPN), so if the VPN server gets overloaded, goes down etc, I'm gonna have problems.

One last thing that I don't quite understand is something you've referred to, in terms of setting Deluge's interface:

It seems that tun0 is always given the same IP by linux (although I haven't specified that anywhere), so I've entered that IP into Deluge's interface setting to force traffic only through the VPN. Although for a couple of minutes when I reboot I do get a message in the thinclient that 'no connections found', but that goes away quickly, and everything seems to work ok, and more importantly, http://checkmytorrentip.com does not report any leaks.

Does that make sense, and seem like a logical solution to you? I'm guessing it has problems initially because deluge tries to connect through this interface before the vpn is properly initialised.

Oooh actually, one more thing. I had problems forwarding the ports correctly for Deluge. In the end I configured a forwarded port in my airvpn account that forwards a specific port to the SAME port at my end. eg 55555->55555, then entered that port into Deluge's incoming and outgoing port settings. That seems to work ok, whereas all previous settings do not. I don't see how anything else could work as how could peers possibly send to the right port if I've redirected it to another port?

I'm finally feeling safe, but I'd appreciate more input if you think I'm not!

Use http://checkmytorrentip.com/ to be certain but I think I tried this and my ISP IP was still being reported to the tracker. Hence my use of the local proxy server.

[syncswim 1]

I assume you mean 'Dante' not 'Daunted'. I've decided to give this a go. Is there any chance you could post your Dante config file, please?

[moz2186 0]

Sorry, yes I meant Dante, Danted is the daemon that I've become accustomed to starting/stopping when I was setting the configuration.

Here's the config (stripped of all comments). You'd have to change the "internal: br1 port =1080" to the eth# and port of your choice. Then the 192.168.0.0/24 throughout to whatever matches your network setup.

logoutput: syslog
internal: br1 port = 1080
external: tun0
method: username none #rfc931
user.privileged: proxy
user.notprivileged: nobody
user.libwrap: nobody
extension: bind
client pass {
	from: 192.168.0.0/24  port 1-65535 to: 0.0.0.0/0
}
client pass {
	from: 127.0.0.0/8 port 1-65535 to: 0.0.0.0/0
}
client block {
	from: 0.0.0.0/0 to: 0.0.0.0/0
	log: connect error
}
block {
	from: 0.0.0.0/0 to: 127.0.0.0/8
	log: connect error
}
pass {
	from: 0.0.0.0/0 to: 192.168.0.0/24
	command: bindreply udpreply
	log: connect error
}
pass {
	from: 192.168.0.0/24 to: 0.0.0.0/0
	protocol: tcp udp
}
pass {
	from: 127.0.0.0/8 to: 0.0.0.0/0
	protocol: tcp udp
}
block {
	from: 0.0.0.0/0 to: 0.0.0.0/0
	log: connect error
}