Open VPN Routing. Need to route traffic between 2 remote offices.
-
Hi All, I did search and it seem like theres a million threads on this I know sorry. But every thread seems a little different.
Anyway I've got 3 PFSense boxes, 1 at main office, and two remote offices.
I've got a Site to Site VPN between Main Office and Remote Office 1
Also Got a Site to Site VPN between Main Office and Remote Office 2Main Office can ping devices at both remote offices
Remote Office 1 can ping devices at Main Office
Remote Office 2 can ping Devices at Main OfficeHow do I get Remote Office 1 to be able to Ping Remote office 2, and vise versa?
Main Office is 10.100.100.0/24
Remote Office 1 is 10.1.49.0/24 and its private OpenVPN tunnel network is 10.0.145.0/24
Remote Office 2 is 10.1.50.0/24 and its private OpenVPN tunnel network is 10.0.146.0/24Thanks in advance for reponding to a question thats likely been answered 100 times. ;)
-
The easiest way would be to create a site-to-site VPN between remote offices. That way the appropriate traffic gets passed directly between them rather than having to make the trip through one tunnel to the main office and then through another to the other remote office.
Otherwise, add the remote office subnets into the tunnel definitions for your tunnels at the main office (you'd add site 2's subnet into site1's vpn config and vice versa) making sure that your firewall rules allow the traffic to pass.
Make sense?
-
I'd like to route all the traffic thru the main PFSense for now. If not for any other reason than to learn how to do it.
So are you saying that on the Remote Office side, in the Tunnel config under "IPv4 Remote Network/s" I need to specify the subnet for both the Main Office as well as Remote Office I'm trying to route to?
If so, I did already try that without success. Although On the Main Office box, under "IPv4 Local Network/s" I added all three subnets. Was this wrong?
Also I did not add any firewall rules. Right now its wide open under the Open VPN firewal Rules. Allow "any" to "any".
Comments?
Thanks! -
That all sounds good - adding Remote Office 2 network to the "IPv4 Remote Network/s" box at Remove Office 1 and vice-versa is correct. IMHO you don't need to add anything extra to Main Office "IPv4 Local Network/s".
Make sure that the LAN rules at Remote Office 1 allow traffic to Remote Office 2 subnet and vice-versa. Perhaps there are policy-routing rules at the remote offices that are accidentally pushing this traffic to the public WAN, rather than letting it go on the OpenVPN.
Do some traceroute from Remote Office 1 LAN to Remote Office 2 LAN and see the path it takes and when it stops responding. -
Thanks for the info. The request is timing out on 10.0.145.1 which is the main office side of the Open VPN private Network.
-
I would use push routes in the client config at Main Office instead. This has the benefit of managing these routes in one place instead of at the remote offices, which have a nasty habit of being unreachable when you need to make a change. Another strong benefit to client-specific overrides is making a change to them doesn't force an OpenVPN reload. You can make a bunch of changes to a bunch of different client entries then reload the server once.
If you don't have them already, add client-specific-overrides for Remote Office 1 and Remote Office 2 on the Main Office pfSense. These overrides match on the Common Name of the client site, presumably in the client cert.
In the advanced section of Remote Office 1's client-specific entry add:
push "route 10.1.50.0 255.255.255.0";
In the advanced section of Remote Office 2's client-specific entry add:
push "route 10.1.49.0 255.255.255.0";
Then be sure that all the firewall rules on all the OpenVPN interfaces are set to pass the desired traffic in from all the remote networks. You probably want "pass any any" to get it working then narrow it if desired.
-
I added those push statements to each clients config on the main pfsense box but still no luck. I did not understand what you meant by this statement:
These overrides match on the Common Name of the client site, presumably in the client cert.
Was there anything else you meant for me to do in addition to the push statements?
-
It means if you are using certs for your clients, the CN X.509 attribute in that cert must match the Common Name in the client-specific override in order to be applied. Otherwise, I believe it matches on the username.
You also need to restart the service to pull in the changes:
Status OpenVPN, restart OpenVPN Service.
-
I'm using a shared key.
Still no luck, I've got the push statements in as you suggested. Traceroute still stops at 10.0.145.1.
I'm not sure how much these private networks play in with the Open VPN tunnels? Should I try putting the two remote offices on the same openVPN private network? right now one is set to 10.0.145.0/24 and the other office is 10.0.146.0/24.
Perhaps i should try pushing these routes too?
-
Oh. Sorry. Client-Specific overrides only work for SSL/TLS connections, not shared key, at least as far as I can tell. I've never worked much with shared key on openvpn since I went to openvpn to get away from shared key.
No, putting them on the same private network won't help unless you bridge, which is even more complicated..
Forget everything I said and add the routes to the remotes as specified above.
If you're in learning mode, you might consider ditching shared key and generating some certificates.
