@johnpoz I'm at a lose what to check, I took out all the DNS settings [image: 1770421201230-6ef7f08d-edff-42f2-b846-a474fd0b6410-image.png] Would the DNS being set wrong cause the forwarding problems, I can reach the site internally via IP what would be your best call to do Keith

@tinfoilmatt said in Rule with UDP and port 514 not matched: Mess not clear. Do you nedd some specific logs. Rule i not matched if UDP prottocol is used.

@johnpoz Cool!

@Uglybrian Thank you for your response. I didn't see anything in those links to help me create a rule to block these log entries. I've tried but no success. There must be something about the source "[::]" that causes it not to match "any".

@SteveITS Thanks for your response pal, this input has helped me resolve the issue. Sounds obvious now but this was resolved by disabling the outbound NAT policy for web host subnet behind the firewall. Now the source IP remains the same so on the ping reply it reachs the web host as final destination, not the NAT IP on the pfsense.

@patient0 Thank you for that information.

@luckman212 The 20.1.0.x network is coming from my pfSense OpenVPN server tunnel network. I initially had it configured as 20.1.0.0/24, but I have since changed it to 10.4.1.0/24 and the behavior is still the same. There is also an explicit outbound firewall rule on pfSense that prevents the VPN tunnel network from egressing to WAN, so 20.1.0.x is not leaking to the public internet even when it was in use. This address space only existed internally on the VPN tunnel. -- Current topology: pfSense OpenVPN tunnel network is 10.4.1.0/24, pfSense side is 10.4.1.1 and EdgeRouter is 10.4.1.2. From the pfSense LAN I can ping 10.4.1.2 successfully, and from the EdgeRouter firewall I can ping the pfSense LAN network 192.168.0.0/24 without issues. Firewall to firewall connectivity works, but end hosts cannot reach each other. For example, host 192.168.255.2 cannot ping 192.168.0.14, and hosts in 192.168.0.0/24 also cannot reach 192.168.255.2. However, both firewalls themselves can ping devices across the tunnel. Hosts in the pfSense network cannot reach 192.168.255.0/24 behind the EdgeRouter. The only variable that changed is a pfSense upgrade, this setup worked correctly on an earlier version but stopped working after upgrading to 25.x. pfSense LAN 192.168.0.0/24 | | [ pfSense ] LAN 192.168.0.1 VPN 10.4.1.1 | | OpenVPN tunnel 10.4.1.0/24 | VPN 10.4.1.2 [ EdgeRouter ] | | EdgeRouter LAN 192.168.255.0/24 | Host 192.168.255.2

@Spider_VL This is a really helpful resource! Thank you for sharing it. I think I’ll refer to this diagram whenever I get confused while working in the lab. Understanding how direction works in floating has been really challenging for me, so I’ll study it more using this figure. Thanks again.

@CatSpecial202 Have you seen the release notes for 25.11.1 that just arrived? This section sounds VERY MUCH like a fix for the issue we are seeing. I hope I will find time to test this pretty soon: “ Netgate 2100 The LAN port link parameters on the Netgate 2100 have been updated to address a potential signal transmission issue. This issue prevented packets containing a specific byte pattern from being transmitted through the LAN port on the Netgate 2100. No other models are affected. “

@KOM Thanks for the speedy reply mate. Yeah, ive had a brief look through the xml and it looks pretty good to edit. Im thinking ill be able to just replace the quad port rj45 with the quad port sfp, adjust the interface names and up and running.

@MP83 FWIW Netgate doesn't date stamp releases but the order can be seen in the left navigation pane of https://docs.netgate.com/pfsense/en/latest/releases/. 25.11 changed FreeBSD versions (to 16), presumably why the fix was included in this case. Edit: dates are on https://docs.netgate.com/pfsense/en/latest/releases/versions.html, d'oh, I knew that.

@johnpoz I set those in the past (long time ago) from the firewall logs because of the same behavior when they were getting blocked. I'll disable for now and see what happens.

@Uglybrian ff02::16 is multicast. FWIW we always disable logging for the default block rules, unless diagnosing something. There's a lot less noise, and disk writes.

Huawei. I‘m with Netgate and Huawei-Support in contact.

@FrankZappa glad you finally got it sorted.. packet capture can be your best tool.. So you can for sure see what is happening, or not happening.

Forgot to add one more possibly useful data point. The problem user "rba" can successfully execute a command like: easyrule showblock lan There are no errors with this or with a command like easyrule unblock lan 192.168.1.72 ...as long as there are no entries. Once there is an easyrule entry, say for example a block placed by the root user, then I can only show the block, and running unblock as rba produces the same Fatal Error.

@johnpoz the only common package in use is System Patches, and there aren't any non-package-provided patches installed. I'll keep digging.

pfsense blocks 169.254.. every 1-5 seconds what is this ??? Your LAN firewall(s) rule : [image: 1766751831585-e03e851c-e449-4b30-89c3-567b387f8df0-image.png] Disregard the first two rules. The third rule is most probably the same as what you have : You inform with this rule pfSense, the firewall, that it should allow incoming traffic that has source IP that falls in the scope of "LAN Subnets". In your case, that everything from 192.168.100.2 to 192.168.100.254, or 192.168.100.0/255 As per your command, traffic that has a source like "169.254.1.1.1" isn't part of the 192.168.100.0/255, so ... the firewall will block this traffic. And lists it the the firewall log as blocked. The one and only question is, as said above : why does this LAN device use an AIPA or 169.254.x.x IP ? Most probably because the DHCP negotiation failed. In that case, most devices assign themselves a pretty useless 169.254.x.x IP - with one advantage : you know now that that device needs your assistance.