4

I setup OpenVPN between my work and my home. It's using certificates (not pre-shared keys), is in tun mode, and works great. The networks look like this:

Diagram

I have proper routes setup to send traffic back and forth, and the client has no problems talking to either 192.168.80.1 (the server's tunnel IP), or anything on the 192.168.5.0/24 (work) network, which is great.

The one problem I'm having is that the client can not talk to, or ping 192.168.5.10 (the server's IP on the work network).

iptables isn't blocking anything. Is there some OpenVPN security setting, or Linux setting I'm missing?

5
  • Why do you need to talk to the eth0 interface? Wouldn't talking to or pinging 192.168.80.1 also work? (I guess the route only forwards packets to non-local interfaces, and 192.168.5.10 is local, but I didn't test this behaviour).
    – dirkt
    Commented Apr 9, 2017 at 8:55
  • We have dozens of networks we need to remember at work. The 192.168.5.0/24 network is so common, that it has been implanted in my brain for 2 years - all I need to remember is the last octet of where to find the OpenVPN server, which I do. Remembering the 192.168.80.0/24 (VPN) network is a waste of effort, as I never need to know the IPs on it, unless I'm configuring OpenVPN routes, which is almost never. Yes, I can setup DNS, or use the hosts file, but that's not the point - I don't want a workaround - I want to either fix it, or understand why it can't be fixed.
    – Tal
    Commented Apr 9, 2017 at 14:39
  • I'm not sure how to test the "routing doesn't route to local interfaces, only to remote ones" hypothesis, except by reading kernel code, and I'm too lazy ATM to do that. :-) But I can tell you that the kernel distinguishes between incoming (i.e., to applications) packets and packets it has to route, and I'd actually be surprised if incoming packets would show up on a different interface (eth0) than the one where they were physically sent to (tun0). But I'm not confident enough to just claim that this is the case.
    – dirkt
    Commented Apr 9, 2017 at 15:28
  • It might be related to the reverse path filter (rp_filter). If you are on Linux, could you try echo 0 > /proc/sys/net/ipv4/conf/<InterfaceName>/rp_filter? Insert the real eth interface name there, of course
    – VPfB
    Commented Jun 24, 2017 at 20:16
  • @VPfB I had high hopes for that suggestion as it wasn't something I had tried before, but unfortunately, it doesn't seem to have helped. Setting just the interface in question to 0 didn't help, so I tried setting all the /proc/sys/net/ipv4/conf/*/rp_filter files to 0, but it still didn't seem to work. I'll play around with rp_filter some more when I get a chance, and think about if reverse path filtering would effect me in this case (it's been a crazy day - I can't think right now) to make sure I rule it out, but I would think if that was the problem, setting everything to 0 would work.
    – Tal
    Commented Jun 25, 2017 at 18:42

2 Answers 2

1

The answer is probably because ping used the wrong source IP for the ICMP packet. By default it will choose the IP on the outgoing interface of the packet. In your case it will be 192.168.80.1 at Work and 192.168.80.10 at Home.

Try the following instead:

ping -I eth0 <address>
1
  • When doing a ping from the OpenVPN client to 192.168.5.10, tcpdump on the openvpn server box shows the source IP being 192.168.80.10. The VPN server definitely has a route back to 192.168.80.10. While the openvpn client cannot ping the openvpn server (192.168.80.10 --> 192.168.5.30), the openvpn server can ping 192.168.80.10 just fine.
    – Tal
    Commented Jun 23, 2017 at 14:15
0

Finally figured out my problem. It had nothing to do with OpenVPN itself, and was not possible to solve given the information above. In case someone else runs into this, this is what it ended up being:

My OpenVPN server is connected to 2 different networks, and runs 2 different OpenVPN instances - one listening on one interface and the other listening on the other interface. One of the interfaces is on my diagram (192.168.5.10) while the other one is not - let's call it 192.168.4.10.

To make this work, I have Policy Based Routing rules that say "if packets have a source IP of 192.168.5.10, sends it to Router 192.168.5.1" and "if packets have a source IP of 192.168.4.10, send it to Router 192.168.4.1". This means when OpenVPN connections are being established, they work properly.

The problem is that when I ping 192.168.5.10 from within the tunnel, the return packets hit the same PBR rule and get sent to 192.168.5.1 instead of back out the tunnel. A change to my PBR rules has fixed this.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .