I wouldn't advise opening up SMB to the internet.

OK, sorry. I should probably be a bit more polite. After all you are an older guy. While I'm a young buck at 52!

@Derelict hinted at it but I'll reinforce what he said and state it directly: DO NOT PORT FORWARD TO A DVR Unless you want someone on shodan watching your cameras for you, setup and use a VPN to reach your DVR and do not expose it directly to the Internet. The security on those types of embedded systems is notoriously awful. The networking stacks are weak, and the UI is probably full of holes.

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?