OpenVPN site-to-site routing problem
-
Here's my situation: I set up a SSL/TLS OpenVPN VPN to be able to do a multi-site s2s network.
The scheme is as follows:
local network 10.50.0.0/16
site 1 10.60.1.0/24
site 2 10.60.2.0/24OpenVPN server:
IPv4 only, virtual network 10.70.1.0/24, local network 10.50.0.0/16, remote networks 10.60.1.0/24,10.60.2.0/24Client Overrides:
Site 1 10.70.1.2/24, local and remote as above
Site 2 10.70.1.4/24 local and remote as aboveBoth sites connect fine.
However, the routing table at pfsense states the following:
10.60.1.0/24 gateway 10.70.1.2
10.60.2.0/24 gateway 10.70.1.2So I cannot route traffic to Site2 at all, and I can't figure it out.
In OpenVPN status I see that site 1 virtual network address is as set 10.70.1.2 and site 2 is 10.70.1.4Any thoughts of why the gateway IPs are the same?
-
@efriedman I have a couple of sites with a similar setup. In my CSO entries, the "IPv4 Tunnel Network" is simply the full subnet - 10.70.1.0/24 - for your example.
OpenVPN assigns the correct gateway value for the connected client based on the Common-Name value for the connected client. The gateway value could change depending on the order of connection and OpenVPN updates the routing tables as required from what it knows about a connection.
One issue I've had in the past about making CSO (and OpenVPN parameter changes in general), OpenVPN can be picky about recognizing changes to a live connection. Sometimes I've had to force both the Client and Server to disabled, then bring the Server up followed by the client to verify a change is effective (or not). Worst case I've (rarely) had to do a reboot of pfsense to verify things are stable.
OpenVPN tends to be good about maintaining a link once you have the parameters correct. It's just getting the exact settings you need that can be a bit of trial and error.Edit - fixed typo CSC for CSO
-
@efriedman
Use /30 as "link-nets" , not /24.
Why do you use client overrides , on the link-nets ?/Bingo
-
@bingo600 My understanding of SSL/TLS OpenVPN servers has always been, that you need CSO's when you have a single server instance handling multiple separate subnets.
In the case of the OP, the server needs to route:
Site "A" LAN 10.50.0.0/16 In:"IPv4 Local network(s)"
Site 1 LAN 10.60.1.0/24 In:"IPv4 Remote network(s)"
Site 2 LAN 10.60.2.0/24 In:"IPv4 Remote network(s)"The server has all these subnets (plus the tunnel which is separate again) in it's configuration. But there is no information about how 10.60.1.0/24 and 10.60.2.0/24 are to be reached. They are just combined together in a list. Which client has each subnet? The CSO's tell the server how to route each different subnet in that list according to the CN that connects to the server. That way the virtual tunnel addresses become largely irrelevant.
just my $0.02
-
Ah ... My bad
I might have missed that OP was using one server to serve multiple remote sites.I'm always using one server per remote site.
/Bingo
