Force ISP route over WAN2 to access WAN1 IP from LAN2
-
Hello,
I'm using pfSense for almost 8 years now and want to thank everybody for this multitalented and easy to use piece of work.
In my 2WAN/2LAN setup there is one thing I have not been able to get working:
How can I make pfSense route traffic from LAN2 via WAN2 when LAN2 tries to access the public IP of WAN1? I want the traffic to go to the ISP2 and then return via ISP1. I do not want to use something like NAT reflection or split DNS to make it work internally.
I tried the basics first: setting the gateway to WAN2 in a rule for IPv4 traffic from LAN2 to WAN1 IP. Alternatively I created a rule for IPV4 traffic from LAN2 to "any" with the gateway set to WAN2. I tried it as interface rules and as floating rules. All variants make LAN2 access the web interface of pfSense on port 443 instead when trying to access https://PUBLIC-WAN1IP-HOSTNAME.
But in my configuration the pfSense web interface is not reachable over WAN1 because of port forwarding of 443 to a web server. So the traffic did not leave pfSense via WAN2 to reenter via WAN1 and to get port forwarded. If I disable the rule the access to WAN1:443 is effectively denied for LAN2 by a floating deny all rule I have in my configuration, so the allow rule is really doing something. Seems to me the internal routing has an "uncanny" priority over the rule gateway in this case.
I tried to find a post matching this scenario but I could not find something that really matches my use case.
If you could give a hint how to proceed I would really appreciate it.
Greetings,
Jens
-
Use a separate router for each ISP!
There is no possibility to route traffic to an IP, which is assigned to an interface of pfSense itself, over another gateway.
-
That was the configuration I had until 2 months ago, but I needed the public IPs to be on the pfSense side to get unnatted VPN on both WANs.
So maybe I could use 2 pfSense routers, one for each ISP, but how to do the WAN failover - with a 3rd pfSense? (just thinking loud, no answer required)
I will think about it. Thanks for your help, viragomann.
Jens
-
Why would you want to do something like that… So you want traffic to go all the way up your wan pipe to your ISP2, then across the internet and come down your wan 1 pipe to hit a IP on your wan1 interface.. To be forwarded in... WHAT?
Why??? Makes NO sense at all....
That like say hey I need to go next door to borrow a cup of sugar... Let me get in my car drive around the city. Stop at neighbors house, then drive all the way back around the city to get back to my house..
I would love to hear how this in anyway shape or form makes a lick of sense...
-
Hey johnpoz,
the reason is quite simple: testing and saving money. I want to have the perspective of a direct connection to the internet (from LAN2 via WAN2) trying to access WAN1 from the outside without any special firewall rules involved like many people have them at home without leasing a 3rd line myself. This way I can test access to WAN1, e.g. web services and VPN from a "home" perspective. I did this with a 3rd line for many years and there have been some cases where this helped to resolve configuration issues on the client or server side that were not obvious when accessing WAN1 internally from LAN1.
As far as I can see I could still use NAT reflection to simulate the overall behaviour.
Jens
-
Nat reflection is not a test of anything - its an abomination in its own right. If you want to test your firewall rules from outside.. Then hit it from outside.. Use a vps on the internet… VPS on the internet can be had for $15 a YEAR... I have multiples of them all over the place for "testing"
Use a box connected to your mobile phone's data... Just disconnect the wan 2 from your pfsense and connect a machine to it..
What exactly are you wanting to test?? Performance - since you forward a port pfsense is done with its job. It works - zero reason to test it.. If you need to validate the port is open then go to can you see me.org a test if the port is open.
-
Nat reflection is not a test of anything - its an abomination in its own right. If you want to test your firewall rules from outside.. Then hit it from outside..
That is why I wanted to do it from the outside in the first place.
Use a box connected to your mobile phone's data…
This is what I currently do.
What exactly are you wanting to test??
I have to support employees working with notebooks with mobile access to my site. By connecting a notebook to a "neutral" line before the next trip I can make sure everything is setup as it should, especially VPN access that sometimes gets bogged after an OS updates messes with the configuration.
Jens
-
You could always route specific clients out a vpn on the client and let that go out wan2, then if hitting wan1 IP it would go down the vpn and come back in your isp1 to get to your wan1 IP.
How exactly did you try and make it work? Policy routing might work, if you set specific clients on wan to to be forced out wan2?
Post up your rules on lan1 an lan2
I can try and simulate this with a vpn connection I sometimes policy route traffic through.
-
You could always route specific clients out a vpn on the client and let that go out wan2, then if hitting wan1 IP it would go down the vpn and come back in your isp1 to get to your wan1 IP.
I am not sure I got the scenario right you have in mind, but I assume you refer to my original idea LAN2 -> WAN2 -> ISP2 -> ISP1 -> WAN1IP -> service (https, VPN, …).
I use two floating rules:
-
block, interface=LAN2, IPv4/v6, protocol=any, any -> any
-
pass, quick, interface=LAN2, IPv4, TCP/UDP, any -> any, Gateway=WAN2
This works well for all outgoing traffic and blocked traffic from LAN2 to LAN1. But when accessing WAN1IP (or WAN2IP) from LAN2 I get the pfSense web interface, although it is not directly accessible via WAN1 or WAN2. For this test there was no VPN involved at all, only the webserver on 443 that is available by port forwarding via WAN1 (I did not want to go for VPN testing if something simpler is not working). I also tried to make the rule more specific by setting destination=WAN1IP:443 but it did not make a difference, the gateway was ignored. There are no related rules for LAN1 in pfSense - access from the "real" LAN1 to the webserver takes a different route and does not pass through pfSense.
-
-
don't do it on floating… policy routing should be done on the interface the traffic enters pfsense on..
