Hi, >>This is a good clarification. But still confusing. I think you need to >>give us a block diagram or picture of things. Because in the above it >>reads like you have two machines in your path where most of us would >>have only one. Because you say that you vpn to a server and that server >>you vpn'd to provides you access to the internet. If you are not using >>the internet to get to that server then I can only assume that you have >>yet another private lan segment between. >> > >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 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? 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 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. 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. 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
