@Jarhead said in None of my firewall rules are working on VLANs: So the trunk connected to the router won't need vlan 1 untagged but the trunks to the AP's will. Exactly you can have more than 1 uplink from the switch that carry different networks/vlans - if you have free ports on your switch and router this actually good idea, now if you have intervlan traffic you don't have to worry about hairpin, as long as you don't put the uplink on the same physical. So for example. [image: 1715137698493-uplinks.jpg] So you can see vlans are on my igb2 interface, there is also an untagged vlan on this, this is vlan 2 on the switch. igb actually goes thru my switch as well, this is vlan 99 on the switch untagged and from another port on the switch untagged in vlan 99 goes to my modem. Lan is untagged goes to vlan 9 on my switch. All the vlans that are tagged on on the switch igb2 plugs into. These are all wireless networks, and there is no intervlan traffic between them if talk to them, its from say my lan network. Roku is also a wireless network but this is where all my media players are and no need to share bandwidth the other wireless networks and I had spare ports. Then dmz is another untagged network if you have the ports on your router and switch, nothing really needs to be tagged, they can all be untagged native networks on pfsense. And then untagged in whatever vlan those networks are on your switch. The only time you have to tag is when your going to carry more than one network/vlan over the same physical wire.

Yup if you don't need to filter between the bridge member segments that's what I would have done.

@johnpoz The last one was the one I applied. Thank you

@johnpoz Ok its working now. Just want to thank you and everyone else. It was the power cycling that was the problem. I had no idea you needed to do that. Yeah with the old one I never needed to take that step so I was totally in the dark. Thanks again ya'll.

@Antibiotic said in Confused about the document of creating a fq_codel limiter: @SteveITS If set to match , quick box ( Apply the action immediately on match) to leave on? If it is the last rule, it does not matter. Quick tells it not to check later rules.

@SteveITS Thanks! that seemed to have cleared it up.

@Antibiotic I have no knowledge about making themes, sorry.

@pastic yeah those should work.. Common practice has been to create an alias with all the rfc1918 space in it.. So if you don't wan a specific vlan to get to any of your other networks vs creating rules for each network you can just block them with 1 rule blocking access to rfc1918, this helps in blocking access to new networks you might add, etc. Also unless this a transit network, its also good practice to set the source to the network, ie if you making the rules on vlanX the source would be vlanX subnets, because there should never be any non vlanX source IPs hitting this interface.

@Antibiotic I use X-Forwarded Header Mode set to transparent as it was having issues with my IP looking like a private address with Netgate forums website. That fixed it I do not disable the VIA header so my requests follow RFC2616. I do suppress the version however. Hope that helps, The X-Forwarded Header Mode was causing issues with my system and setting it to transparent helped Netgate's staff helped me with that because I could not see that my IP was showing up incorrectly and causing issues, I am not behind a lot of equipment so I don't need it enabled.

@johnpoz said in Port restriction rule!: https://docs.netgate.com/pfsense/en/latest/multiwan/policy-route.html#bypassing-policy-routing [image: 1714525724767-d4cab2a0-036c-4732-b23b-033f2863ee09-image.png]

@Snailkhan said in Cannot access pfSense Webui from LAN: In firewall logs i see below I saw this : the green part : [image: 1714476013249-60bc99e9-cfd2-40ef-8b56-0aca73b4bf05-image.png] I don't know what 'snort' is, but sure enough : Disable it or if possible, edit the snort2c hosts alias and remove your IP, and redo the snort settings so it won't block legit local traffic anymore. Btw : the alias snort2c must be used somewhere. You've looked at the Floating firewall page ? ;) It's also blocking DNS traffic (to 4.2.2.2 port 53). @Snailkhan said in Cannot access pfSense Webui from LAN: table <fw_host_IP_Alias> { 192.168.56.10 } That's explains everything : you've managed to lock yourself out. Locate this "192.168.56.10" device, switch to a temporary static IP setup, like 192.168.56.11, and with some luck you can edit the snort settings faster as that snort will also lock the door on you again.

I would concur using it as explicit proxy where your devices actual gateway points to pfsense vs the proxy should remove such issues what what your seeing with that 22 traffic you listed. Other option with putting such devices that are really internal to your network on their own transit network can eliminate asymmetrical flow issues.

SOLVED After a rethink I discovered no auto created outbound NAT rule (set to manual) added that and now everythings works as expected.

@runevn said in Can't access VLAN20 from VLAN60 - Interface bound state help: You were right. This brought to mind a line from Grateful Dead song ;) "Well, I ain't always right, but I've never been wrong" You get a cookie if you know what song, without having to look it up ;) Dead on the Brain - My Dave's Pick 50 came in the mail today.. Always a good day when they come.. https://store.dead.net/en/grateful-dead/special-collections/daves-picks/daves-picks-vol.-50-palladium-new-york-city-ny-5377/081227817466.html I always have subscription, so 4 times a year is like xmas ;) Glad you got it sorted. edit: soon to be 52, as soon as get it ripped and on plex ;) [image: 1714253671610-soon.jpg] edit2: make that 53, this shipment had the bonus disc.. Sweet! And hint that above line is from a song on the bonus disc ;)

@johnpoz said in Windows OpenVPN Client Blocked By Firewall: @panzerscope looks like they are back up... Quick little look and seems like a client reinstall fixes it for most, or validate service is running. But yeah that error points to a client side problem. Thanks. I found that lesson out a little quicker, by chance I recall seeing there was a client update available, so I went ahead and installed the update and the issue went away. I have to remember that in future, if there is a rule to allow anything OUT on LAN that it is unlikely to be a firewall related issue an something local to the device/client!