3

I have a cute Raspberry Pi 2 router running Raspbian Jessie. It connects to a VPN using OpenVPN on tun0 and redirects all the wireless (wlan0) traffic into tun0. This is done by using these iptables rules:

iptables -A FORWARD -o tun0 -i wlan0 -s 192.168.1.1/24 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -F POSTROUTING
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

I would like to setup another OpenVPN connection and channel all the traffic directly generated by the router into it.

The goal is to have 2 separated openvpn processes, hence to use two cpu cores and load-balance the cutie, since a single RPi2 core would be maimed by all the encryption work.

Am I thinking right? Is it possible? How can I do it?

Improve this question
4
  • 1
    Something like this : unix.stackexchange.com/questions/23106/… ? – dhruvvyas90 Dec 31 '15 at 12:11
  • Rather the opposite: I don't want to limit, I want to use multiple cores. The problem is that OpenVPN is not written for multicores. – Alessandro Cappello Jan 1 '16 at 8:45
  • As long as you have two separate OpenVPN configurations, each going to their own tunX device, they should be different processes -- and will use the multiple cores automatically. – Wim Jan 2 '16 at 17:15
  • It's nice to read that, it means that I'm on the right track! But how can I redirect the traffic from 192.168.1.1 to tun1 and all the traffic from the other devices to tun0? – Alessandro Cappello Jan 2 '16 at 17:25
3
+50

It's not recommended to mess around with a process' affinity. If you really have the urge, use taskset but you have been warned. The best you might do is kill people hurt performance (sic).

What I'd recommend is simply fire up multiple instances of OpenVPN, using different configuration files. You'll want to do something along the lines of

/usr/local/sbin/openvpn /etc/openvpn/private_tunnel.conf
/usr/local/sbin/openvpn /etc/openvpn/dedicated_gaming_tunnel.conf
/usr/local/sbin/openvpn /etc/openvpn/clark_prn_tunnel.conf
/usr/local/sbin/openvpn /etc/openvpn/whistleblowing_tunnel.conf

Then, setup additional iptables entries for the additional tun devices. I'm sure you can handle that bit.

EDIT: Okay, I read the comment section and I realized something.

#These are untested. Someone should check for duplicate/unnecessary/incorrect entries.

# Forward everything to tun0
iptables -A FORWARD -o tun0 -m conntrack --ctstate NEW -j ACCEPT

# Then, forward 192.168.1.1 to tun1
iptables -A FORWARD -o tun1 -s 192.168.1.1 -m conntrack --ctstate NEW -j ACCEPT

# The rest of the entries
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -F POSTROUTING

# Two masquerades, one for each tun interface
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
iptables -t nat -A POSTROUTING -o tun1 -j MASQUERADE

Last but not least, let your kawaii Pi 2 handle the low-level stuff like assigning resources for each process.

Improve this answer
2
  • Thanks for your reply! It doesn't seem to work, even if it doesn't throw any error, but I'll give it more time to better test it. What makes me say that it doesn't is the fact that if I start to download both on router and on a client, the top list shows only one openvpn process, and both client and router have the same public IP address - theoretically they shouldn't, since the VPN service gives different IP addresses to different clients. Is there a way to see which interface is being used by the router when communicating with the outside? – Alessandro Cappello Jan 4 '16 at 9:03
  • @Alessandro What I've thought of is using watch -n 0.1 ifconfig and checking which interface's RX and TX bytes grows the most while making the router communicate with something (maybe download a file?). It's a redneck solution, but it should work. – Aloha Jan 4 '16 at 11:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.