How you do this in the real world where you OWN the IPs is advertise your netblocks out of your different isp with different metrics when your primary goes down that route would go away and they would come in via one of your other routes.

If you do now own the IPs then sure you could change the fqdn to point to a different IP. Many dns services will set this up for you were if IP x doesn't answer so assume down, then they change the fqdn to point to your failover IP with a very short ttl on the fqdn

example
https://dnsmadeeasy.com/services/dnsfailover/

@lazyterrier said in Failover 1:1 NAT:

What I want to achieve is if WAN 2 fails the emails rather than going out of X.X.88.1 go out of X.X.88.4 which does have reverse lookup.

Just set up an outbound NAT rule on WAN1 and X.X.88.4 as translation address.

If you want to prevent the SMTP server to go out to WAN1 if WAN2 is down, add a policy routing rule for the outbound and state the WAN2 gateway.

That is not necessarily true. The default behavior is to remove the gateway from the rule and reapply, which will result in the traffic going out WAN1 (presuming WAN1 is the default gateway). You can set the skip rules on gateway failure checkbox but that applies to every policy routing rule everywhere. And you still have to explicitly block the traffic in question in a later rule or it will probably be matched by a pass any rule further down.

I would make a gateway group specifically for SMTP with WAN2 then WAN1.

I would set outbound NAT (or 1:1) on both WAN interfaces for the SMTP source address to something on each WAN that has the DNS records you need.

Else I would policy route out WAN2 and, on that policy routing rule, set a tag to something like "NO_WAN1_EGRESS" and reject traffic with that tag outbound on WAN1.

Ok the hiding the IP might be personal. But the real reason you might hide your SOA (hidden master dns) is so it doesn't get queried.. So you have your NS local and you can control. On a slow link, etc. But your NSers that everyone uses is out on real connections UP 24x7 and hopefully geographically diverse.

You can also do a hidden secondary, or slave - where the NS at your location is not in the delegation so doesn't get queried but will maintain a copy of your zone that you can use if the other NSers are down, etc. Or that you can query locally, etc.

@johnpoz Thanks for breaking that down. Not sure what I was thinking. I started cleaning things up right after getting your previous thread.

You are right. I missed to mention one detail. My workstation is a little different than the rest of the computers in the network. My eth0 is in another network and my eth1 is in LAN on pfSense site1. Also my default gw is not the pfSense site 1. This is why I needed the additional routing but the rest of the machines don't. Thanks for catching this.

Reboot fixed it - Thanks

Well as long as that rule is above your any any rule.. Remember rules are evaluated top down, first rule to trigger wins.

I realized the Nat policies that were failing was anything nating to my lan interface. Any other interface worked correctly.

To fix this I went in and changed my lan interface from an /24 to a /23 and then back again. After refreshing the interface the Nat policy started working as expected.

Yes, you are right. However the rule which allows tcp port 554 even not needed because of I have an option "pass" in the nat redirection rule for port 554. And I have a question regarding the rule "allow all from internet", not the rule "allow tcp port 554".

Also looks like your suppose to access it via the url, which sure is not going to be direct to your IP... Kind of like plex where you login with your account on plex and directs you to your IP, etc..

Your going to need to validate traffic actually hits pfsense wan on 8089.. When you try and access. But your forward looks good. Is your pfsense behind a NAT? If so then you would have to forward on that device.

is pfsense wan IP public or rfc1918?

@johnpoz

That's true, I also think that it can be changed. But if the vendor says it can't and the customer doesn't want to jump through hoops... I'm done.

Again thank you very much for the time. I appreciate that.

Cheers,

Jack.

First give the Lan IP address to the same subnet as the pfSense,
Turn off DHCP from the router,
Connect cable From the LAN side of the wireless router to the pfsense interface.
do not use the internet on the wireless router.

@chpalmer thanks... very helpful. Traffic seems to be going through pfSense now, it seems like there is also a firewall on the pbx itself that might be the source of my issues.

Honestly, it sounds like you are trying to get one router doing more than it should be being asked to do. Not really that it can't do it but there are two distinctly different purposes in play here.

we own the building and provide guest wireless, but we have tenants, other companies. We don’t need their people seeing our LAN. However, we are an MSP, so at the same time we may have Labtech agents on their machines that need to talk to support.mycomp.com by that external. We also may have PC’s in for repair on the technet, that may be infected with viruses or anything else, but we still need access to our tools from the web.

So yes, on the wifi I literally want it to go out the GuestWifi Net, out the external WAN that is set on and come right back in through the firewall as if it was a completely segregated network with its own firewall but without me stuffing anymore stuff in my racks.

The router is not going to send something out to the internet when it is destined for an address on the router itself. Maybe with policy routing. But it really sounds like things might make more sense if you had a Guest/ISP/Tenant firewall and an MSP/Development/Testing firewall.

All gets infinitely easier with a proper routed subnet you can use on an inside interface instead of this 1:1 + NAT reflection stuff.

To expand on your specific example (thank you for that) when you enable NAT reflection the NAT happens when the connection enters the GUESTWIFI interface. Then the firewall rules on that incoming interface are processed. When you connect from 172.16.2.16 to 123.234.111.226, the first thing that happens is the NAT reflection.

Now you are dealing with a connection from 172.16.2.16 to 10.50.0.22 as far as the firewall rules are concerned.

You are passing traffic on the GUESTWIFI interface to ! ip_TrustedNetworks Does that traffic match the post-NAT destination? I am guessing not as I am assuming 10.50.0.0/24 is included in the ip_TrustedNetworks alias.

(Blocking traffic using a pass to ! rule is another issue for another day. My advice is to BLOCK/REJECT to ip_TrustedNetworks then PASS to any)

So, on GUESTWIFI, you probably want to specifically pass the connections to the REAL IP ADDRESS of the destination host, 10.50.0.22 in this case (limiting to specific ports, etc ok here to, such as destination TCP 25, 587, 465, 110, 143, 993, and 995 for your typical, non-microsoft mail server.)

that has something to do in your software.. has zero to do in pfsense. Can not talk from rfc1918 to public internet... Its no possible..

Why would you have configured manual outbound?

Sounds like something in your software like in ftp when you do a passive or active connection for the data side where the server or the client tells the other how to connect for the data channel. The server or client ftp software has to be configured correctly with the public IP address and not the devices actual rfc1918 address.

interesting, but after the upgrade I didn't see any arp entries on the WAN with arp proxy, I couldn't even ping the upstream gateway. Here is from your link:

If a particular configuration does not work with IP alias or Proxy ARP type VIPs, try with a CARP VIP instead, or vice versa. Address or wait out the potential ARP concerns before declaring one particular type a failure, and always be on the lookout for IP conflicts.

I didn't see any IP conflicts, but maybe the ARP table became corrupted.

https://doc.pfsense.org/index.php/Port_Forward_Troubleshooting