3 offices, OpenVPN clients cannot communicate with remote offices
-
I've been searching through the forums for an answer and believed I've found it however I just cannot get this to work. We have 3 offices using 3 different routers currently. Office 1 uses Cisco ASA, Office 2 uses pfSense and office 3 uses a Netgear Business router/firewall.
Office 1 (10.200.0.0/16) <–IPSEC--> Office 2 (192.168.50.0/23) <--IPSEC--> Office 3 (192.168.4.0/23)
Office 2 is using pfSense and OpenVPN for its staff. This is the office in question. the pfSense IPSEC between all 3 offices works great and each can communicate. This issue that comes into play is the Office 2 has OpenVPN clients. Their IP Pool is 192.168.53.0/24. On the OpenVPN server the following settings are in place:
IPv4 Local Network/s - 192.168.50.0/23,192.168.4.0/23,10.200.0.0/16
Advanced Config - push "route 192.168.50.0 255.255.254.0";push "route 192.168.4.0 255.255.254.0";push "route 10.200.0.0 255.255.0.0";When OpenVPN client connect to the server, they can only communicate with the 192.168.50.0/23 subnet and no other office. The IPSEC works fine from within the building, just not external OpenVPN clients.
On office 1 and office 3's end, theres phase 2 rules on the IPSEC to account for both the 192.168.50.0/23 and 192.168.53.0/24 subnets.
I'm confused as to why these openVPN clients cannot communicate with anyone outside their own office (2). I've even tested with having the firewall for the openvpn and ipsec wide open and that did not help. I only did this to test to make sure my rules were not effecting it, but it was a no go.
Any ideas would be greatly appreciated :)
Thanks!
-
IPv4 Local Network/s - 192.168.50.0/23,192.168.4.0/23,10.200.0.0/16
Advanced Config - push "route 192.168.50.0 255.255.254.0";push "route 192.168.4.0 255.255.254.0";push "route 10.200.0.0 255.255.0.0";Just a comment that those push route advanced statements are no longer needed from 2.1 onwards. The list in Local Network/s generates a push route for each network in the list. But I don't expect that having those in there will break it.
The words you say about IPsec Phase2 entries sound good - that is usually the problem others have had, getting the remote offices to know about the existence of the OpenVPN "Road Warrior" subnet across the IPsec link. I am no IPsec expert, so will leave it to someone else to think of likely issues. -
I tried removing the advance config but still have the same issue. Is there something I need to do on the IPSEC connections to each remote office?
Hopefully someone has an idea to go off of?
-
Also noticed that if an OpenVPN client does an ipconfig /all, no gateway is filled in. Should one be there? I would assume so…no?
Route Print:
IPv4 Route Table
Active Routes:
Network Destination Netmask Gateway Interface Metric
10.200.0.0 255.255.0.0 192.168.53.1 192.168.53.2 30
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
192.168.4.0 255.255.254.0 192.168.53.1 192.168.53.2 30
192.168.50.0 255.255.254.0 192.168.53.1 192.168.53.2 30
192.168.53.0 255.255.255.0 On-link 192.168.53.2 286
192.168.53.2 255.255.255.255 On-link 192.168.53.2 286
192.168.53.255 255.255.255.255 On-link 192.168.53.2 286
224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 192.168.116.112 266
224.0.0.0 240.0.0.0 On-link 192.168.53.2 286
255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
255.255.255.255 255.255.255.255 On-link 192.168.116.112 266
255.255.255.255 255.255.255.255 On-link 192.168.53.2 286 -
Here is an example of me on 192.168.44.0/22 with an OpenVPN working through tunnel 10.50.32.0/24 to networks 10.49.0.0/16 and 10.51.0.0/16
I still have a default route (0.0.0.0) to my real internet gatewayat 192.168.44.250 - it is rather odd that your client can establish the OpenVPN connection but not actually have a default route at the top of the list! but at least the other routes to the various office subnets across the OpenVPN tunnel are there.IPv4 Route Table =========================================================================== Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 192.168.44.250 192.168.47.3 20 10.49.0.0 255.255.0.0 10.50.32.5 10.50.32.6 30 10.50.32.1 255.255.255.255 10.50.32.5 10.50.32.6 30 10.50.32.4 255.255.255.252 On-link 10.50.32.6 286 10.50.32.6 255.255.255.255 On-link 10.50.32.6 286 10.50.32.7 255.255.255.255 On-link 10.50.32.6 286 10.51.0.0 255.255.0.0 10.50.32.5 10.50.32.6 30 127.0.0.0 255.0.0.0 On-link 127.0.0.1 306 127.0.0.1 255.255.255.255 On-link 127.0.0.1 306 127.255.255.255 255.255.255.255 On-link 127.0.0.1 306 192.168.44.0 255.255.252.0 On-link 192.168.47.3 276 192.168.47.3 255.255.255.255 On-link 192.168.47.3 276 192.168.47.255 255.255.255.255 On-link 192.168.47.3 276 192.168.56.0 255.255.255.0 On-link 192.168.56.1 276 192.168.56.1 255.255.255.255 On-link 192.168.56.1 276 192.168.56.255 255.255.255.255 On-link 192.168.56.1 276 224.0.0.0 240.0.0.0 On-link 127.0.0.1 306 224.0.0.0 240.0.0.0 On-link 192.168.56.1 276 224.0.0.0 240.0.0.0 On-link 192.168.47.3 276 224.0.0.0 240.0.0.0 On-link 10.50.32.6 286 255.255.255.255 255.255.255.255 On-link 127.0.0.1 306 255.255.255.255 255.255.255.255 On-link 192.168.56.1 276 255.255.255.255 255.255.255.255 On-link 192.168.47.3 276 255.255.255.255 255.255.255.255 On-link 10.50.32.6 286 =========================================================================== Persistent Routes: None
I really expect it will be an issue with IPsec phase2 and successfully telling the other offices the route back to the OpenVPN road warrior tunnel subnet.
-
Thanks for the reply. We ended up resolving the issue on Monday and it was indeed an issue with the phase2. It was a problem with the route coming from the Cisco router and the Netgear. Everything was good in pfSense, just had to get the configs right on the other ends. We just had 1 thing on each crossed up. Thanks guys!