Had tried this and it didnt work, but just now realised I had the gateway wrong. Have set up a daily email to run that script for each gateway that I have, against the same server. Works like a charm! Thanks for your help

+1

@beejayca have you solved your issue? if yes could you elaborate?

found the cure, added rule on vlan100 to use default gateway if going to certain address or host. turns out the load balance gateway lets local traffic out right away, thanks to netblues for giving me the idea

Thanks for your input Jim, appreciate it very much. So from what I understand it should be no problem to add the physical 172.17.11.0/24 network to pfSense and still have the 172.17.11.100/32 route via gw 172.17.10.11 intact since the /32 network (host) is more specific. -Rico

This isn't an Asus forum. No idea how you got here, but this forum is for pfSense from Netgate.

Zero mention of IPsec in your OP.. Just saying..

hey , my situation is im always connected to a wireguard server wire guard can roam between ips so ill always have one public ip... but with the current gateway group fail-over behavior when first gateway goes down ill get timeout until i reconnect my vpn ... reconnecting manually is one thing i dont want to do ... if i enable "flush states when gateway goes down" when im switching from gateway1>gatewway2 its fine and i roam but when gateway 1 comes back online i dont roam back to it... so what i want is do "flush states whenever gateway changes" is it possible via gui ? can i write a script to do that?

@george-94 Well I needed to get this up and running this weekend so yesterday I failed back to using inter-vlan routing on a L3 Cisco switch, and then using the WIndow Server for DHCP using DHCP policies to assign the right IP's to the right subnet. Bummer, I really like what I see in pfSense. I might get back to it again some day.

OK. So I went and got a UPS today to connect to the server for some further power stability. Putting this in place, of course, necessitated powering off and on again the server/PFSense host. Same issue. Cycling NTP this time did not seem to work so I am betting it was coincidentally noted before. I also tried marking the Gateway as up- still same issues with no connectivity. In desperation, I finally go and simply unplug the CAT 5 from the fiber modem and plug it back in. Boom. Full connectivity comes back up immediately. Makes me wonder if ESXI/ the fiber modem is maintaining some sort of state between the two which PFSense can't break till I physically reconnect? At that point, PFSense and the modem synch up and connectivity is restored I suppose. Looks like I am going to have to just make sure it gets reconnected physically every time the server is rebooted. Thanks for the response.

Thank you for your reply. It turns out the solution was simplier than I thought. I just put all 3 WANs in one gateway group with the same tier! They are all VDSL connections on the same wire to the cabinet.

Without do any change now I can access to 192.168.2.114:80, don't know why... I rebooted the firewall like 3 times without see any difference. I'm afraid that at the next reboot I can't access anymore... I didn't change anything between a restart to other. I can't explain this

I just created a specific reject rule to each other network which works.

I'm having the same issue. Except I cannot access any external sites after a reboot also. Changing the default to something else and then back to the gateway group fixes all flow issues. The other option I see of doing is setting the gateway group under lan rules, and setting the routing default gateway to automatic. This breaks "static routes", so additional rules would need to be made for a few static routes I need. I experienced this issue under the RC and now with a fresh install of 2.4.4-RELEASE-p1.

Problem solved: created an outbound NAT rule on interface A that replaced the source address with that of interface B for certain destinations. Since the two interfaces share the same gateway this was not an issue for the ISP - it doesn't care on what PPPoE session a request came from as long as the originating IP address is allowed through the default gateway.