OpenVPN does not route traffic to remote IPSec branch offices.
-
Hello,
I have a pfSense 2.2.1 installed in the HQ hosting the OpenVPN for remote users. I also have two branch offices on pfSene (same version) connecting to the same HQ pfSense box using IPsec.
HQ subnet - 192.168.10.0/21
Branch1 - 192.168.21.0/24
Branch2 - 192.168.23.0/24
OpenVPN - 172.16.1.0/24
On the HQ pfSense box I have set for the OpenVPN server under IPv4 Local Network/s the three 192.168.10.0/21,192.168.21.0/24,192.168.23.0/24 so this way the route for the 3 subnets is pushed out to the OpenVPN clients which I know change the routing table as I have confirmed this. So the 3 subnets are routed to the OpenVPN server in the HQ.
On the branch offices I have two phase2 one on the IPsec, one with the HQ LAN subnet (as remote subnet) 192.168.10.0/21 and the other with 172.16.1.0/24 (as remote subnet). So traffic back from branch offices should reach the HQ pfSense box.
OpenVPN clients can reach any machine at the HQ with no problems but they cannot reach any o the branch offices thought the IPsec. I do not want the configure site to site OpenVPN as the IPsec has been working reliable between the HQ and the two branch offices for years.
What can I do to set properly routing between the OpenVPN clients and the remote offices.
Thanks. -
What about all the necessary OpenVPN and IPSec firewall rules?
-
I allow all traffic between the OpenVPN and the two IPSec on both directions while I am trying to get this working.
Thanks. -
Then I guess you have to post screenshots to get more eyes on things because if you had done all that it would be working.
-
I don't think this is a firewall issues, it is a routing issue. When I run a trace route from an OpenVPN client trying to reach one of the branch offices this is what I get:
C:>tracert 192.168.23.1
Tracing route to 192.168.23.1 over a maximum of 30 hops
1 15 ms 14 ms 12 ms 172.16.1.1
2 11 ms 10 ms 10 ms domainname.com [206.201.5.180]
3 * saddleback-rs-mv4 [64.58.128.9] reports: Destination net unreachableTrace complete.
So the HQ box is sending the packets to the default route instead of sending them through the proper IPSec to the branch office. Looks like it's not aware of the IPSec it's running on the same box.
Thanks.