Hello. I found this thread through search. I am experiencing exactly the same issue. I ha e multiple Google Home devices. After changing to a pfsense router they mostly do not work. Sometimes if I keep requesting thee will work again. Otherwise the same error mentioned here. I cannot figure out why. Some specific request being blocked. Just not sure.

@ducati57 ?

@Gertjan said in UDP packages dropped: When you install pfSense, any (like close to "all") traffic from LAN to WAN passes. UDP will work for sure. You've found initially one firewall rule on LAN - it worked. Exactly that's my problem. The direction LAN => WAN is the problem. Btw : Traffic from WAN to LAN needs more then a firewall rule. It's called a NAT rule, which included a firewall rule. With only a firewall rule, you can't use LAN resources from 'WAN'. Sorry for my short details. NAT is clear. I've built a static port outbound rule for UDP traffic. @hs_pfsenseuser said in UDP packages dropped: What rules ? What interface ? Can you detail ? ISV == Fritzbox == WAN Private Class C == PFSense == LAN also Private Class C and others Testing setup uses only private network: Local DECT phone on Fritzbox connected to WAN interface Local SIP phone connected to LAN interface and registered in Fritzbox Firewall testing rule WAN: Fritzbox as source and SIP phone as target, allow all UDP traffic on all ports Firewall testing rule LAN: SIP phone as source and Fritzbox phone as target, allow all UDP traffic on all ports Hybrid Outbound NAT: Fritzbox as source, udp/*, Destination *, WAN Address as NAT address, static port Testing with several keep alive times for UDP on PFSense side and port activity time on FB side Test 1: Initiate Call by Local SIP phone for DECT phone Incoming Call on DECT side, pickup OK and bidi audio on dynamic UDP ports also OK. Packet capture shows packages on both interfaces for both IPs (SIP and FB) Test 2: Initiate Call by DECT phone for SIP phone Incoming Call on SIP side, pickup OK and audio on dynamic UDP ports mostly only from DECT to SIP (uni directional). Packet capture shows Fritzbox packages on both interfaces and SIP packages only on LAN side. Logging of the firewall rule shows the match for the UDP rules (WAN and LAN), but no traffic is routed from LAN to WAN. Captured SIP packages show the right source IP (SIP) and IP endpoint (Fritzbox) Sometimes bidi audio works without any changes in PFSense My problem is, that the same setup worked for years with PFSense 2.5.2. With release 2.6 the problems with UDP started. So I skipped 2.6. towards 2.7.0. Maybe the big changes under the hood are the reason for this and I have to adjust my settings. But I have no idea, what the problem is.

@y2raza gateway monitor ip is coming from the isp I am not using icmp.

@johnpoz Sirs, thank you for your recommendations and all. we are running this updated 2.4.5 . I know it is still old and we are going to take your recommendations and start pushing forward to newer versions and systems. Thank you thank you for injecting more sanity into my world. There's never enough good ideas. I appreciate you. 2.4.5-RELEASE-p1 (amd64) built on Tue Jun 02 17:51:17 EDT 2020 FreeBSD 11.3-STABLE

@HLPPC I've also found that it helps to disable all ifconfig options on the MODEM interface and to audit the L2 firewall rules: ifconfig igbx -txcsum -rxcsum -txcsum6 -rxcsum6 -lro -tso4 -tso6 -vlanhwcsum -vlanhwtag -vlanmtu -vlanhwfilter -vlanhwtso [image: 1697056627023-l2.png] Thanks in the dc for mentioning this vulnerability to me. https://derekabdine.com/blog/2022-arris-advisory.html

@viragomann I think that does the trick! Thank you for your input! And if somebody else reads this - I think it's still a bug though that the "Skip rule when gateway is down" option doesn't work as expected..., Maybe somebody can reproduce this?

Because I'm going off topic here, I'm resuming what is still the problem at a new Topic and it solved there.

Glad you figured it out, personally I would still use a VPN for access instead of doing it over WAN but if you're filtering for specific IPs then should be fine.

@JonathanLee Yeah for sure, but I'm not running anything like that lol. I'd still consider 10s of TB a day quite a bit of volume compared to most places though.

@Stefaan-0 said in windows firewall: Maybe this is a stupid question Can't argue with that.

@Gertjan is correct! I totally forgot about probably the most important reason you would not typically want to block HTTP at the firewall -- devices testing for a captive portal and verifying basic Internet connectivity.

Thank you for the correction. The issue with using a public dns server is that DNS blocklist lookups can get blocked leading to mail acceptance issues. When I used Cloudflare DNS we had a few emails that were not accepted. I tried to edit my post above to remove the internal setting of Comcast DBS [ our ISP provider ] . I suppose running bind on our mail server is the best way to go

@ZipleR said in Allow outbound rule for all public addresses: I put the rule at the top of the list so it would be the first rule that applies... which would then block access to dns and then my scenario would be possible to why you don't have "internet" Is there maybe something wrong with the way I think "Invert match" works? No you have the concept down,. but have no idea what other rules you have in place. Do you have any rules in floating? We don't even know if you put that rule on the correct interface. We don't know that the device even has that IP, or is using pfsense as its gateway.. Also inverted rules can run into issues if your using vips, using an alias could be causing it issues? Here would be a much better way to lock down.. This 1 specific IP from talking to the rest of your network, while allowing others on the network to talk to other things.. It is better to be very explicit in your rules.. Lets see the full rule set.. Setup your rules to specific block to what you don't want it to go to, vs trying a bang rule. Here is a set of rules that would prevent this network from talking to anything else on any other vlans, but allow internet.. Could be easy adjusted to allow other things on that network, but block this 1 IP. [image: 1695987840171-test.jpg]

@Gertjan maybe Suricata in IDS mode can help depending on what rules are triggered

@kevdog I see. I got, you didn't have problems on the client accessing the server. Asymmetric routing could happen due to multi-homed machines in your case. But the log doesn't look like that. You would rather see response packets from the server being blocked.

@viragomann I have discovered that as soon as I remove the 1:1 NAT mapping, it all works. So the specific public ip address is probably being blocked for some reason by the upstream router.