^ 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 :)

Thanks for all your help , I have been there and trying to make it work :)

@johnpoz
I use IPSec to create a site-to-site tunnel should the wireless bridge go down. (Hilariously, this is no longer working, but that is a different problem for a different day).

I wanted to use the pfSense for the VPN clients but had too much problems setting it up with the win 10 clients. I only have two VPN clients so it is not really a problem at the moment.

But I will probably sit and redesign the whole network. Or I should just get some hardware routers. The win 10 hosts are giving me hell as well.

@Derelict noted on that. Does a reboot also reset state?

@moo82 said in During transition of default gateway, pfsense is irresponsive for various seconds:

In any event, the J1900 CPU doesn't appear to support AES-NI, so you need to look into a replacement router or CPU upgrade before upgrading to pfsense 2.5. It will possibly be released at some point this year?

That requirement has already been discussed and lifted for 2.5 as it will most likely not getting the REST API. But again, it wouldn't hurt to upgrade before stepping up to 2.5 either ;)

thanks for your help.

actually, in my case, the easier way is to let pfsense create automagic associated rules. i was hoping to separate and delegate the nat rules to other people while managing the firewall rules which is why i wanted this feature. that's a no-go until/unless i create a rules generator.

let's turn it into a nice feature request ;) there is no reason why pf would not be able to store the router's mac and incoming interface and reply-to accordingly ^^ ( i used this setup on some hacked config some years ago with a single interface but multiple gateways which was very convenient. i recollect on an ipfw+ipf based setup on bsd 7 and i actually though it would be builtin pf )

see you around

OK Fixed it. All workiing perfectly now! I had forgot to include OPT2 in DNS resolver's LAN interfaces.. Thats why clients on OPT2 couldnt reach the web, they couldnt resolve sites.

There will always be traffic from gateway monitoring (two pings per second by default) unless it is disabled. If it is disabled you will have to do without knowing if that gateway is up or down.