OpenVPV site-to-site, only the first Remote Network is reachable from LAN
-
I know, I've read your post. :-)
AFAIK your CSO is still incorrect....I'm not sure what happens when tunnel and local network is specified there, maybe it's the behavior you report.-Rico
-
@rico
You mean-<common_name> <![CDATA[vpn-client]]> </common_name>
?
Sorry, I just wrote it bad, now it's correct. -
It‘s better to post screenshots of your OpenVPN and CSO configuration, not the conf files.
-Rico
-
Screenshots as requested:
OPENVPN SERVER CONFIGURATION:
OPENVPN CLIENT SPECIFIC OVERRIDES:
TESTS IF REMOTE NETWORKS ARE WORKING:
Actually I have ping replies only from the first subnet in remote networks 192.168.10.0/24
I can't reach the second subnet 192.168.90.0/24PfSense is doing some wrong thing in routing, as you can see from traceroute. Packets to the subnet 192.168.10.0/24 are correctly routed through the VPN tunnel, but packets to the subnet 192.168.90.0/24 are not routed through the VPN tunnel, both static routes are active as you can see from screenshot
Is this some nasty bug or am I missing something?
Thanks
-
What does the routing table look like on the client when it is connected?
ROUTE PRINT
The mode you are using is designed to be talking to another router.
The OpenVPN client for Windows is designed as a remote access client and is not necessarily designed to have routed subnets behind it.
You have two clients connected using the same CN. How is OpenVPN supposed to know where to route what?
-
In the remote site there is a Mikrotik router RB760 acting as OpenVPN client, behind that router there are various clients / devices in two phisically separated subnets (one port of the RB760 has IP in one subnet 192.168.90.1/24, another port has IP in the the other subnet 192.168.10.1/24). From the remote site everything is working, from clients / devices in both subnets, having Mikrotik router as gateway, I can reach every device in the LAN subnet 192.168.1.0/24 (other side of the VPN tunnel)
This is the network diagram of the infrastructure:
The problem is in the "LAN SEDE GARLAND" subnet, in this subnet every device has pfSense IP 192.168.1.2 as gateway, so the routing for the two subnets reachable via OpenVPN must be done by PfSense, in fact in the routing table of PfSense there are the correct routing entries:
As you can see, there are entries:
192.168.10.0/24 with gateway 10.10.10.2 (endpoint of the vpn)
192.168.90.0/24 with gateway 10.10.10.2 (same endpoint of the vpn)In the clients there are no routing entries referred to subnets 192.168.90.0/24 and 192.168.10.0/24 because these must be handled by PfSense.
With the routing tables shown in client and PfSense, why is there this behaviour?
192.168.10.10 is correctly routed through VPN (2nd hop is 10.10.10.2, vpn endpoint)
192.168.90.98 is not routed through VPN, in fact it is routed through 192.168.30.1 (default gateway in PfSense) -
Any policy routing on your LAN rules?
-
I have two gateways in failover configuration, the VPN is active only in the default gateway, I don't need that to work in case of primary gateway down
-
You are probably policy routing that other VPN remote network out WAN. See where you are doing that and remove it.
If in doubt add a pass rule for protocol any source LAN net dest 192.168.90.0/24 with no gateway set at the top of the LAN rules.
-
Thanks you very much.
Adding the rule in Firewall - Rules - LAN now it's working and packets are correctly routed for both subnets.
I checked all the firewall rules and there is no rule with 192.168.90.0/24 as source or destination, so I can't really understand why PfSense is routing that network through the WAN. Now it's working with the rule added, so it's ok for me.Thanks
-
We would need to know the contents of all of those aliases to be able to be more sure. One of those rules is policy routing the traffic.
-
This is the alias list: