RE: OpenVPN and IP Forwarding
>>I used dia to make a png file diagram of my network. I tried to make one with text, but
>>I couldn't understand it and I made it. I assume the list won't forward attachments, so
>>I posted it at:
>>
>>http://i1309.photobucket.com/albums/s629/CletusJenkins/network_zps9f815828.png
>
>This helped a lot.
>Now me, I have the VPN server running on the "router" machine and the client on the side of the end users. But if you are the only user then this should work too, it is just a bit confusing for me.
>
>[....]
>
>> Anyway, here is an of my openvpn config (domain names expunged):
>
>The openvpn server side config is important too, even more, but.... As you said, the OpenVPN tunnel is working so it is just a routing issue.
The VPN Server is a black box to me unfortunately. It is in another country. I just rent the vpn service from its owners, perhaps they could give me their server config, or at least the bits relevant to my connection to them. I hadn't thought to ask them. Mainly because the VPN tunnel works great, as long as one is logged into my "router" machine or the wireless laptop I am writing this from.
>
>The VPN server is just one machine, yours, and not part of another local network right? We are trying to solve a routing problem from ONE machine, the VPN server, to the network on the private network other side of the VPN right?
>
No, I'm pretty sure the problem is between my "router" and the other machines on my local lan. When I bring up the VPN on the "router", the connection between the "router" and the private network gets weird (at least to me and my limited understanding of openvpn).
>On your VPN server, is there a routing table line that tells it what to do with a packet for 192.168.2.0/24? It should be a line like I have
>172.16.0.0 172.16.1.133 255.255.0.0 UG 0 0 0 tun0
>In this case I route the entire 172.16.0.0/16 network to the other side of the VPN tunnel which uses the 172.16.1.0/16 network in my case. You should have something like
>192.168.2.0 10.10.0.xxx 255.255.255.0 UG 0 0 0 tun0
Before bringing up the VPN I have this routing table (not the real routable IPs):
Destination Gateway Genmask Flags MSS Window irtt Iface
66.55.44.30 0.0.0.0 255.255.255.252 U 0 0 0 eth1
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 66.55.44.33 0.0.0.0 UG 0 0 0 eth1
So the next to last line points back to my local lan. When I bring up the vpn the following is the route table:
Destination Gateway Genmask Flags MSS Window irtt Iface
10.10.0.1 10.10.0.33 255.255.255.255 UGH 0 0 0 tun0
10.10.0.33 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
77.66.55.44 66.55.44.33 255.255.255.255 UGH 0 0 0 eth1
192.168.2.0 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
66.55.44.30 0.0.0.0 255.255.255.252 U 0 0 0 eth1
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 10.10.0.33 0.0.0.0 UG 0 0 0 tun0
I still have the same route. Does the tun0 interface created by openvpn completely override the other interfaces on my "router" machine? My local lan is wired on a device I own, so I didn't feel a need to encrypt local traffic.
>Because you want to reach the 192.168.2.0 network on the other side of the tunnel, your routing table needs to know where to send those packets. This routing line can be created automatically via a push route line on the openvpn server but as you have server and client reversed have a look at an "up" script in your config.
>I have a script on one client machine that creates a few extra routing rules.
>In the config you need:
>up /etc/openvpn/dmz.up (or whatever script name you like)
>And the script looks like:
>#!/bin/sh
>route add -host media.tio.nl gw $5
>#route add -host mailie.tio.nl gw $5
>[....]
>That way I can reach those machines via my vpn tunnel to do maintenance in stead of using the default route via the internet connection, where those ports are blocked of course. ;-)
>
>The router in your private network now needs to have similar lines to reach your client. If your machine at the other side is indeed just one machine it should use the 10.10.x.x ip-number associated with the tun interface to reach the private network.
I noticed something odd after a reboot to clear any routing weirdness, I can't ping the systems on the private network from my "router" whether the vpn is up or not. Is this normal? Looking closer at my route table (before the vpn is started), it seem odd:
Destination Gateway Genmask Flags MSS Window irtt Iface
66.55.44.30 0.0.0.0 255.255.255.252 U 0 0 0 eth1
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 66.55.44.33 0.0.0.0 UG 0 0 0 eth1
Is it saying send anything destined for 192.168.2.0/8 through eth1, my real, routable network interface? Shouldn't it go through the interface that is actually connected to the local lan, eth0?
I noticed a notational mistake in my original question, the local lan is 192.168.2.0/24 not 192.168.2.0/8, its been such a long time since I used CIDR notation I got it part after the slash backwards.
>
>Your other machines in the private network do not need any extra routing lines as they have the router machine to do the routing for them, they simply dump everything there via the default gateway routing
>
>>The thing I don't understand is when I bring up the VPN link, I lose the ability to ping
>>or otherwise connect from my "router" machine to the local lan (192.168.2.0/8)
>>machines. But the VPN works fine from the "router" machine, I can do everything I
>>normally would do on the internet.
>
>Euh.... that looks like there is a problem with the routing lines on the router machine sending the packets the wrong way. As the router machine is connected to the "local LAN" directly this is very weird. Look at your routing lines on the router machine before and after the openvpn tunnel is up and look at the differences.
>
>Like I wrote, I have the openvpn server on the router machine. That way all the vpn traffic coming from all the clients gets handled by the machine that is already responsible for handling routing. That machine acts as a router/firewall for my local network and should know all possible traffic destinations/sources. All the other machines do not know anything about routing, just where the default gateway is, the router machine.
>
I didn't quite understand this the first couple of times I read it, but now I think what you are talking above above is the problem. I tried deleting and recreating the route to my local lan, but I haven't gotten one where the local lan works. I keep having to route it through the eth1 interface. Unless I am totally confused about what the routing table is saying in my comment above. Here is what I think should work, but doesn't:
route add -net 192.168.2.0 netmask 255.255.255.0 gw 192.168.2.1 dev eth0
>One other thing... unless you run into other issues and really need "proto tcp" to keep a session open to keep the openvpn traffic flowing, the preferred proto for the openvpn traffic itself is udp. The reason for that is that when sending tcp traffic inside a tunnel that is using the tcp mechanism to resend packets when needed, things can really go wrong in some cases.
>Do not change it just now, lets first solve your current problem but... once that is solved see if still you have a working openvpn tunnel if you switch to udp. In most cases you get a better throughput. In some isolated cases the performance is better using tcp, just see what is better for you.
>
>
>Bonno Bloksma
>
I am using the vpn config the company gave me to use. I just customized it to store my vpn password in a file, rather than enter it manually. But I'll try udp, I take a performance hit, but I assumed that was entirely due to the extra routing hops to their network. Maybe it will give me some of that performance hit back. Thanks.
Reply to: