@steveits Thanks, that is good info. I may just do LAN entirely.

@lightingman117 same here.. default deny logging disabled on mine. I have no desire to see out of state blocks. Or any sort of nonsense noise on my wan either. I log blocks that might interest me, on the wan this is only SYN traffic, and some common and interesting UDP ports. And some other things that interest me that might be trying to talk to my IP. But if some random packet hits my IP that is not a syn, and would never be allowed anyway - I don't really have a desire to see it in my logs, it just fills them up making it harder to see the interesting stuff. On my lan side interfaces I have blocks that log for stuff that would be of interest to me if devices on those networks tried to go there or on specific ports, that sort of thing. And as mentioned by @SteveITS you can always trigger the default log back on if your actually trying to troubleshoot something that is not working, or whenever else you might want to take a peek.

@4rr3n said in VLAN Broadcasts Testing: I need to listen for a broadcast from a different VLAN on the VLAN that I'm connected on. Broadcasts don't pass through a router. You'll have to do the packet capture on the VLAN with the broadcasts you want. As johnpoz mentioned, you can just start capturing in Wireshark, but it's far more useful with filters. Wireshark has both capture and display filters, but you still have to decide what you're looking for, in terms of protocol, address, etc..

@hovnetworks happy to help.. Yeah you would think for example that plex and uptime and statuscake IPs would all be in the us so wouldn't need those - but some of the IPs are outside the US when checking.. So its best to be specific. Generally speaking port forwards are less secure for sure than say a vpn. But if you can lock down who can access it, it can be very secure.. In a scenario where you know the IP or even a small netblock of where the remotes are going to be coming from.. Limiting your port forward to that IP or IPs is pretty secure.. When I first started sharing plex, I was going to limit it to my specific users IP.. But you ask a user for their IP and most of the time its a deer in headlight look you get back. And then their IP changes, or they are trying to watch via their phone while they are out and about.. So did the next best thing and just locked it down to country where they would be coming from, etc. I had a buddy travel to Ireland a few weeks back - so I opened up for him, and he did watch some stuff while he was there ;) And then when he got back I removed those IPs from the alias.

25565 is Minecraft Java ports. Bedrock is 19132 and 19133

@the-other, @pwood999 I agree with you that preparing your kids with the ethical and moral understanding is key. That said, there is such a thing as temptation, which can at time overpower the best ethical and moral comprehension. Unfortunately, pornography can be highly addictive. Therefore, the technological block can help against temptation. I think, at home I have all that covered pretty well. However, it was a client who had indicated that he wanted administrative access control. Knowing his level of expertise, going about it the way I would is not an option. I had hoped that the incredible extensibility of the pfSense platform might offer a viable solution.

That subnet looks like an Amazon Web Services range, so there could be all sorts of websites in there !!

... I've had a closer look at this to see how the filter.inc file actually works. There's a function filter_expand_alias that will build out the alias for you. But it's necessary to layer up the rule as a series of string concatenations rather than trying to use EOD. So you end up with: $ipfrules .= "pass out log on { em0 } dup-to ( em1 192.168.1.3 ) inet proto tcp from any to {"; $ipfrules .= filter_expand_alias("My_Alias"); $ipfrules .= "} port 80 ridentifier {$increment_tracker()} flags S/SA keep state label \"USER_RULE: Outbound Custom Rule\"\n"; $ipfrules .= "pass in log on { em0 } dup-to ( em1 192.168.1.3 ) inet proto tcp from {"; $ipfrules .= filter_expand_alias("My_Alias"); $ipfrules .= "} to 192.168.1.87 port 80 ridentifier {$increment_tracker()} flags S/SA keep state label \"USER_RULE: Inbound Custom Rule\"\n"; I can't see a way to create this sort of rule in the UI though, because there's no free-form text field where you can specify your own options (in my case the "dup-to".

@phatsta it’s coming from all the devices running IPv6. Create a block rule and set it not to log is the easiest thing to do.

@scottlindner: We might be sort of talking past each other. My reply was simply meant to say that in a home network, many times security might take a bit of a back seat to ease of use for other family members. Yes, a DMZ does a really good job of isolating things, and that unfortunately means many popular home automation widgets get isolated from the devices on the more secure LAN that want to talk with them. And while there are some utilities that purport to help certain traffic types cross that LAN/DMZ boundary, not all are 100% successful with all IoT devices. So, that puts you back to balancing ease of use and security. But each network admin can make their own choices in this area. Some will go for security and isolation and use the DMZ route. Others may decide making "casting" work seamlessly and having music streamers and other devices "just work" on the LAN without requiring configuration and network gymnastics is worth the risk of just putting those IoT devices directly on the LAN with everything else.

@yea Rules are processed in order, top down.

@johnpoz That did the trick. I found a few things to investigate. Here are the rules: [image: 1682270905122-screenshot-2023-04-23-094829.png] Thanks for the help. It is greatly appreciated.

@johnpoz said in WAN rule for my ipv6 webserver is not working as expected.: @bob-dig you beat me too it ;) good catch.. DNS was your guess first. Can't have it. @johnpoz said in WAN rule for my ipv6 webserver is not working as expected.: how exactly are you testing, are you using a fqdn that points to the IPv6 of the server? This would mean that the rule you had placed to allow the traffic never triggered.. Wrong destination IP

@mrpete I would think alias is better, since it should fill a table with all of those IPs. I do same sort of thing for like uptime robot and status cake, and the IPs that plex uses to check services. But I just load all of those lists via pfblocker into an alias. And I have it only set to update ever like 12 hours.. And never ran into any issues..

@rennit I guess? With VLANs AFAIK there are two ways to get the VLAN assigned. Either something assigns it (AP, switch) or the device's network config has a VLAN. With the latter, someone with knowledge can change, add, or remove the VLAN tag. If the switch allows the new-VLAN packet on that port then it gets passed on. Normally that's blocked by a managed switch, but generally unmanaged gigabit switches will pass packets without regard for VLAN. Otherwise something would need to be removing the tag from the packets, in order to cross over to another VLAN.

@imv8n hey there, Seems you can reach vlan1 from vlan 50 (reaching pfsense)... So, what switch are you using? Do you need to configure that switch? Here I use cisco soho switches. You nned to configure those so that other devices (IPs) are allowed to get to the gui of the switch. This has to be configure on the switch itself...

@pfsenselearner-0 Looks like they’re just using double NAT. Not real sure what that gets, maybe a DMZ? But that can be done with one pfSense and three interfaces. Unless one blocks it by firewall rule the inner LAN would by default have access to the “middle” LAN. Re: change WAN to LAN, not sure I follow but WAN is generally “towards the Internet.” One can name interfaces however one wants.

IMO you're generally better off letting the default deny do this rather than having the HomeNet be able to connect to any destination outgoing wise. So IMO a better rule layout would look something like: Source: HomeNet Destination: HomeNet Allow Source HomeNet Destination: RFC1918 inverse match alias (so all public IP space) Allow I simplified things but I think you'll get the idea. The way I personally do it is just like above except that I also have a deny all rule to "This Firewall" with acceptions above for management traffic and DNS.

@kamal8641 Yeah as @viragomann said you really should not expose the web GUI of anything to the public web if you can help it, while some things are built well for it, it's still best to avoid it unless absolutely necessary. The better route to do this would be setting up a VPN server on pfSense, like WireGuard, and then using that to connect to the XO GUI from remote places, is there some reason that's not doable?