@gertjan Thanks for the link, I'll watch the video and hope to understand how I need to set it all up. If not I might come back with few question ;)

@gregeeh Aliases are pretty much all or nothing. Think of them as a preprocessor macro in C. One thing I like to do is go to diagnostics, command prompt, then enter the command pfctl -s rules. That shows you the rules as they are loaded and optimized in pf. If you do this, you see individual rules for each item in the alias. So if there is overlap on the TCP and UDP ports you could do a single rule and enable it for both TCP/UDP. If there is no overlap, create 2 aliases and 2 rules. It looks like you have distinct ranges: TCP ports 100, 200, 300 and UDP ports 1000, 2000, 3000, so 2 aliases, 2 rules, one for TCP one for UDP.

@soulvoid86 Presumably your devices are not able to access the DNS server anymore, cause you did not what I suggested. I advised to add a rule to the top of the LAN rule set for allowing access to internal services like DNS. This rule must have set the gateway option to "any". Since I don't know, which services you need, I cannot be more accurate. Supposed you're using the DNS resolve on pfSense, you need to pass TCP/UDP to the destination "This firewall", port 53. The next rule has the WAN gateway set, so it directs any passed traffic to that gateway. Hence it cannot be used for access to internal destinations.

@frosch1482 said in Firewall rules / problem with blocked traffic / no clue what goes wrong: Isn´t all that multicast traffic on 224 or 225 networks? in this case it shouldn´t be in conflict with the block RFC1918 rule Yeah while the discovery would be multicast.. Which you seem to be passing with avahi? But if it finds something on 192.168.1.100 for example via that multicast discovery.. And then wanted to connect to 192.168.1.100 - that would be blocked. So what is the point of the discovery in the first place?

Can't seem to get it going. In Firewall-Rules-wiregaurd I have a the rule that allows Devices (currently only my phone) to connect to my network. Interface = Wireguard Source = Network 10.1.15.0/24 that i change to Single host or alias 10.1.15.2 (Phone ip). then in advanced, I change gateway from Default to NordVPN at this point the phone looses connection ???

@uglybrian I like this solution better. I will try this and see if it works.

@steveits said in Strange behavior with ATT gateway in IP Passthrough: Your router is on the AT&T router's LAN. So is this why it was appearing on the WAN interface logs? & Thanks for the suggestion, my firewall logs sure looks so much cleaner, and its mind blowing to see how many IPs are getting blocked by pfBlocker

I'm cleaning up the rules now. I thought I would mention that I found this bug too: https://redmine.pfsense.org/issues/11572 Basically, my IPv6 block lists we not working because the rule was set for IPv4 with IPv6 lists. :( Easy fix, but a sneaky bug for sure.

We now went live with the setup and I observed another detail. Until now, I had only seen the weird behavior when connecting to external websites. As these were mostly hosted by Google, I suspected it might have been related to Google using particularly modern protocols or implementations of their own server software. When trying to access the web interface of an old VoIP phone we have at one of the sites, I however experienced the same issue. The device definitely uses the opposite of modern protocols/software, it even only supports TLS1.0/1.1. I managed to take some screenshots depicting the problem: Log output in pfSense saying that the connection is blocked. It looks as if the connection would originate from the phone (10.16.103.56) when in fact, it was initiated by my client (10.25.102.100) to the HTTPS port of the device. [image: 1629367015673-2021-08-19-114942.png] I also managed to grab a wireshark dump of the connection attempt. Please ignore the differing IP address "10.137.0.37". This is due to me using Qubes OS, an operating system which heavily makes use of virtual machines which automatically receive internal IP addresses. For this issue, you can read 10.137.0.37 == 10.25.102.100. [image: 1629367026245-2021-08-18-201055.png] The output shows that a TCP handshake is established correctly and the TLS handshake starts as well, but is interrupted immediately. I think that this does not always happen at the same time. When accessing the Google domains I remember seeing a "Server Hello" message. If I start a dummy webserver (Linux laptop running Apache) with the same IP address as the VoIP phone I can access the Apache default webpage without any issues, both over plaintext and HTTPS connections. This leads me to the conclusion that this is indeed a bug in pfSense which occurs only together with some particular servers. I don't know how else this could be explained. I will file a bug report for this issue.

@stephenw10 Thank you very much Steve for the info, I will take it in account.

My point was more to that dhcp would not be needed to be listed in that rule description, and if its on another vlan - that rule wouldn't even work for dhcp. Client isn't going to ask some dhcpd on another vlan for an address.

ICMPv6 to a multicast address.. Say # IPv6 ICMP is not auxiliary, it is required for operation # See man icmp6(4) # 1 unreach Destination unreachable # 2 toobig Packet too big # 128 echoreq Echo service request # 129 echorep Echo service reply # 133 routersol Router solicitation # 134 routeradv Router advertisement # 135 neighbrsol Neighbor solicitation # 136 neighbradv Neighbor advertisement pass quick inet6 proto ipv6-icmp from any to any icmp6-type {1,2,135,136} tracker 1000000107 keep state # Allow only bare essential icmpv6 packets (NS, NA, and RA, echoreq, echorep) pass out quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type {129,133,134,135,136} tracker 1000000108 keep state pass out quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type {129,133,134,135,136} tracker 1000000109 keep state pass in quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type {128,133,134,135,136} tracker 1000000110 keep state pass in quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type {128,133,134,135,136} tracker 1000000111 keep state pass in quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type {128,133,134,135,136} tracker 1000000112 keep state pass in quick inet6 proto ipv6-icmp from :: to ff02::/16 icmp6-type {128,133,134,135,136} tracker 1000000113 keep state Is not all Multicast - and sure isn't to 224.0.0.1 As I stated if it was required for IPv6 to work, the rules would already be there - hidden. His blocking of IPv4 multicast noise is not going to break anything..

@johnpoz thanks a lot for the detailed answer. i will talk to isp about allocating a static address for me.

Interesting, no advice? no suggestions? :)