Score:1

Routing OpenVPN traffic to IP Tunnel

pk flag
Max

I'm connecting through OpenVPN to my server1 but don't like to have its IP visible while surfing the web, so I opened an IP tunnel to another server (server2). How can I set the routing and IP Tables so traffic of OpenVPN goes through this IP Tunnel and then Server2 IP will show up while browsing websites?

Server1 and Server2 are reachable through IPTunnel.

  • Server1 public IP: 198.51.100.1
  • Server1 OpenVPN IP: 10.8.0.0
  • Server1 IPTunnel IP: 172.20.9.1
  • Server2 public IP: 203.0.113.1
  • Server2 IPTunnel IP: 172.20.9.2

Thank you :)

dominix avatar
gf flag
it just depend on the route you push. Do not push default route to every openvpn you connect to. if you push a specific subnet, it will be used for the IPs in this subnet.
Ron Maupin avatar
us flag
"_Server1 public IP 88.88.88.88 server2 public IP 99.99.99.99_" Those IP addresses do not belong to you. You should not be publicly claiming IP addresses that you do not own. IANA has set aside three IPv4 ranges (`192.0.2.0/24`, `198.51.100.0/24`, and `203.0.113.0/24`) and one IPv6 range (`2001:db8::/32`) for example addresses.
Max avatar
pk flag
Max
So you expect me to share my exact IP address publicly? Those are just symbols, please don't be stupid
Ron Maupin avatar
us flag
No, you should use the address ranges IANA has set aside for such things, then people know they are examples. You are sharing IP addresses that belong to someone else, and I doubt you would like other people giving your address (IP or home) as their own. You are claiming those are your addresses, and they are addresses belonging to someone else. To solve that problem, IANA has set aside the address ranges I previously commented.
Nikita Kipriyanov avatar
za flag
Also 172.10.x.x is not a "free" block to use. You don't own them so you aren't permitted to use them anywhere. You probably thought about the block `172.16.0.0/12` as defined in the RFC 1918. So well, I changed all the addresses in your question for it to be correct. See [RFC 5735](https://www.rfc-editor.org/rfc/rfc5735) for details.
Nikita Kipriyanov avatar
za flag
Putting that aside, why do you need this strange construction? Why not using server1 or server2 alone for the VPN? Just have all VPN clients to connect directly to server2 and don't bother with advanced routing.
Score:1
za flag

The main problem is with the server1. It has a direct connection to the Internet and it will send all the packets towards Internet through this connection. However, you want it to send all the packets that came from its VPN clients towards Internet through the tunnel. This is impossible to do using simple basic routing.

To resolve this, you have to use Linux's policy routing. I advise you to read the whole linked LARTC chapter in full (not just that page) before continuing, because it is essential for you to understand what's going on!

Now, when you are read that, let's use for our purpose.

Currently, your server1 has roughly the following routes (as shown by ip route command):

198.51.100.0/24 dev eno1 src 198.51.100.1
default via 198.51.100.2 dev eno1
172.20.9.0/30 dev wg1 src 172.20.9.1
10.8.0.0/30 dev tun0 src 10.8.0.1
10.8.0.0/24 via 10.8.0.2 dev tun0

The first two routes are the Internet connection of the server1, the third one is the tunnel and last two are OpenVPN-related. (I assume that the physical interface is called eno1, the tunnel is WireGuard virtual device called wg1, and OpenVPN is in server net30 mode using tun0.)

The rule table looks like this (ip rule) — as by default:

0:      from all lookup local 
32766:  from all lookup main 
32767:  from all lookup default 

You need to add additional routing tables and rules:

ip route add default via 172.20.9.2 table 200
ip rule add from 10.8.0.0/24 lookup 200

You can use a symbolic name of a table in place of a number, if you register it into the /etc/iproute2/rt_tables file, as described in LARTC.

This doesn't change anything for the server itself. However, clients with addresses like 10.8.0.6 will get routed using the table 200 according to the policy, so their traffic to the Internet will get routed through the tunnel wg1 as defined in the routing table 200.

The rest is easy. On the server2, have a route towards VPN clients and the NAT for them:

ip route add 10.8.0.0/24 via 172.20.9.1
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eno1 -j MASQUERADE

(Again, I assumed the physical interface on the server2 is called eno1 too.)

If you want to use modern NFTables instead of legacy IPTables, change the masquerade command to something like the following:

nft add rule ip nat POSTROUTING oifname "eno1" ip saddr 10.8.0.0/24 masquerade

In the OpenVPN server config you set it up to push a default route through VPN to clients (as opposed to the comment by @dominix up there, you actually want to push a default route to all clients if you want them to browse Internet through the VPN):

push "route 0.0.0.0 0.0.0.0"

Don't forget to enable IP forwarding on both servers:

sysctl net.ipv4.ip_forward=1

That's all. You have to figure out how to make this permanent using your distro's network configuration facilities. Since you didn't specify what distro you use on your servers, I'll leave that as a homework.

I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.