Incorrect outbound policy based routing
-
Hello. We are having an issue with our site-to-site OpenVPN connection. Below is a diagram of the connectivity currently
/24 ARIN IP Allocation–-> HQ PfSense Wan 64.79.X.146 ----> Internet(openvpn tunnel) ---> Spoke PfSense Wan 74.109.X.6 --> Local Lan 10.0.x.1---> Server 10.0.X.248
What we are trying to do is perform a 1:1 Nat from our /24 across the VPN to a server in our remote office. We have this about 90% setup and working sucessfully but we have a single remaining issue. We are experiancing a Asymetrical route. So there is the traffic flow we are seeing.
Outbound Successful Testing
server 10.0.X.248 –> Spoke Pfsense ---> openvpn tunnel ---> hq pfsense --> /24 1:1 Nat address ---> Working internet via 1:1 addressInbound Failed Testing
(Http or ANY service)1:1 internet address–-> HQ PfSense Wan 64.79.X.146 ----> OpenVPN Tunnel ---> Spoke PfSense Wan 74.109.X.6 --> Local Lan 10.0.x.1---> Server 10.0.X.248
We did packet captures on all the interfaces and the 1:1 nat packet is recived by the server sucessfull. the server responds but instead of the response going out over the OPENVPN connection back to our HQ pfsense to be natted to the 1:1 address. Instead it is going out the local pfsense wan address 74.109.x.6. Obviously the connection doesnt work with that setup.
We have Sucessfully setup the OpenVpn connection between the sites. We can perform outbound 1:1 nat sucessfully, but when we try to access public resources inbound we end up with an asymetrical route to the wrong NAT address.
This is the ruleset we are using for Policy based routing.
ID Proto Source Port Destination Port Gateway Queue Schedule Description
- 10.0.X.248 * ! 8.8.8.8 * VPS_NAT none
Can anyone provide some guidance or assistance on getting this routing troubleshot?
-
bump**
-
bump
-
These kind of questions rarely get a (satisfying) answer. I found numerous (much older) issues like yours with no answer.
I'm experiencing a similar issue and the async routing was classified as a feature.
-
The problem here is that the return traffic has no way to know it's supposed to go back over the VPN in this case. So it tries to leave out of the internet connection, and either gets blocked for lack of a state, or gets blocked at the client because the IPs don't match up.
The "client" for the inbound traffic is not known as one that needs to be routed across the VPN.
Normally, multi-wan sorts this out by using reply-to on the firewall rules on the interface, however we don't add that for VPNs. It may be possible to do that in some cases where the OpenVPN interfaces have been assigned. We have talked about adding a manual reply-to field populated with gateways to choose from, but that hasn't materialized yet.
