@bmeeks The minute I started reading your post, I realized the error in my thinking. Since it's on a private (home) network, I wasn't thinking of real external traffic coming in. I kept thinking in terms of it being all on my local LAN, then asked myself why I'm using NAT! I got it...thanks for y'alls help!

I testes the last days and after four reboots still no problems anymore. Looks like it was for the Gateway monitoring. I don't understand the connection between the problem and the monitoring, but tha most important is, that it just works!

@Zawi You are correct, no default gateway was set on my cisco switch stack for my virtual management IP of 10.0.0.126/24. Set gateway to 10.0.0.1, problem solved! Thanks dude, made my day! Happy 4:20!!! from Vancouver, BC, Canada

@info385 Dude, we're talking about the remote access server for the road warrior clients here! You cannot run an access server in Peer to Peer mode. I had suggested the "IPv4 Local Networks" option for the remote access server only, while on the Peer to Peer you only need the "IPv4 Remote Networks" setting.

@JohnKap My understanding was that TLD only worked on subdomains.

A detailed dig or nslookup executed on one of these 'kid' devices ? You are aware of the fact that DNS traffic isn't only UDP traffic ? You saw the first pinned post here ? Can you show the related firewall rule - check if it hits any traffic ?

@Gertjan You are right. I just restored the configuration on my FG that I had working good last night, and voila. However, I'm considering to enable a nic on my ESXi host and send the traffic through the OPT. And not use the same interface for everything.

@serbus John, your bottom rule in the PRI list is redundant. It's saying that on your PRI interface, to block any source to any destination over any port. It's also got zero states with zero traffic. Your 2 PRI to WAN rules can be summed up with a single rule - protocol both IPv4 and IPv6, source PRI net to any destination. Quick question - are there any hosts on this PRI interface, since none of the rules have any hits on them? Looks kinda like a ghost town. What is the PRI network, a guest network? Your PRI to LAN block rule would never get hit, unless you've got IPv6 running on your network. You have an allow rule directly above your block rule, first rule to match wins, no other rules below are evaluated. Hope that helps a little... :) Jeff

[image: 1587252064854-6760b5bf-1128-433b-9288-348428705a47-image.png]

https://docs.netgate.com/pfsense/en/latest/book/firewall/rule-methodology.html Anti-spoofing Rules pfSense uses the antispoof feature in pf to block spoofed traffic. This provides Unicast Reverse Path Forwarding (uRPF) functionality as defined in RFC 3704. The firewall checks each packet against its routing table, and if a connection attempt comes from a source IP address on an interface where the firewall knows that network does not reside, it is dropped. For example, a packet coming in WAN with a source IP address of an internal network is dropped. Anything initiated on the internal network with a source IP address that does not reside on the internal network is dropped. If you look you will see them... [2.4.5-RELEASE][admin@sg4860.local.lan]/root: cat /tmp/rules.debug | grep antispoof antispoof for $WAN tracker 1000001570 antispoof for $LAN tracker 1000002620 antispoof for $WLAN tracker 1000003670 antispoof for $TEST tracker 1000004720 antispoof for $NS1VPN tracker 1000005770 antispoof for $W_PSK tracker 1000006820 antispoof for $W_GUEST tracker 1000007870 antispoof for $W_ROKU tracker 1000008920 antispoof for $DMZ tracker 1000009970 [2.4.5-RELEASE][admin@sg4860.local.lan]/root: pfctl -vvsr | grep 1000002620 @65(1000002620) block drop in on ! igb0 inet6 from 2001:snipped:9::/64 to any @66(1000002620) block drop in on igb0 inet6 from fe80::208:a2ff:fe0c:e624 to any @67(1000002620) block drop in inet6 from 2001:snipped:9::253 to any @68(1000002620) block drop in on ! igb0 inet from 192.168.9.0/24 to any @69(1000002620) block drop in inet from 192.168.9.253 to any [2.4.5-RELEASE][admin@sg4860.local.lan]/root: So again ask how is it this traffic would be allowed.. State table would be for the other interface.. So this traffic would not be allowed in.. If you disabled antispoof, you would be wanting such traffic to happen..??

@teamits oops... you are correct. So busy and got distracted. Thanks for pointing that........... and thanks for your reply. I'll work on it this weekend to not affect productivity. Thanks again

Seems you're missing the route for the servers network on router A. This has to be set in the OpenVPN settings. @Ben-Ktz said in Cant establish connection: I'm able to ping from Network A to the interface of the pfsense which is connected to Router B (192.168.1.1) but I can't connect to the lan interface of the pfsense which is connected to the server (192.168.0.1) Since you know now, pfSense is responding to ping, you may also try to ping its server side interface to investigate. If you don't get a respond you will miss the route.

@johnpoz Again, I agree with what you're saying :) pfSense is the valid gateway, but they were not pointing to it. These cameras have always pointed to .73. All of the involved devices have always lived on the 192.168.111.x/24 network. The pfSense ip has always been the gw for that subnet although pfSense just moved there - pfSense was originally the gw on an outer subnet. Before and after the cutover, the cameras and the DVR_PC could continue to ping each other by IP, so they had each other's MAC resolved and the path to each was known - no hops in between. I had even reset the switch these connect to earlier today because I thought something may have been wrong/bad/corrupted in it's MAC tables. There was never a point where the devices failed to ping each other. I did change the .73 host from a static IP of .73 to a DHCP reservation for it's MAC so that pfSense now hands it .73 but that shouldn't have affected anything either. Changing from a wrong gw on the cameras to the correct one is the only change I made to resolve what I was seeing. I'm sure there is a piece that I don't see that would give us, as Paul Harvey used to say, the rest of the story. I will be making other changes to this network and it is driving me nuts not seeing the missing link so I can say I know what was happening. Thanks for all of the responses. Keeps me on my toes.

I guess I stand corrected. Appreciate the feedback, caps, exclamation points and all.

@humaxoid [image: 1586515236188-cf96414c-43fd-49a6-ac77-7c82c2b4c4da-image-resized.png] result nat on igb0 inet from 192.168.1.80 to any -> 79.XXX.XXX.XXX static-port

@Leonardo-Lowry Do your phone and carrier support Wifi calling? I have lousy cell service in my home but, with Wifi calling, I now have an excellent signal. Added bonus is data does not count against my cell phone.

@raviktiwari said in Parallel Test Environment using 2 pfSense, 2 Static IP, 1 ISP, 1 Gateway: @senseiluke I did exactly what you said and it fixed. So a no brainer from my end. :-) Many Thx: Rav You're very welcome, Luke

Thanks @Konstanti for your care. I'm using cloudflare.com, gstatic.com, liveupdate.symantec.com, liveupdate.symantecliveupdate.com, pool.ntp.org, symantecliveupdate.com, time.google.com, office.com