LinuxQuestions.org
Visit the LQ Articles and Editorials section
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices



Reply
 
Search this Thread
Old 06-24-2010, 07:14 AM   #1
MheAd
Member
 
Registered: Jun 2007
Distribution: Ubuntu 14.04
Posts: 186

Rep: Reputation: 36
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:
Code:
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.8.0.1  P-t-P:10.8.0.2  Mask:255.255.255.255
Client:
Code:
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.8.0.6  P-t-P:10.8.0.5  Mask:255.255.255.255
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:
Code:
Thu Jun 24 12:31:05 2010 /sbin/ifconfig tun0 10.8.0.6 pointopoint 10.8.0.5 mtu 1500
Thu Jun 24 12:31:05 2010 /sbin/route add -net 192.168.0.0 netmask 255.255.255.0 gw 10.8.0.5
Thu Jun 24 12:31:05 2010 /sbin/route add -net 10.8.0.0 netmask 255.255.255.0 gw 10.8.0.5
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.
Code:
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.0.0     10.8.0.5        255.255.255.0   UG    0      0        0 tun0
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).

Last edited by MheAd; 06-24-2010 at 07:18 AM.
 
Old 06-24-2010, 07:53 AM   #2
nimnull22
Senior Member
 
Registered: Jul 2009
Distribution: OpenSuse 11.1, Fedora 14, Ubuntu 12.04/12.10, FreeBSD 9.0
Posts: 1,571

Rep: Reputation: 92
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
 
Old 06-24-2010, 08:09 AM   #3
MheAd
Member
 
Registered: Jun 2007
Distribution: Ubuntu 14.04
Posts: 186

Original Poster
Rep: Reputation: 36
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).

Code:
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.8.0.5        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.8.0.0        10.8.0.5        255.255.255.0   UG    0      0        0 tun0
172.16.0.0      0.0.0.0         255.255.255.0   U     0      0        0 eth1
10.0.2.0        0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.0.0     10.8.0.5        255.255.255.0   UG    0      0        0 tun0
0.0.0.0         10.0.2.2        0.0.0.0         UG    0      0        0 eth0

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.
 
Old 06-24-2010, 09:31 AM   #4
nimnull22
Senior Member
 
Registered: Jul 2009
Distribution: OpenSuse 11.1, Fedora 14, Ubuntu 12.04/12.10, FreeBSD 9.0
Posts: 1,571

Rep: Reputation: 92
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.

Last edited by nimnull22; 06-24-2010 at 10:18 AM.
 
Old 06-24-2010, 10:20 AM   #5
TimothyEBaldwin
Member
 
Registered: Mar 2009
Posts: 249

Rep: Reputation: 27
Quote:
Originally Posted by nimnull22 View Post
LAN IP is 192.168.0.x and sender IP doesn't belong to it, so replay can't go farther then server eth1.
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.

Quote:
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.
But that would break many applications.
 
Old 06-24-2010, 10:45 AM   #6
nimnull22
Senior Member
 
Registered: Jul 2009
Distribution: OpenSuse 11.1, Fedora 14, Ubuntu 12.04/12.10, FreeBSD 9.0
Posts: 1,571

Rep: Reputation: 92
Quote:
Originally Posted by TimothyEBaldwin View Post
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.

Last edited by nimnull22; 06-24-2010 at 11:03 AM.
 
Old 06-25-2010, 01:35 PM   #7
TimothyEBaldwin
Member
 
Registered: Mar 2009
Posts: 249

Rep: Reputation: 27
Quote:
Originally Posted by nimnull22 View Post
2. SNAT can't brake anything because it is just a NAT (source NAT).
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.

Last edited by TimothyEBaldwin; 06-25-2010 at 07:21 PM. Reason: Forgot to delete some quoted text
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Error When converting Routing OpenVPN to bridge mode openvpn danmartinj Linux - Software 0 11-06-2009 10:23 AM
Openvpn and routing problem tungaw2001 Linux - Networking 1 11-24-2008 05:38 PM
OpenVPN Routing problem dilly Linux - Server 0 11-12-2008 08:17 AM
routing using openvpn williebens Linux - Newbie 1 07-11-2008 10:28 PM
OpenVPN and Routing. Eightpock Linux - Networking 2 07-10-2008 07:48 AM


All times are GMT -5. The time now is 07:59 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration