Routing a service to non-default WAN
-
@viragomann said in Routing a service to non-default WAN:
Add a rule to WAN2 allowing IPSec traffic to the interface IP (if the service is running on pfSense itself), enable logging and state a unique description.
Sounds like what I did first before started with policy routing, NAT etc. to get it working.
Meanwhile, I really don't know what did the trick, but it started working somehow as expected.
Such a relief after so many hours:)
Thank you so much guys!! -
So you added a rule back to pass the IPSec traffic on PE3 overriding the auto-rules?
-
My setup now is this: no policy rules, no static rules, no manual NAT rules. Default GW is WAN1, ipsec listens on WAN2. I have manually opened udp/500 and udp/4500 on WAN2 (no gw set). I think, that was my setup in the first shot. When I tried to disable these 2 rules, it stopped working even though I can't see any denied packets in firewall log. When I added the static routing to the remote ip (still without rules to pass udp/500 and udp/4500 on WAN2), it works.
So it seems that to get pfsense work correctly as initiator on non-default wan you either need to:
set a static routing rule to remote endpoint with the non-default wan
or
set udp/500 and udp/4500 permit rules on the non-default wan
otherwise pfsense sends replies with the default wan instead. -
When pfSense is the initiator it should be the route-to rule that sends traffic via the WAN2 gateway when it's sourced from the WAN2 IP.
When the other side initiates reply-to should apply.
However the auto rules do not appear to add reply-to. Which is interesting.
-
@stephenw10 said in Routing a service to non-default WAN:
When the other side initiates reply-to should apply.
However the auto rules do not appear to add reply-to. Which is interesting.
Pfsense is the responder in my case. Yes, it confused me a lot :) I was about to introduce some wild workarounds. So glad we got it working! Thanks a lot to both of you guys.
-
@mik256 lol, again same issue:) this time with openvpn. Tried all common tricks: policy routing, nat, playing with firewall rules with and without specifying gateway, but openvpn just keeps replying on default wan. Why the hell i just can't make it reply on the interface the request came from:( btw can't really see what policy routing (setting gw in fw rule) could be good for, when the routing takes place before that.
-
So for remote clients connecting to pfSense?
The same thing applies, reply-to should normally pass replies back out of the same WAN as long as the rule passing it in one the specific WAN interface.
However openvpn has some additional setup options for multiwan that can be used instead. So how is it configured?
-
@stephenw10
Yes, remote clients connecting to pfsense. OpenVPN server is listening on LAN (only this interface, there is a port forwarding from another firewall). Tried TCP/UDP. Tcpdump shows requests from clients arrive on hn0 (LAN), but replies are sent from hn1 (WAN), while they need to send back to the firewall.Besides that, I didn't find any additional setup options which might be relevant in openvpn server settings, which do you mean?
Thanks
-
@stephenw10
I found how to deal with that: instead of using LAN for openvpn server, I used a new VLAN interface which has default gateway set to the port forwarding firewall. Nothing else needed to be changed.Seems like having a gatway on interface pfsense treats this interface differently a correctly sends replies.
-
@stephenw10 said in Routing a service to non-default WAN:
Is the gateway actually defined on the interface? That's what configures it as a WAN with reply-to and route-to on rules.
Yup, exactly.
Reply-to only applies to WAN type interfaces. -
@stephenw10
cool! my bad I didn't read this carefully. thanks -
No worries. I remember hitting that issue myself when I first setup pfSense with multiwan. Too long ago to mention!
Until you realise how pfSense determines what is a WAN interface and what that triggers it can easily seem like magic.
