@m0nKeY One thing to remember is traffic does not pass between different subnets, unless you specifically allow them. Here are the rules for my guest WiFi, which may be what you want: [image: 1709392129651-5ebfe259-0328-4def-9f4d-b61d7afcefc9-image.png]

Hmm Google Translate isn't really helping here! What exactly is failing here? Do you have Limiters set in the Captive Portal? It looks like you so since limiter info still shows them present.

We found a link aggregation that looped rather than aggregating in a switch as well as some ports that was untagged for multiple networks that are now disabled. This has lowered the load, but not fixed the problem. I saw this in the gateway log this morning: Feb 28 04:04:32 dpinger 81222 WANGWv6_GC a:b:c::1: sendto error: 55 Feb 27 21:06:24 dpinger 80779 WAN_GlobalConnectGW a.b.c.193: sendto error: 55 Feb 27 21:06:24 dpinger 81222 WANGWv6_GC a:b:c::1: sendto error: 55 Feb 27 21:06:15 dpinger 81222 send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 1 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr a:b:c::1 bind_addr a:b:c::3 identifier "WANGWv6_GC " Feb 27 21:06:15 dpinger 80779 send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 1 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr a.b.c.193 bind_addr a.b.c.195 identifier "WAN_GlobalConnectGW " Feb 27 21:02:37 dpinger 40064 send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 1 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr a:b:c::1 bind_addr a:b:c::3 identifier "WANGWv6_GC " Feb 27 21:02:37 dpinger 36210 send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 1 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr a.b.c.193 bind_addr a.b.c.195 identifier "WAN_GlobalConnectGW " Unlike before it seems to affect cpu and ram a lot too. around 8GB ram and a load average of 4.29, 5.47, 5.91. Swap is unused. specs are: Intel(R) Xeon(R) Silver 4110 CPU @ 2.10GHz 16 CPUs: 1 package(s) x 8 core(s) x 2 hardware threads I did a state reset to clean up, however no change to latency. I am starting to think this is merely traffic hitting a "threshold" that we haven't hit before, which is impacting the processing speed, yet we are not really processing any more data than we did previously, as far as I can see. I am unsure how to proceed, can anyone give any good ways I could troubleshoot and locate the source of the problems?

@kmp said in Default deny rule IPV4(1000000103): For LAN interfaces, as I understand it, there is no default drop rule, The default behavior of pf, the firewall used by pfSEnse, is drop. Try it out for yourself : remove all rules from LAN and see what happens. There is one exception : if you have the DHCP server activated on an interface, pfSense will ad pass rules for port 67(68) UDP on that interface. @kmp said in Default deny rule IPV4(1000000103): the default is pass as initially When installing pfSense, there will be a PASS ALL on the LAN, and only the LAN. If you assigned other (OPTx) interface during installation, all these interface will not allow incoming traffic. You have to add rules for all these interface yourself in the GUI. Btw : because the WAN doesn't have any rules listed in the beginning, the WAN doesn't let any traffic in. This is what most users want. @kmp said in Default deny rule IPV4(1000000103): I will say that I screwed things up by initially setting up an inbound NAT with "PASS"; When you add a NAT rule, to things happen : An address (and port) translation rule is inserted. This rule is listed under Firewall > NAT > Port Forward When done, have a look at your WAN firewall rule : there is also a new firewall rule now. This is, of course, a PASS rule. At the bottom, you'll see [image: 1709018592967-a2a63be9-1c3c-41a6-8f25-787f52ea61fb-image.png] I would be best not to edit this rule, as it is maintained by the NAT rue listed under Firewall > NAT > Port Forward @larryjb said in Default deny rule IPV4(1000000103): Suddenly I had to change it to 192.168.1.1 Ok, nice, but do you mind what the 'suddenly' is about , It was written on the wall and you followed the advise ? @larryjb said in Default deny rule IPV4(1000000103): and I cannot get an internet connection unless I have it set to .1. You can set any IP on your LAN as long as the LAN network is not the WAN network. Golden rule number one : just keep the default 192.168.1.1/24 on LAN, connect the WAN to your upstream device or cable, and you'll be fine. In the past, we all some modem type device, so the WAN interface obtained a 'real' Internet WAN IP (non RFC1918). This changed the last decade or so, most use now a (modem)+router (so it can integrate VOIP functionality, VOD, and an Wifi access point). These ISP devices 'boxes' have often a switch integrated, and offer an RFC1918 LAN network, and because these devices do "NAT", you get a free firewall. This LAN network can be used with all your home devices. really nice, as now grandma can now set up here own home network without knowing nothing. If this ISP device uses also 192.168.1.1/24, then you have a choice to make : change the ISP box default LAN network 192.168.1.1/24 to something else, like 192.168.2.1/24, or change the pfSense defayult LAN to something else, like, 192.168.10.1/24 (Ok to pick 192.168.10.15/24 but then I really have to ask you : why ????). Some like 192.68.10.254/24 My way of seeing things : because my ISP box is connected to nothing but pfSense, I change the ISP Box default network from 192.168.1.1/24 to 192.168.100.1/24 - the pfSense WAN IP becomes something like 192.168.100.x where x is something between 2 and 254, using the default DHCP client on it's WAN. I've shut down the crappy Wifi of the ISP box, as I've my own dedicated APs, all behind pfSense LANs. Btw : [image: 1709021003697-75d96281-63e3-4082-9d1d-f44d701457e6-image.png] you don't need these. Keep the KIS process up and running : enter less info, simplify maintenance and possible issues : [image: 1709021061496-5857ea7c-7a79-4233-bb2b-3c7c77fd512d-image.png] and now you can access "the world". I had zero DNS issues for the last 15 years of pfSense usage.

@johnpoz Looking at the Ip Scanner those MAC adresses are for HP printers tied to the network in other building. I believe there must be some security feature in the switches that is stopping access.

@Konstanti Здравствуйте! Это англоговорящая ветка , для сообщений на русском языке есть свой раздел Я так и стал подозревать, спасибо Напишу там

@johnpoz I think you hit it on the nail! “Skip rules when gateway is down” sounds exactly what I need. If I enable this, then it should go to my next rule which is to block the traffic altogether:) Thank you @johnpoz

@ErniePantuso its not dumb.. But if you have a wire between your router and your pc - how would any other devices even connect and use an IP? If it works - sure go for it.. Just not a normal setup is all.. But yeah it can work.

@elvisimprsntr said in Network Drops. There HAS TO be an easier way!: un a Shields Up! scan on all service ports to determine what ports might be open. Cool site - thanks! I passed (with no Common or Service Ports open), but will store this for future testing needs :)

@JeGr Thanks for your extensive replay !! I will give some reactions here and perhaps more in the future. Lots of things in your replay :) Your differentiation is only artificial. There is no difference - it's only wording. Yep I largely agree to that, however IMHO very important wording. It are rule groups, not interface groups! That's why not using "any" as source on OpenVPN rules is important Generally speaking, a vlan whatever type, should block sources not belonging to the vlan itself. So every interface should start with a yes or no hidden rule. Block if source not me! I did add a rules like that in the past "block if source not my subnet" (I hope that works also for IPV6). And I am not sure if that rule is there as hidden rule Manually crafted Interface groups work the same way. You create them and they are entered and used in the pf ruleset like another interface This feels like defining rules in aliases. I do not yet understand. Have to study this Floating I'd avoid entirely or only use in very specific special cases (e.g. outbound reject rule for RFC1918 traffic, it's the only way to create outbound rules). Let me start saying that the way firewalls work are more or less the opposite from what IMHO should be. Let met compare with a house. It is the house owner who decides who is allowed to enter the home. It is are not the neighbors who decide that they are allowed to enter my house (VLAN/INTERFACE). So from that perspective it is very strange that interface rules are defining who is allowed to leave the vlan and not who is allowed to enter the vlan !! To put it in other words, rules defining who is allowed to enter the interface, do IMHO belong with that interface and not belong to a special group like floating! Having said that, I am using float for multiple reasons: to block incoming traffic towards e.g. my green zone to make sure that certain blockings are there and are processed first (quick) for performance reasons, placing peformance critical rules, related to file transfers there. Since floating is processed first and the less rules to process is more performance. I tend to use floating more and more to accomplish this! much hassle in case of debugging as to where exactly a certain pass or block comes from Yep an no. off course, I enable logging where necessary. However, in general, my feeling is exactly opposite! In a lot of situations vlans need largely the same rule set. And if that is really one set of rules, that set of rules is much easier to maintain and to correct, than to maintain the equivalent of all those rules at the different vlan's!! If I make a change in the group, it is automatically there for all interfaces using the group. What should be nice / should help, is if rules could be defined using ^my-subnet^ and "my-address" in opposite of "vlan-x-subnet^ and ^vlan-x-address^ Also don't forget, that you will be severly limited in using REJECT or BLOCKs in those groups. As the ruleset is top-down-first-match (pf's quick keyword) if you block or reject something in Group 1, you don't get a second chance to allow it in Group 3 or 4 This is complex, perhaps I will come back on this one later on. But for now a short reaction. Up to now, I always assume that rules are processed in the same order as they are visible (apart from floating first etc). At this moment I do not yet policy based routing. Related to floating rules, I always use quick In general was surprised with my new finding. And I did some testing verifying that my suspect was correct. I did not yet do testing to verify the order in which rule-sets are processed, which is important. So at this moment, I do not yet use the rule-set options as I see them to there full extend. But I use them all ready. Examples: a vlan available on the 1G network and the 10G-network being there with the same reason the guest network and the private network having more ore less the same rule set websites each having there own vlan, but are further more or less the same As said still playing around with the ^new^ possibility

@Ristin the states are under diagnostic menu. Glad to hear its working, there is nothing really do to for such connections to work.

@dimsum said in opt cannot going to internet: when I ping 1.1.1.1 it does work No it doesn't - you are showing timeout - that is not working. These are working examples [image: 1708356468553-working.jpg] timeouts and ttl expired and nothing past hop 1 is not working anything.. So even your lan doesn't work?? Can pfsense itself even ping anything? [image: 1708356609489-pingpf.jpg]

Manual checklist: A list of criteria to manually review your firewall rules against. Automated tool: A software application that scans your firewall configuration and automatically identifies potential issues. Compliance with company security policies: Do your rules align with your organization's overall security strategy? Can you share your firewall configuration file or provide access to the firewall itself?

@michmoor Perfect. That is what I was looking for. Thx

@louis2 said in IOT-LAN; How to handle multicast !?: Other vlans I will probably pass it, with logging to get better understanding. Pass it to what?? Pfsense - what is pfsense going to do with it?? Nothing!! what you do on pfsense has nothing to do with other clients on that network seeing or not seeing the traffic.. Pfsense routes traffic off the network.. It is not involved with traffic be it unicast, multicast or broadcast traffic between devices on the same network.. What you do with it on pfsense is not going to have any effect on if some other device on that network.. But create any rules you want so its not logged, which was what you were asking about.. But pfsense is not going to actually do anything with traffic sent to a ff02:16 address, it sure isn't going to route it anywhere else.

@PnetG maybe you can create two Client Specific Overrides for these 2 devices. Reading man openpvn, --redirect-gateway is the option that is passed to all devices, to force internet access via vpn. For these 2 specific devices, you can pass: redirect-gateway !ipv4 (or !ipv6 too) to not redirect gateway (and then these 2 devices can access internet directly). Another option is using the "pull-filter ignore ...." on the .opvn|.conf files for these 2 devices, to make them ignore the redirect-gateway pushed by the openvpn server to them (see man openvpn).

@JKnott I said what I said, if I wanted a VPN I would have said VPN. I want to daisy chain 2 different firewall configurations by different builds together on the same LAN before it goes out to the modem's ISP. On top of the double firewall I will be having 2 or 3 VPNs "on" as well but I am not asking how to do the VPN, I am asking how to daisy chain 2 firewalls together as I never have used 2 firewalls at the same time before only 1 but now I want 2 on. Is this achieved easier through LAN-to-LAN, or a Double NAT, or the 2nd Layer router also has an option called "Site-to-Site"; the pfSense btw is what will be behind the modem while the other firewall will be within the inner part of the LAN

@viragomann great shout. Thanks for that. I had left an ip address entry on the layer 3 switch for the vlan. So would send the packets to the gateway. Many thanks Chris

@fero1233 said in Rule order bug?: So for future refrence: pfblocker is the problem, and the solution is to remove that specific interface from "outbound firewall rules" in pfblocker :) Or even better: Don't use automatic rules at all, as the options are quite limited with the moving around of rules. Just set the IP Lists to "Alias Deny" or "Permit" etc. instead of "Block Deny" and just create your own rules with the pfB_xy Aliases to reject or block or allow traffic as needed. Especially when having larger or more complex rulesets, that's definetly necessary. Cheers