@hillisdr said in Rule not matching: After removing the server interfaces in vlan 8 You had multihomed devices... Oh well yeah, that is always and forever problematic.. Almost never a good idea ever.. Unless the other networks are just SANs or something and are not routeable

http://bradhedlund.com/notes/multicast/ IGMP general group query messages (sent by the router to hosts) contains 0.0.0.0 and is sent by default every 125 seconds. IGMP queries are sent to 224.0.0.1 (the all multicast hosts address) IGMP Membership Reports are sent by the hosts on a LAN segment, reporting to the router which multicast groups they are listening for. Your firewall shouldn't log that for starters ;) Yes its igmp snooping - you prob have it turned on via your switch or something. I turn it off - because I am not using any multicast on my network. Since I'm not using it - its noise that can be removed from the network.

Ok great info. Let me take a look at that more. If I can't figure it out i'll post up some rules. This is likely the cause though. I now its first triggered rule wins, but i couldn't immediately see how any rule would allow traffic to a GW that isn't specified... what you're saying makes perfect sense. Thanks, I'll investigate.

Well I ran a search for pfsense pppoe and found a screen shot showing the same icon for two pppoe DSL connections. [image: 1605291249356-7ea1a2d7-3c0a-42ad-b047-86fd253b73c9-image.png] Case closed.

Hello, I do a little up because the problem is reproduced again today. This is really problematic. PfSense to run for almost a month, and for no apparent reason it no longer works. Only a restart make it work. The problem necessarily comes from PfSense. All my other VMs are working, and I can access them in SSH (I go through another firewall dedicated to the administration). On the other hand, I cannot connect to Pfsense, neither through the web interface, nor in SSH. I'm starting to wonder if I should replace Pfsense with something else. If someone can give me answers? Thank you.

maybe you need to reset states after changing rules for ipv6 diagnostic / states / reset states This may be necessary after making substantial changes to the firewall and/or NAT rules, especially if there are IP protocol mappings (e.g. for PPTP or IPv6) with open connections.

The weird thing is, just one room id doesn't work. But basically if I deactivate all blocks it should work, right? I should try that just to see if it works.

Well if your outside the home and your not connected to the vpn wouldn't work now would it ;) If your in the home and the vpn can not connect.. But you would be able to connect because your local wifi.. What does it matter.. Seems like only issue would be your remote, and you forget to click the vpn.. So your home connection thing doesn't work - so you click the vpn connect button ;) Not seeing the need.. But its your money..

@JeGr said in Block rule from Alias A to Alias B, to save copying rules: You can also use an interface group for that without having to use Floating rules - which can be a bit tricky. Thanks! It'll be either floating rules or an interface group - I'll try both and learn new things. @viragomann said @Cabledude You can set the destination to "This firewall". This is an implicit alias for all IPs assigned to pfSnese. Okay I will try that and see how it goes, thanks a lot you guys, this is a great place! Now all I need to figure out is how to use my pfSense box to replace my ISP's fiber 200/200 / ipTV box and route VLANs 4 and 6 through the pfSense box using IGMP. Exciting stuff :-)

Thank you to everyone who has helped me with this today. Much appreciated :) Have to say Im enjoying this setup already. The speed of repply in this forum is outstanding as well. Thanks again and have a great evening :) Thanks Andy

if anyone runs into the same problem- using fully virtualized network cards helps (e1000, rtl8139) but has am major performance impact, really high cpu utilization in comparison to my esxi setup I had before, although this kvm box has a better cpu. i would strongly advise against it, unless you have so much horsepower, it does not matter. but I came across this: https://docs.netgate.com/pfsense/en/latest/recipes/virtualize-proxmox.html in the last paragraph it states: "Because the hardware checksum offload is not yet disabled, accessing pfSense webGUI might be sluggish. This is NORMAL and is fixed in the following step." well, setting this option seems to help for me for any traffic passing the pfSense VM. I can now run virtio paravirtualized network interfaces and have a good performance over all, at relatively low cpu consumption.

My best advice : If you need a switch , buy a switch. With reference to the above, i have no experience with pfSense and bridging. But i see a lot of experienced members giving the same advice. /Bingo

Follow the instructions outlined in the offical documentation here: https://pfsense-docs.readthedocs.io/en/latest/dns/redirecting-all-dns-requests-to-pfsense.html. Put only the IP address of the pfSense firewall in the DNS Server IP box on the client. Do NOT put any other IP addresses in there. This works for any client that uses conventional DNS lookup requests via port 53 using either UDP (the norm) or TCP (rare). However, some applications these days have built-in DNS lookup routines that use DoH (DNS over HTTP); and these requests will typically go out over port 443 (same as all HTTPS web traffic), so interception and redirection is not really possible. Some firewall admins address the DoH problem using pfBlockerNG-devel and list of known DoH DNS server IP addresses.

In my opinion, this is done so that you can block only part of the networks or all networks together. I usually block private networks that I do not need.

It is odd for sure ;) thanks for bringing it up - always fun to look at odd shit ;)

Got it resolved. You were right, fudged a firewall rule!

@bmeeks said in WAN Rules - Firewall log - vlan security - be invisible: What you are seeing in your firewall logs is the normal result of Internet noise. Various folks for varying reasons (some for research and some for malicious reasons) continually scan large segments of the IPv4 address space. Your firewall will see that traffic and drop it and and log it. If you don't want to see that noise in your logs (and few of us really do), then you create a block all rule with logging turned off. If I recall correctly, the default for new rules is for logging to be "off". Thus the rule will catch the traffic and prevent it from being logged. It was, and is still being blocked, though. It's just your new rule is preventing the logging of the dropped traffic, so now your log is cleaner. Good to know, I want to make sure that all incoming connections are droped and that only imporant things are logged. I probably need to review the documentation a bit better.

@bmeeks said in iOS 14 and blocking those pesky "private addresses": How are you going to filter by MAC address? pfSense (and most firewalls) do not support that kind of filtering Linux based firewalls running IPTables do.