OpenVPN routing issues - 2.1.5 and 2.2.1 - *Solved*

rkelleyrtp

Greetings all,

I have an OpenVPN site-to-site setup that has been working flawlessly between my home and office network when both sites were running 2.1.5. However, after upgrading my home to 2.2.1, it seems I have run into some sort of routing issue.

My office is running pfSense 2.1.5 as the OpenVPN server, and my home device is running 2.2.1 as a remote client (Peer-to-Peer pre-shared key setup). I have two networks at the office (172.16.157.0 and 172.16.158.0) that are included in the OpenVPN setup as the Remote IPV4 networks, and the tunnel network is 10.0.250.0/30. The home pfSense has a LAN IP of 172.16.201.1/24, and the office has a primary LAN IP of 172.16.157.1/24 with a Virtual IP of 172.16.158.1/24

When the VPN is running, my home clients cannot access anything on the 172.16.157.0 network, but they can access the 172.16.158.0 devices. I tried various OpenVPN options, validated the OpenVPN firewall rules (allow all), rebooted the 2.2.1 server, etc. However, my clients still cannot ping/access anything on the .157 network. If I run the traceroute command from PC1 to the .157 network, I get the following:


$ traceroute 172.16.157.5
traceroute to 172.16.157.5 (172.16.157.5), 64 hops max, 52 byte packets
 1  172.16.201.1 (172.16.201.1)  0.464 ms  0.239 ms  0.232 ms
 2  * * *
 3  * * *

Next, I try the same thing for the .158 network:


$ traceroute 172.16.158.5
traceroute to 172.16.158.5 (172.16.158.5), 64 hops max, 52 byte packets
 1  172.16.201.1 (172.16.201.1)  0.376 ms  0.212 ms  0.199 ms
 2  10.0.8.1 (10.0.8.1)  18.384 ms  16.862 ms  19.946 ms
 3  172.16.158.5 (172.16.158.5)  19.934 ms  18.717 ms  16.846 ms

Notice the second hop in the .158 traceroute. This is the local IP of my home pfSense VPN connection. It seems the local pfSense 2.2.1 router is not routing packets destined for .157 across the VPN tunnel. I have rebuilt the tunnel 3 or 4 times now and tried from various PCs on the home network. Still, my home PCs cannot get to the .157 network.

Oddly enough, this exact setup was working properly when both sides were running pfSense 2.5.1.

Any pointers?

divsys

Hi,

Can you post screen shots of your OpenVPN server and client setups?

As far as things working OK on 2.1.5 and then "breaking" with 2.2.1, there have been cases of 2.1.5 setups that shouldn't have worked but "unfortunately" did work through various collaborations of events.

Your setup sounds reasonably straightforward and it shouldn't be difficult to get this up and going.
Ver 2.2.x has improved the setup of OpenVPN and removed a number of gotchas from the past.
Any reason you don't want to bring the office system up to 2.2.1?

marvosa

Post the server1.conf and client1.conf from both sides.
A network map would also be useful.

Derelict

I have two networks at the office (172.16.157.0 and 172.16.158.0)

the office has a primary LAN IP of 172.16.157.1/24 with a Virtual IP of 172.16.158.1/24

No, you have one network with a VIP.

Why the VIP?

cmb

@rkelleyrtp:

It seems the local pfSense 2.2.1 router is not routing packets destined for .157 across the VPN tunnel.

It more than likely is, otherwise the traceroute wouldn't die, it'd go out via the Internet.

Make sure there isn't any overlapping IPsec config in place. Verify the routes on both sides under Diag>Routes. Assuming there isn't any overlapping IPsec, I suspect the issue is it's going over the VPN, but the remote end doesn't have a return route for the other network, hence no reply with TTL exceeded in transit when it hits the opposite end of the tunnel.

rkelleyrtp

Solved!

Thanks everyone for the great hints - especially CMB about the IPSec overlapping addresses.

Prior to setting up OpenVPN, I had an IPSec tunnel working but wanted to try OpenVPN for data compression. While I disabled the IPSec tunnel on my home router, it appears I forgot to disable it on the office router. Thus, the remote router had a route back to my home network via the IPSec tunnel and not the OpenVPN tunnel.

Appreciate all the good replies!