OpenVPN routing.
 

Hi guys,
I'm having difficulties to understand the logic behind the routing procedure in VPN.

Let's say I have two machines, one is vpn-server the other is client.

The server has even an extra eth1 interface 192.168.0.1 on private network 192.168.0.0/24 . I want my client machine be able to reach other machines that may be on the 192.168.0.0/24 network.

I activated ip_forward and set up forward rules in IP-tables (which, other than that, are clean).
iptables -A FORWARD -i tun+ -j ACCEPT

When using routed aproach, I configure the server/client accordingly, I "push" the 192.168.0.0/24 from the server and this is the result I get when startup of server / client is complete, I get following tun0 interfaces.

Server:
Client:
Now, I'm not actually sure what P-t-P addresses are. I guess it stands for "peer-to-peer" but I'm having difficulties to understand, in practical sense, what they do.

With startup sequences complete, I'm able to ping the server tun0 interface from the client. I'm even able to ping the 192.168.0.1 eth1 interface of the server (network I pushed), but I'm still not able to connect to any machine on that same network.

During the initalization, I can spot the following rows on the client side:
As you can see, the 10.8.0.5 address is being used as gateway (the p-t-p address). I don't quite understand what it does. It's obviously, from what I can see, being used as gw to the network 192.168.0.0 that I want to reach. But still, I cant reach it.

When using route command on the client I see the following row regardign the 192.168.0.0 route.
Obviously this "p-t-p" address is being used for gateway to that network. But I can't reach it.

To be actually able to do what I want to do (reach other machines behind VPN internal network 192.168.0.0 - I have to manually add the following on my client:

route add -net 192.168.0.0 netmask 255.255.255.0 gw 10.8.0.6 (the actuall IP address of the tun0 device on the client).

Why does OpenVPN behave like this?
Shouldnt it add this automatically? For that matter, what is the purpose of the rows that it actually did add automatically during the initalization?

Thanks in advance (and I hope I made myself clear).

Lets do things step by step.
Please, if possible, reboot client and then JUST start vpn-client.
Then do not do anything and type on root console:
route -n

Post output here, removed any private addresses, please.

I will try to explain how vpn works then.

Thanks

Hi, I rebooted the client machine, and then started the vpn-client.
I assume you wanted the vpn server to be active so connection can be made.
After typing route -n on the client I get the following:
NOTE. 10.0.2.0 network and the 10.0.2.2 IP is the default NAT connection on the virtual box to the "real world".
172.16.0.0 is the host-only network that I use for interconnection of my virtual machines.
192.168.0.0 is the internal network on the server. As you can see here, GW added is 10.8.0.5 (the mentioned p-t-p address of the tun0 interface on the client).


As you can see...the same effect...still the 10.8.0.5 is being used.
To be able to actually reach the machines on 192.168.0.0/24 network I have to type the route add command I already posted.
What I'm wondering here is why the this so called "peer-to-peer" ip is being propagated automatically as GW (and what it practically does in the first place) and why I need to add the actually client's tun0 IP (10.8.0.6) manually to be able to do what I want to do. I can live with this - but I want to know why this is being done this way. :)

First of all, let see what you get.
1. Default route: Destination=0.0.0.0 GW=10.0.2.2 Netmask=0.0.0.0 Interface=eth0
This is where all packets will go, except for: 10.8.0.5, 10.8.0.x, 172.16.0.x, 10.0.2.x, 192.168.0.x.
I hope you understand it.

2. Route to 192.168.0.0-254: GW=10.8.0.5 Interface=tun0.
Now. Imagine, you send packet to (for example) 192.168.0.25, which is on LAN, connected to server. Your packet successfully reaches GW and vpn server (you said you were able to ping it). But what was the sender IP?
Next. Packet goes farther, to destination. And destination receives it and answers. LAN IP is 192.168.0.x and sender IP doesn't belong to it, so the destination has to replay through GW, and GW (of the LAN) will sent packet by default route. But anyway not to the sender.

I think, you need to add SNAT rule to the server iptables POSTROUTING chain. It will change all external IP to the interface IP, so replay can go back to sender.

No, the problem is that the reply doesn't reach the OpenVPN server. The best solution is to add a route on the destination host, or it's default router, pointing to the OpenVPN server.

But that would break many applications.

1. I changed my own post, it was little bit incorrect.

2. SNAT can't brake anything because it is just a NAT (source NAT).
Of course one need to specify that only packets from vpn, which go to LAN have to be caught by SNAT rule.

P.S. And of course it possible (or it may be really better) to add route on vpn-server, especially, if host on LAN will try to connect any IP behind vpn.

For example NFS4, ISATAP, and many peer-to-peer applications. Those peer to peer applications that do work are liable to choose a route avoiding the VPN.