OPENVPN SSL site to Site not working
alocaurd last edited by
Im trying to get a multi site to site config working with ssl/tls. i have one hub and two spokes.
All offices have an Allow All rule set on the openvpn tab, and all offices show VPN connection is online.
From the pfsense boxes, i can ping each others lan IP, and i can even ping the other nets (from branch 1 or 2, i can ping 192.168.0.5 which is the DC at HQ).
The routing table looks fine to me, but for some reason, the PCs in the branch offices cannot talk to the main office net. I dont see any traffic being blocked in the firewall logs either.
Let me know what pages you want screenshots of if you need them.
Hopefully on the main office OpenVPN server you already have both remote subnets listed in Remote Network/s. Then you need the Client Specific Overrides for each branch office. It sounds like you have those, since the offices are getting good-sounding addresses in the tunnel. In those you also need "iroute" statements, like https://doc.pfsense.org/index.php/OpenVPN_iroute_in_CSC_seems_to_have_no_effect
That will tell OpenVPN internally which remote office subnet is reached down which client.
If that does not help, then post screen shots of OpenVPN server and client (obfuscate any keys), and LAN and OpenVPN rules.
marvosa last edited by
Phil, it is my understanding that iroutes are only needed if the remote end is a software client and not a PFsense box.
alocaurd, sounds like there are routes missing, please post the server1.conf and server2.conf from the main office and the client1.conf from both branches.
I use iroute statements in Client Specific Overrides when doing main-site-to-multi-branch-sites with certificates and pfSense at all sites - the iroute statements let the server end decide which subnets are down which client link.
Andyrue last edited by
I'm going to jump in here without trying to hijack the thread, as I'm having what seems to be the same problem.
Main office pfSense - 192.168.11.1 (OpenVPN 172.16.0.1)
Branch Office pfSense- 192.168.7.1
From the branch pfSense server I can ping 192.168.11.1 and 172.16.0.1 successfully.
LAN clients from the Branch Office with 192.168.7.x addresses and 192.168.7.1 as their GW can't ping 192.168.11.1 or 172.16.0.1.
I'm not concerned with the Main office LAN being able to reach the Branch office LAN unless that's needed for this to work, I just want the Branch LAN to be able to reach the Main Office LAN.
Same as the original poster, I have Any to Any rules in both OpenVPN tabs.
On the Client VPN config I have both Tunnel and Remote network fields filled in with the appropriate information
On the Server VPN config I have both Tunnel and Local network fields filled in with the appropriate information as well.
From the client1.conf file pulled from the Branch server
ifconfig 172.16.0.2 172.16.0.1 route 192.168.11.0 255.255.255.0
Should I try the iroute suggestion even if I don't need to specifically go from Main LAN to Branch LAN? Thanks for your advice.
I believe you will still need the iroute statement. But I haven't actually tried this configuration where you only have 1 branch office (so OpenVPN could guess which branch office has the remote subnet - there is only 1!), without using iroute.
Even though you do not need Firewall Rule/s to permit traffic from main to branch (because the traffic from main to branch is all replies that match states initiated by connections from branch to main), the system has to explicitly know how to route in both directions - it does not automagically know how to route reply packets.
Andyrue last edited by
It's working now. Seems it was a combination of things.
I needed the iroutes on the server, and I also had the VPN server configuration set to "Remote Access SSL/TLS" since I was initially using this for Road Warriors, but later wanted to add a site-to-site. Changing it to Peer to Peer gave me an option for Remote Networks on the server side that I didn't see before and once I entered the branch network in there things started working.
Thanks for your help, hope the OP gets it going as well.