SOLVED: OpenVPN Site-To-Site Gateway Won't Come Up

My gateway for the the OpenVPN Peer-to-Peer server won’t come up, the OpenVPN is configured, the interface is created, the gateway is created. Now if I restart the server, OpenVPN is up but the gateway is showing as 100% packet loss. Follow through the config, add firewall rules, NAT etc. but no change.

I’m using 1.1.1.1 as my monitor IP.

No duplication in my IP subnets.

I have several Remote Access servers running, but for the life of me I can’t figure this out.

Any tips on how to troubleshoot the gateway ?

I assume this is in pfsense so check the logs for an error message. If it’s not pfsense, still check the logs for an error message.

Yes it’s pfSense 2.5.2.

Inspecting the Gateway logs yields:

Those two addresses are same for my other “OpenVPN” gateways, so I assume they ought to be the same for a peer-to-peer GW.

If this is the source of the error, how is that fixed ?

The dpinger service is not telling you the gateway is not up but that is is not reachable. I have an older video but still covers the basics of OpenVPN site to site.

Or you could use Wireguard:

Ha ha I did see that video, sounds like user error then. Let me give this another go.

I did notice pfSense will deprecate pre-shared keys for OpenVPN in the future, so perhaps I got my certs wrong somewhere.

Let’s try again.

Still having trouble getting this to work, might as well detail this out as I know I have made a minor error and can’t spot it.

Have a basic connection between two sites for 2 vlans as below:

Site2Site.drawio

I’ve basically followed the pfsense setup for 2 sites

https://docs.netgate.com/pfsense/en/latest/recipes/openvpn-s2s-tls.html

I noticed in the example for the OpenVPN server configuration it adds the remote network subnets into the local network entry as well, it says enter ALL networks.

I’ve setup my CA and certs, I believe it works as it should.

My Setup looks like this:

My Create Client-Specific Overrides look like this:

My WAN rule looks like this:

I’ve created an interface:

My firewall rules for the interface look like this, in the alias all subnets I use are included:

My outbound NAT rule:

At this stage on the Server side I believe that gateway should be up, before even looking at the client but still not up.

Can’t quite tell if the route is setup correctly:

I have setup the client side also and it appears that there is a connection of sorts:

Any clues on what I’ve messed up I just can’t see it …

Ok so changing the Tunnel IP from a /24 subnet to a /30 subnet made the connection come up (also disabling the Client Specific Overrides).

I do not fully understand why however ? Can anyone explain this jiggery-pokery ?

It might still take me a couple read-throughs to digest all this, but some things that stood out for me:

  • Server Config
    • 192.168.140.0/24 should be fine as an IPv4 Tunnel Network, although obviously rather large if you’re only ever going to have two end points - server & client. If you did want to use a smaller subnet, you can in theory go down to a /30, but I usually “reserve” at least a /29 for even the smallest of tunnel networks.
    • 10.10.10.0/24 present in both Local & Remote networks seems odd. I would list it in IPv4 Remote Networks only, and add any additional/future peer subnets here when expanding the scope of the VPN.
  • Client Specific Overrides
    • Clear both Tunnel Network & Local Network/s
    • Leave only 10.10.10.0/24 in Remote Network/s
    • If you want to force the tunnel end-point IP in use by this specific override add to Advanced:
      • ifconfig-push 192.168.140.X 255.255.255.0;
      • Don’t push the subnet ID, first or last usable IPs.
  • Monitor IP 1.1.1.1
    You didn’t show a screen shot of this, and not sure if you meant you’re trying to monitor the VPN Tunnel with this from the client or server end, but I would leave the gateway created by adding an interface to the VPN service as is - the gateway monitor should track it’s state according to the VPN service.
  • Outbound NAT Rule
    Not sure of your intentions here, but if you need to have internet bound traffic from SiteB:10.10.10.0/24 leave out SiteA’s WAN interface, you’ll need to add a rule on SiteB adjusting the gateway to the VPN interface GW, and then your Outbound NAT Rule at SiteA should apply to the 10.10.10.0/24 subnet, not the tunnel network.
  • Just a heads-up
    I’ve occasionally come across pfSense OpenVPN configs that just don’t behave as expected, but eventually came right when deleting and re-creating the service from scratch. Especially while experimenting or changing from say Peer-to-Peer (Shared Key) to (SSL/TLS).

My apologies if I’ve missed the ball-park all together.

@stildalf thanks for your insight, I should say some of my network has grown organically over the years and my knowledge with pfSense, openvpn and networking continues to evolve as I discover I need more features as I tinker away.

Initially I had Remote Access Servers and clients between both sites acting as a Site-to-Site connection, while also doubling up as a method to access my networks when travelling. Then I setup additional RAS servers as my primary means of accessing my networks while on the road. My IP numbering scheme was just based on a simple way I could easily remember everything.

Then I got smart arsed, thinking I ought to decommission my Site-to-Site RAS setup and replace it with an actual peer-to-peer connection, that’s when I had issues, my plan was simply to “lift and shift” using the same IP numbering scheme I had been using to date.

I kept the above /24 simply because it was already in place, however, I’m beginning to think that OpenVPN will treat a /30 subnet differently as it only has 2 (or 4) usable IP addresses. However, I’m yet to fully understand if a /24 and /30 are actually treated differently.

I agree, initially it wasn’t setup in this way. However on the pfSense example they do exactly this unless I’m mistaken.

You make some points that differ from pfSense, though I can’t claim to fully understand this either. It’s something I need to look more into.

Nothing special here, I normally leave this blank but added it to see if there was any effect.

Yes I must have set this up incorrectly then, only need the two sites connected over the VPN.

Yes I can see they are a bit temperamental, though I got the RAS setup without too many issues in comparison.

Thanks for your input it’s very insightful, especially when my main approach is monkey see monkey do :grin: !

Yeah, there’s absolutely nothing wrong in keeping that tunnel network on a /24 (as long as topology is on subnet). I often revert to that, even if just to minimize the cognitive overhead while mentally navigating my subnet prefixes. :slight_smile:

But I think I lead you astray with the Client Specific Overrides, I just had a quick look at one of my working configs. I’ll leave my original post as is, but here’s how it should’ve read:

  • Server Config
    • IPv4 Tunnel Network: 192.168.140.0/24
    • IPv4 Local network(s): 192.168.10.0/24
    • IPv4 Remote network(s): 10.10.10.0/24
  • Client Specific Override
    • Clear Tunnel Network (it’s not being overridden, so defaults to the server config)
    • IPv4 Local Network/s: 192.168.10.0/24
    • IPv4 Remote Network/s: 10.10.10.0/24

And looking at that you can see why the client specific override isn’t really necessary with only one client - the overrides and server configs are actually identical.

But let’s say you added a SiteC to the mix, with a local lan subnet on 10.10.20.0/24, and you wanted comms between SiteB and SiteC through the tunnel as well as to SiteA. Then your configs would present like this:

  • Server Config
    • IPv4 Tunnel Network: 192.168.140.0/24
    • IPv4 Local network(s): 192.168.10.0/24
    • IPv4 Remote network(s): 10.10.10.0/24, 10.10.20.0/24
  • Client Specific Override - SiteB
    • IPv4 Local Network/s: 192.168.10.0/24, 10.10.20./24
    • IPv4 Remote Network/s: 10.10.10.0/24
  • Client Specific Override - SiteC
    • IPv4 Local Network/s: 192.168.10.0/24, 10.10.10.0/24
    • IPv4 Remote Network/s: 10.10.20.0/24

This is one of the neat benefits of Peer-to-Peer (SSL/TLS) with overrides, it can scale relatively easily to SiteD, SiteE, etc. With Peer-to-Peer (Shared Key), while perhaps easier to setup, you’d need an additional server config (and tunnel network) per leg to achieve something similar.

1 Like

Right, now I see the purpose of the Client Specific Override, thanks for making that clear.

I wasn’t too far off, I find it a bit tricky to troubleshoot when I clearly don’t fully understand the technology :stuck_out_tongue: thank you for your explanation.

There is a 3rd network in the works, though that will be in a while, this is very useful info.

My apologies, just double checked this and I see I got it wrong again with regards to the 3-way config - when SiteC is in the mix.

Basically you gotta:

  • add all the networks that will potentially be accessible through the VPN to the Server’s Local Networks. Typically this includes any of SiteA to SiteX’s local LAN subnets.
  • add all the VPN client subnets to the Server’s Remote Networks. Typically only SiteB to SiteX’s local LAN subnets.
  • Override each SiteB-X with the topology applicable to it (from the server’s perspective).

So the 3-Site config should look like this:

  • Server Config - SiteA
    • IPv4 Tunnel Network: 192.168.140.0/24
    • IPv4 Local network(s): 192.168.10.0/24, 10.10.10.0/24, 10.10.20.0/24
    • IPv4 Remote network(s): 10.10.10.0/24, 10.10.20.0/24
  • Client Specific Override - SiteB
    • IPv4 Local Network/s: 192.168.10.0/24, 10.10.20./24
    • IPv4 Remote Network/s: 10.10.10.0/24
  • Client Specific Override - SiteC
    • IPv4 Local Network/s: 192.168.10.0/24, 10.10.10.0/24
    • IPv4 Remote Network/s: 10.10.20.0/24

The other benefit of Peer-to-Peer (SSL/TLS) with Overrides is the fact that these topology settings can essentially be managed from one place - SiteA’s server and overrides. Add a new SiteX or perhaps a new VLAN subnet, restart the VPN server service and you should be good to go. Take my word for it, I found it quite hairy to make topology changes on Peer-to-Peer (Shared Key) VPNs with more than a couple end points.

Thanks for that. My 3 site setup is a bit in the future, however, a network config might be better rather than a hub and spoke config (it’s only home networks). Though I finally have my virtual environment setup, so I can now actually test in a test environment rather than in live!