Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I've entirely configured (remotely) a Debian GNU/Linux dedicated server hosted in a professional capacity and I've got a network routing question (which AFAICT precisely fits the FAQ of serverfault).

That dedicated server has a static IPv4 IP and a very simple route:

route -n

Table de routage IP du noyau
Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface
94.xx.yy.0      0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         94.xx.yy.254    0.0.0.0         UG    0      0        0 eth0

I've only one static IP and there are a lot of other dedicated servers on the same subnet which I cannot mess with.

That server is hosting/serving our company's main webapp (Apache+Tomcat) and is running Squid as well. I did all the configuration myself. Once the budget allows it I'll move Squid to another server.

For now I'd like to add OpenVPN to that server (preferably using tun, not tap) and I want to know what needs to be done to be sure that my interfaces won't "clash" with the other dedicated servers.

I don't understand how the setup should be done and I'm confused as to what the route shall end up looking like.

In order to help me understand the "big picture", could someone give a precise example of:

  • local IP address of an OpenVPN client
  • gateway IP that that OpenVPN client shall be using
  • the route output of the OpenVPN server

Basically I'm a bit lost and before starting I'd like to understand how the routing is done on the OpenVPN server.

As far as I understand it the OpenVPN clients shall be on the same network that the OpenVPN server (using, say, a 10.0.0.0/8 network) but I'm hitting a mental roadblock trying to figure out how the clients are going to use the 'tun' interface to then end up using the 94.xx.yy.254 gateway.

share|improve this question

1 Answer 1

Suppose the VPN client has the following IP settings:

IP eth0: 192.168.1.100
Default gateway: 192.168.1.1

So, all non-local traffic will go out through 192.168.1.1. If there's traffic to another host on the LAN, it'll just go to that host.

OpenVPN starts up, the client gets a new interface tun0, and then we see something like:

IP eth0: 192.168.1.100
IP tun0: 10.8.0.13
Default gateway: 192.168.1.1
VPN routing: 10.8.0.1 for the network 10.8.0.0/24

This assumes that the OpenVPN server is not pushing any additional routes. So, a network packet going to, say, 8.8.8.8, will still go across the LAN's default gateway, 192.168.1.1. A packet going to, say, 10.8.0.204, will go across the OpenVPN tunnel, to the OpenVPN server at 10.8.0.1 for further routing.

If the OpenVPN server pushes a route for it's LAN, say, 172.16.0.0/24, then the VPN routing above may look like:

VPN routing: 10.8.0.1 for the network 10.8.0.0/24
             10.8.0.1 for the network 172.16.0.0/24

So, similarly, a packet for 172.16.0.24 will go to 10.8.0.1 for further routing.

If the OpenVPN server is also pushing the setting "redirect-gateway def1", then the default gateway is different on the VPN clients. You'll see something like:

IP eth0: 192.168.1.100
IP tun0: 10.8.0.13
Default gateway: 10.8.0.1
  (other gateway with lower priority): 192.168.1.1
Static route: 94.xx.yy.zz uses 192.168.1.1

Where 94.xx.yy.zz is the public IP address of your OpenVPN server.

In this case, traffic directly for your OpenVPN server will go through the LAN default gateway 192.168.1.1. Traffic that's local to 192.168.1.0/24 will just go to hosts as expected. Any other traffic will use 10.8.0.1; non-local traffic that's not directly to the public IP of the OpenVPN server will go across the VPN tunnel, and emerge from 94.xx.yy.254.

You may see another default route in the routing table that retains 192.168.1.1 as the gateway, but it will have a lesser priority than 10.8.0.1. This is, I think, more of a placeholder by the OpenVPN client, so that it knows what to set the default route back to, once the VPN shuts down. Don't worry about that entry.

share|improve this answer
    
thanks a lot, +1. You wrote: "If the OpenVPN server pushes a route for it's LAN, say, 172.16.0.0/24, then the VPN routing above may..." But seen that the OpenVPN server already is on 192.168.0.100 and on 10.8.0.13, when would it have "it's LAN" be on 172.16.0.0/24? –  Cedric Martin Aug 24 '12 at 17:17
    
I didn't see that the OpenVPN server had a LAN IP of 192.168.0.100, actually, so I made up some other network range. I had the client in 192.168.1.0/24, so I wanted to make the OpenVPN LAN network very different. –  cjc Aug 24 '12 at 17:19
    
oops sorry, I messed that up: wrote too fast. I re-read it all and your "redirect-gateway def1" example really just helped me understand better how things should work. It's a great example, thanks a lot again. –  Cedric Martin Aug 24 '12 at 17:21

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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