@Bob-Dig That would be it. Thanks!

Since I'm a network engineer in my spare time only, I didn't know to search for ULA and GUA :)

I'll stick with my floating rule for now and wait for the patch to be patched.

@Derelict said in Firewall drops packets between LAN and OPT1:

mssfix 1400;

Thanks for the suggestion, this seems to be the root cause!
An MTU of 1300 improved OpenVPN connections from my Android phone a lot, it might be flawless now. And yes, UDP is used for the tunnel.

A cloud VM's TCP connections still have hiccups. I'm yet to do further experiments.
The strange thing is that OpenVPN worked with default settings in my previous (similar but not identical) setup.

Are Source "Nets" and "Subnets" the same thing?

Yes.

@coltswalker if you know the hostnames you can create host overrides so they resolve nowhere. I do not recall specifics but unbound has “views” to control access for certain clients. You should be able to find info about that here.

@ziggy94 Cannot see one myself. There is no special routing going on presumably? Very odd especially if one server is running well. Perhaps leave everything as is and do a reboot to see if that cleans things up. Not convenient, i know.

DHCP never was the problem. See the solution in another thread.

@johnpoz: Thanks your keen eye identified the same issue I uncovered in my selectively toggling of rules. Thank you very much!

My problem was that the IP alias OpenDNSFamilyShieldServers are evaluated to the OpenDNS Family Shield servers 208.67.222.123 and 208.67.220.123, whereas in System → General Setup → DNS Server Settings I had 208.67.222.222 and 208.67.220.220. Those are the standard OpenDNS servers. With that mismatch my subnet could not access any DNS server.

The fix was changing System → General Setup → DNS Server Settings.

@Gertjan
found the root of the problem to be that the file had whitespaces, so I deleted it and let the DHCP server to re-assign IP's. I thought I had upgraded it to the latest community Version.

Well, I did a reboot and it appears to be working when I added iplocation.net IP's to the list and these IP's are exiting through the AirVPN USA WAN gateway. But, I'm not getting any success with updating the ifconfig.co IP's even after doing a full update via pfBlockerNG.

Since I'm getting good IP's with iplocation.net, the firewall test working fine.

here's a list that can be imported as an alias of supernets microsoft update uses/owns
used https://geo-lookup.ipify.org/ to look up blocked IP's and then correlate to a block/asn owned by m$

windowsupdate.microsoft.com Entry added Mon, 21 Mar 2022 14:36:24 -0700 download.windowsupdate.com Entry added Mon, 21 Mar 2022 14:36:24 -0700 go.microsoft.com Entry added Mon, 21 Mar 2022 14:36:24 -0700 dl.delivery.mp.microsoft.com Entry added Mon, 21 Mar 2022 14:36:24 -0700 wustat.windows.com Entry added Mon, 21 Mar 2022 14:36:24 -0700 download.microsoft.com Entry added Mon, 21 Mar 2022 14:36:24 -0700 67.24.0.0/13 Entry added Tue, 28 Nov 2023 00:22:34 -0800 8.240.0.0/12 Entry added Tue, 28 Nov 2023 00:23:48 -0800 51.10.0.0/15 MICROSOFT-CORP-MSN-AS-BLOCK 104.40.0.0/13 MICROSOFT-CORP-MSN-AS-BLOCK 52.160.0.0/11 MICROSOFT-CORP-MSN-AS-BLOCK 13.64.0.0/11 Entry added Thu, 25 Jan 2024 14:26:53 -0800 172.160.0.0/11 Entry added Thu, 25 Jan 2024 14:38:23 -0800 20.160.0.0/12 Entry added Thu, 25 Jan 2024 14:43:38 -0800 40.76.0.0/14 Entry added Thu, 25 Jan 2024 14:44:19 -0800 20.64.0.0/10 Entry added Thu, 25 Jan 2024 14:45:14 -0800 40.127.0.0/16 Entry added Thu, 25 Jan 2024 14:50:01 -0800 51.140.0.0/14 Entry added Mon, 21 Mar 2022 14:31:36 -0700 52.160.0.0/11 Entry added Mon, 21 Mar 2022 14:31:36 -0700 20.48.0.0/12 Entry added Mon, 21 Mar 2022 14:31:36 -0700 52.136.0.0/13 Entry added Mon, 21 Mar 2022 14:31:36 -0700 104.107.104.0/22 Entry added Mon, 21 Mar 2022 14:31:36 -0700 40.80.0.0/12 Entry added Mon, 21 Mar 2022 14:31:36 -0700 52.136.0.0/13 microsoft 20.48.0.0/12 Entry added Sat, 02 Apr 2022 18:27:56 -0700 52.160.0.0/11 Entry added Sat, 02 Apr 2022 18:27:56 -0700 51.140.0.0/14 microsoft 20.184.0.0/13 Entry added Fri, 08 Apr 2022 10:02:16 -0700 40.126.0.0/18 Entry added Fri, 08 Apr 2022 10:03:26 -0700 20.40.0.0/13 Entry added Fri, 08 Apr 2022 14:57:24 -0700 52.242.97.97/11 Entry added Fri, 08 Apr 2022 14:58:28 -0700 13.91.16.69/11 Entry added Fri, 08 Apr 2022 14:59:38 -0700 51.10.0.0/15 Entry added Fri, 27 May 2022 18:10:58 -0700 13.107.4.0/24 Entry added Fri, 27 May 2022 18:12:13 -0700 40.112.0.0/13 Entry added Fri, 27 May 2022 18:20:55 -0700 40.125.0.0/17 Entry added Fri, 27 May 2022 18:28:46 -0700 52.224.0.0/11 Entry added Fri, 27 May 2022 18:35:24 -0700 13.107.42.0/24 Entry added Fri, 27 May 2022 18:53:55 -0700 52.152.0.0/13 Entry added Fri, 27 May 2022 18:59:37 -0700 104.40.0.0/13 Entry added Fri, 27 May 2022 19:01:05 -0700 204.79.197.0/24 Entry added Fri, 27 May 2022 19:18:44 -0700 40.74.0.0/15 Entry added Fri, 27 May 2022 19:26:09 -0700 104.84.224.0/22 Entry added Fri, 27 May 2022 19:36:17 -0700 51.116.0.0/16 Entry added Fri, 27 May 2022 19:48:04 -0700 13.64.0.0/11 Entry added Fri, 27 May 2022 20:04:08 -0700 20.64.0.0/10 Entry added Fri, 27 May 2022 20:06:22 -0700 96.7.232.0/22 Entry added Fri, 27 May 2022 20:08:21 -0700 184.30.160.0/19 Entry added Fri, 27 May 2022 20:14:38 -0700 40.127.0.0/16 Entry added Sat, 28 May 2022 10:02:46 -0700 8.240.0.0/12 Entry added Sun, 21 Aug 2022 16:44:27 -0700 54.192.80.0/22 Entry added Sun, 21 Aug 2022 16:45:10 -0700

@Spyderturbo007 said in Rule Help Request - VLANs:

(http://zb-000XXX00.local) which is what has been failing

Why would you think mdns would resolve if your not on the same network? That is a local discovery method..

If you want to use name of something, then give it a fqdn.. host.yourdomain.tld - this can be done via registering static dhcp reservations, or simple host override.

My wifi controller sits on a different network than my pc.. I am on 192.168.9.100/24 and controller is at 192.168.2.13/24

but see it resolves with a fqdn

$ ping uc.home.arpa Pinging uc.home.arpa [192.168.2.13] with 32 bytes of data: Reply from 192.168.2.13: bytes=32 time=2ms TTL=63 Reply from 192.168.2.13: bytes=32 time=1ms TTL=63

Pfsense now defaults to using home.arpa as the local domain, because this is the recommended domain to use locally.

https://www.rfc-editor.org/rfc/rfc8375.html
Special-Use Domain 'home.arpa.'

@Malibucola I am currently unable to test my setup since I have "recently" moved and am in the process of saving up money to have electrical outlets run, therefor my server rack and equipment are off (including my pfsense server) but I vaguely think that was also what I had to do to unblock uploads, I do recall I had fixed it some time ago and clearly forgot to update here with that news/what I did to fix it, but I do recall I freaking hate google and have all the non-required google things blocked and vaguely recall that I think I also figured out that was the domain name in question that fixed it, the URL just has a very hard recollection in memory when I see that domain. so yes, I do think that was what I did to fix it as well.

@Gertjan for extra info, I did follow the guide of "suricata/snort, taming the beasts" and followed it HARD, so, just for extra context, that I am almost positive is half of my problem and why "if users could not access discord, we would know" style of comment is not more applicable, now mind you I am fully assuming this statement to be accurate and am happy to correct if I'm incorrect here however it is likely applicable info to add either way, but yea, I block everything google that is not mandatory for the internet to work (google adsense, analytics, adwords, google api tracking domains that are EXPLICITLY tracking domains, clearly the wrong subdomain of google-apis here as well)

I found my solution. The problem was virtualization specific. I was passing through my ethernet adapter via bridging on Unraid . Although the VM had sole access to the ethernet, this was breaking port forwarding due to some deeper technical stuff I cannot explain. Long story sort, switching to PCI passthrough fixed this. Enabling Multi-Function PCIe ACS override, binding the ethernet card to VFIO at bootup, and then assigning the VM the PCI devices directly in the VM settings resolved this.

Another note, after hours of work, I could NOT get a Realtek RTL8125 based ethernet card working. PCI passthrough would entirely fail, and using bridging with Unraid resulted in WAN working but the LAN port failing to operate at all. That ethernet card not working was a massive part in this taking me forever to troubleshoot. Everything is working great and with the preferred method of PCI passthrough with an Intel I225 based ethernet card. If I had started with the I225 card instead of trying to save some money with the RTL8125 I would have saved myself some serious effort. Lesson learnt.

https://redmine.pfsense.org/issues/14619

This helps explain it.

Screenshot 2023-12-15 at 10.53.07 PM.png

Separators cause issues if you’re using them.

@eeebbune not for the handshake.. Those are tiny syn and syn,ack

Where exactly is that sniff from, and I am not sure what you show blocked is actually the same traffic in your sniff.. Without timestamps to reference.. For all I know that is some other connection on same ports that were blocked..

Here is the thing - if what your talking to takes seconds to respond to a syn vs milliseconds - your going to have a bad day no matter how you look at it.

edit: here is an answer from a syn.. It is less than 1 ms.. Not 28 seconds.. If the device your sending a syn too doesn't answer in 20 some seconds you have something wrong with that box.. Or its just never seeing the syn at all.. Even if we take the time of the last retrans which it got??? It took 13 seconds to send a syn,ack?

here is normal sort of response time talking to something - here talking to my nas.. You can see the time sent the syn, and when got back the syn,ack

answer.jpg

Its less than 1 ms..

here is talking to something out on the internet.. 11ms not 27 seconds..

11.jpg

edit2: So if this is the same session.. The ports match up, once you sent syn,ack that .6 box answered with ack in like less than 1 ms.. So why is 18.88 taking 27 seconds to respond? Maybe the hamster is tired running around the wheel powering it?

ack.jpg

I found everything I needed to know and better here pfSense baseline guide with VPN, Guest and VLAN support.

@DGG
I found the solution.

I need to bound the firewall states to the interfaces.

This is the quote from the pf.conf manual page

set state-policy
The state-policy option sets the default behaviour for states:
_ if-bound States are bound to interface.
_ floating States can match packets on any interfaces (the default).

Now I have to figure out if it is possible do it from Web interface, in OPNsense it is. PfSense manual say nothing about it.