Site-to-Site (Shared-Key) client not routing to server subnets (kinda solved?)
-
I was banging my head against this for quite a while, and then seemed to have solved it, but don't understand it at all. Is this a bug?
This is a pretty standard Shared-Key Peer-to-Peer (Site-to-Site) configuration, mostly as seen from the recipe: https://docs.netgate.com/pfsense/en/latest/recipes/openvpn-s2s-psk.html
The only difference is that the Server-side has a 172.45.0.0/16 network, and the Client side has a /24 subnet.
After completely disabling IPsec tunnels, routing between each side (and each pfSense endpoint) works correctly without pushing any custom configurations.
Now, I want to add an additional Server-side subnet to be routed over the OpenVPN tunnel, so the Client configuration now looks like this:
- IPv4 Remote network(s): 172.45.0.0/16, 10.0.0.0/24
Result: Client pfSense (all interfaces) can ping 10.0.0.1, but none of the Client-side machines can ping 10.0.0.0/24 and all of the traffic is being routed to the public internet. However, routes are correctly being created for this subnet on Client pfSense.
If I re-order the remote subnets ...
- IPv4 Remote network(s): 10.0.0.0/24, 172.45.0.0/16
Result: All routing works correctly (Client pfsense interfaces, Client network devices, Client pfsense routes created).
Can somebody explain why re-ordering this would work?
-
@klou You are using the term ip-sec and openvpn on the same problem and this is confusing.
As for the order of remote networks, is it repeatable?
-
@netblues Sorry for not being clear. I'm replacing my IPsec vpn with OpenVPN, so configs exist for both types, with the same endpoints.
By "After completely disabling IPsec tunnels," I was referring to https://docs.netgate.com/pfsense/en/latest/troubleshooting/openvpn.html#ensure-no-overlapping-ipsec-connections
And yes, I could reproduce this by re-ordering the IPv4 Remote networks and refreshing the connections.
-
@klou
I'm wondering, why you are routing a public network to the remote site. However, this may be done and should not cause the issue at all.But I'm basically avoiding spaces between the networks. Possibly you can try to remove it and see if it changes the behavior.
-
I always wondered if the space matters.
It turns out I'm wrong in what "works" -- while the routes are being created for both server subnets (and traffic is passing from Server->Client and back), Client-initiated traffic will only route to the first listed subnet.
I've removed the space, and things look promising. We'll see if this holds up. If so, I can't believe it's something so stupid.