Yeah Rico hit it on the head.. Where you can run into problems is when the site could be really any IP owned by the CDN its being hosted on.. So the specific IP you use could change all the time..

And some of these have ttls as short as 60 seconds for example... So when the filterdns process runs (every 5 minutes by default) that populates your alias for www.somedomain.com you get IP 1.2.3.4... But then 3 minutes your client wants to go there and you get 4.5.6.7 which is not in your alias.

Even if you put in the whole swath of IPs that are owned by CDN.. you now get sites that you might not want going through the vpn since they are hosted on the same CDN, etc.

So while yes you can do it.. Be aware that there could be complications based upon if that fqdn is hosted on CDN..

Yes having the same GW for multiple WAN IP:s worked (at least for me) fine for a while. This is basically the only option you have if you want to run with multiple wan IP:s and your operator is providing you with multiple IP:s with DHCP (mine gives up to 5, no static IP:s available) . Off course for monitoring of GW one must use different targets for every GW.

For testing purposes I did do a fresh install of Pfsense 2.4.4-RELEASE-p2 and the problem seems to stay.

Annoying part is that this setup now works, for a while, then it goes offline, and soon works again :).

@Rico
Hi , I have tested this approach and configured CoDel Scheduler and used it for a while and tried diffrent combination of it's options but the mai nproblem is that is causes web access slowness on entire clients, no body can use internet correctly, some websites not opening right a way and take a long time to load but as soon as we disable schedulers every thing is ok!

i think configuring scheduler and CoDel and Queues needs some advanced expertise. guidelines provided in the video and pfsense docs not enough to use them, at least for me.

It looks to me like you need to:

Change your default gateway from Automatic to the gateway group. Policy route your LAN traffic to the gateway group

https://docs.netgate.com/pfsense/en/latest/book/multiwan/index.html#multiple-wan-connections

What? This is not a guide. Question asked and answered.

@viragomann Sorry, I misread that IP. I accidentally blocked out my local IP. You are right.

Not sure about the original ASUS firmware, but I have like 10 ASUS RT-AC68U with DD-WRT connected as Site-to-Site OpenVPN to my pfSense Server. Everything working very great and robust.
I'd recommend to check if DD-WRT is available for your ASUS DSL-AC68U.

-Rico

^ exactly - how do you know its not starting the conversation via cell data connection and then switching it to wifi..

All pfsense is saying with those blocks is hey there is not freaking state for that.. Lots of reasons that could happen..

Could be something as odd as switching wifi networks - do you run more than 1? Do you have more than 1 AP? Do you have a AP doing nat, and another not, etc. etc.

Asymmetrical can be a reason for seeing those blocked packets sure, but could be something like pfsense wan bounced and you have it set to reset all states?

@conor
I have removed the LAN Gateway and ... Tadaaam !

PING SRV-1 to RT-1

ping 192.168.1.1 Pinging 192.168.1.1 with 32 bytes of data: Reply from 192.168.1.1: bytes=32 time<1ms TTL=63 Reply from 192.168.1.1: bytes=32 time<1ms TTL=63 Reply from 192.168.1.1: bytes=32 time<1ms TTL=63 Reply from 192.168.1.1: bytes=32 time<1ms TTL=63 Ping statistics for 192.168.1.1: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms

and SRV-1 to DNS :

ping 8.8.8.8 Pinging 8.8.8.8 with 32 bytes of data: Reply from 8.8.8.8: bytes=32 time=14ms TTL=54 Reply from 8.8.8.8: bytes=32 time=14ms TTL=54 Reply from 8.8.8.8: bytes=32 time=14ms TTL=54 Reply from 8.8.8.8: bytes=32 time=13ms TTL=54 Ping statistics for 8.8.8.8: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 13ms, Maximum = 14ms, Average = 13ms

Thank you very much for your help 👏 😁 😁 😁

In an HA environment where all NAT needs a custom rule I would agree.

I like the NO NAT rules in this case. The routed subnet is unlikely to change, leaving Automatic NAT in place.

Personal preference, of course.

Yeah you need them to route the network to you via just directly attaching you via the bigger network.

@Derelict
Interface rule:
1efa4a8e-c5a9-4e55-8b3d-95517c62df16-image.png

Gateway configuration:
ea2aed3f-ed57-4664-b8d9-deab815f6f33-image.png
14422b99-061a-4aa7-93dc-9bd94a461183-image.png

5baefd9a-6fd9-477c-95c8-e9b187ff6ed5-image.png

My LAN address is unable to reach 202.60.9.71 without the LAN rule, should be accessible without it since I have a static route for it.

I already posted my diagram before, but here it is:
e85000c4-22d6-42d8-a1b1-962b859dc0b4-image.png

Besides 172.50.0.0/16 being real IPs and no private RFC1918 range (what can be quite problematic of its own), I think you are missing some routes and policies on the way.

Wouldn't it be easier to just NAT 172.30.1.0/24 via IPSEC so the VPN Clients arriving via IPsec look like they come from a local IP from 192.168.150.x? Otherwise all devices will need policies to allow traffic from and route back and forth between 172.30.1.0/24 and 172.50.0.0/16. So your Main Site pfSense needs to know about 172.30.1.0/24 (if it doesn't, you didn't tell) as well as the CMS Cisco and your Branch Office pfSense needs to know about 172.50.0.0/16.
I'd add that as Phase 2 entries to the IPsec tunnel so the routes will be pushed automatically.

Excellent video !!!
have watched it and will do the implementation tomorrow
can you PM me for further guidance?
willing to pay to get some questions answered.

I would strongly suggest using Virtual IP's within 1 x WAN interface on pfSense.

You can then forward HTTPS (TCP 443) traffic from each virtual IP address to a different host / IP Address internally :)