# OpenVPN no longer routes

## depontius

I just started using OpenVPN for the first time in quite some time.  I used to use it from work to access my home network for my email, etc.  But then I re-read the corporate security guidelines and realized that OpenVPN could be considered to "extend the company network," and indeed with misconfiguration that's quite easy to do.  Since then I've been using ssh with port forwarding to get to my home resources.  But I still use OpenVPN when I travel, and last used it last October.

Now it's post-baselayout2 and my first time using OpenVPN since.  I've glance at this thread: https://forums.gentoo.org/viewtopic-t-878975-highlight-openvpn.html but don't seem to  be having the same problems.  In particular, I haven't shortened the service name I use, and the basic connection seems to work in spite of that.

My OpenVPN server doesn't route.  From the road, I can only contact the machine that's running the OpenVPN server.  I'm contacting it by the LAN address, not the tunnel address.  But I can't contact anything else on my LAN.  Yet if I look at either "netstat -Nr" or "ip route show" it looks as if I get to my LAN through the p-p tunnel.  I did double-check, and /proc/sys/net/ipv4/ip_forward is set to "1" on the server.

Some more interesting factoids... 

When I traceroute to the server, there's just one return - the server LAN address.

My tunnel is "inet addr:192.168.77.130  P-t-P:192.168.77.129  Mask:255.255.255.255", but when I traceroute to a different machine on my LAN I quickly get to the first hop at 192.168.77.1, and no further.

If I look at "ifconfig tun0" on the server, I indeed see 192.168.77.1, and the 192.168.77.129/130 are the "push addresses" for this client in /etc/openvpn/ccd.

Also looking at kern.log I see a bunch of martian packets being logged.

If I look in /proc/sys/net/ipv4/conf I see that rp_filter is set to "1" for everything, and log_martians is set to "1" for "all" and "0" for the rest.

But the rp_filter and log_martians didn't bother me 6 months ago, other than maybe some log noise.  Nor am I getting any log noise from rp_filter.

Any suggestions?

----------

## Mad Merlin

If you're using tun mode (point to point connection at layer 3) instead of tap mode (network bridge at layer 2), you need to add routing rules on the default gateway for the machines on the other network, otherwise they won't know to go back through the VPN server to reach you.

Having to add routing rules on the default gateway sucks, so I'd suggest using tap mode instead. With tap, you'll get a normal second IP address on the remote network, and you won't need to futz around with routing. Basically, on the server, create a bridge, bridge eth0 and tap0 into it, use "dev tap0", then once the client connects, run a dhcp client on the client's tap0, and your client will now have an address on the remote network.

----------

## depontius

Trip's over, and I can't use OpenVPN from work, so for the moment the issue has gone underground, again.  Point is, when I first set up OpenVPN tun mode looked less complex than tap mode, and I've had things all set up and running for years.  Two changes happened recently - baselayout2 and I switched servers.  (I normally keep 2 running or near-running, and tend to ping-pong between them.)  Right now I'm suspecting that if I go back to the other server for OpenVPN - which is actually pretty easy to do - that I'll find it isn't routing, either.

In any case, while on vacation I was able to do what I needed to do - because of the way I now access my home services from work.  In order to avoid the "extending the network" clause I now ssh into my home server and forward some ports back to work.  My email clients, etc, are set up to work with oddball port numbers, so I'd still need to use openssh port forwarding even with OpenVPN.  So I was able to start OpenVPN, then ssh into the gateway machine with ports forwarded from my mail server.

I'd still like it working correctly.  I need to switch back to the other server for my gateway and verify that it doesn't work either.  That would pin it down to baselayout2.  For various reasons I'd rather not go to tap.

----------

