Can't Get The Gateway up for a Site-To-Site OpenVPN Connection.

[neogrid]

Hi,

Perhaps someone can spot my error, I've removed my RAS and Client from two pfSense connections and am trying to replace the connection with a Site-to-Site connection, using the same subnets. My target looks like this:

My goal is to connect the two sites over the two vlans. My CA structure is in place and working.

I’ve basically followed the pfsense setup for 2 sites

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

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

My vpn server 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 …

[viragomann]

@neogrid
Is there only a single client connecting to the server or multiple?
If it's only one you should rather use a /30 tunnel network for a site-to-site VPN. So there is no need to configure a CSO.

[neogrid]

@viragomann hi

On the client side there will be multiple machines but I won't run out IP addresses.

However, I thought this configuration / approach should work.

Is the error the CSO ? It looked ok to me.

[viragomann]

@neogrid
The question is how many OpenVPN clients are connecting to the server. The devices behind the client don't matter at all.

If you have only one OpenVPN client use a /30 tunnel and remove the CSO.
If you have multiple clients you need a CSO for each.

[neogrid]

@viragomann It's a single pfSense box. Let me try it.

[viragomann]

@neogrid
So instead of CSO enter the server sides LAN into the "Remote Networks" box in the client settings.

[neogrid]

@viragomann What witchcraft is this ??

Clearly I don't understand something, though I know not what.

Why when I change my tunnel IP from 192.168.140.0/24 to 10.128.240.0/30 (disabling the CSO) does it now work ?

I thought the main principle was that there should be no overlapping IP ranges (I had tried a different /24 subnet I had never used and it did not work either).

[viragomann]

@neogrid
As mentioned, when you use a larger tunnel network, you need a CSO and the configuration gets more complicated.

The CSO is especially needed at server site to route the clients site LAN properly.
If that doesn't work check in the OpenVPN log if the CSO is applied. There are often issues due to wrong common names stated in the CSO or whatever.

[neogrid]

@viragomann ok thanks very much for the help. I must have made a config error, though I'm sure I triple checked everything. I'll look into the CSO a bit more. Thanks for helping out.

[viragomann]

@neogrid
Checked you screens again. The only one failure I can find is the source network in the firewall rule on PEMSITE_A. The pass rules only allows access for the tunnel network, but not the clients LAN.

However, this is also applied now when using a /30 tunnel.
But maybe there are rules on the OpenVPN tab allowing access to any source.

Remember that the OpenVPN tab is an interface group which includes all OpenVPN instances you're running on this node. Rule on interface groups have priority over ones on the interface tab. So if there is a rule for allowing any to any (default after running the OpenVPN server setup wizard), rules on the interface tabs are ignored.

[neogrid]

@viragomann actually I use an alias with my various subnets, including the tunnel subnets, so I believe it is covered. I also use an interface for my OpenVPN servers and don't use the "general" OpenVPN tab as such. That way I have some idea what is going on by doing things manually.

I need to do a bit more digging into this.