Thanks, I guess because I am new to IP6 I just want to double check and not do something silly. In this case, I have created a number of rules for my guest network (below), would it be a safe thing to do to have an alias for the local subnets (e.g. IP6 & 4) and then just create an inverse rule below, so if the traffic from the Guest network is not to local subnets, then let it out or is there a better / more efficient way to achieve this? [image: 1578961261244-ip6_fw.jpg] Many thanks!

The source OS isn't recorded in the logs as far as I'm aware. You could set a specific rule to match a specific source OS and then maybe go by whatever that rule's tracking ID is, but the actual OS info won't be in the log data. https://docs.netgate.com/pfsense/en/latest/monitoring/filter-log-format-for-pfsense-2-2.html

One idea I had was to set the reverse proxy to also be a remote syslog server. Then on the VMs that are running services that get routed through the reverse proxy, have them send their logs to the reverse proxys log server, then the reverse proxy can perform the fail2bans instead of the individual VMs. This would allow the outside users IP to match what fail2ban is trying to block.

@johnpoz Sorry again...I need to mess with firewall inbound/outbound rules again? WTH?! What am I freaking missing here and why is it so different than your screenshot? Is your screenshot from a different version of Windows? [image: 1578934211654-image.png]

Looks like the solution I need, thanks

One thing in addition: I've defined an alias including all RFC1918 subnets and use that alias in the rule instead of LAN net or whatever to allow access to anywhere but my internal network. So that rule is safe even when I change a network or add one. However, this permits access to the pfSense interface address as well. So if you want your OPT device to use pfSense for DNS resolution you have to add an additional rule to allow that. I do this by one floating rule with Quick option checked for all my internal interfaces together.

I have another separate bridge setup, and I hadn't really paid much attention to it before; but I noticed that packets show up as being default denied on both the member interface and the bridge interface. It looks like the packets that would be bridged show up on the member interface, and packets that are destined the firewall itself show up on the bridge interface. I think that packets that are destined to be routed (as opposed to switched on layer 2) also show up against the bridge interface, which is what's happening in my original post. So I really have no idea what net.link.bridge.pfil_bridge is meant to do. It appears that rules apply to the bridge interface even with this disabled. Maybe it's broken? Maybe it has some more nuanced meaning? I see all sorts of people on the internet messing with these settings, but nothing really clearly explaining why they're doing it.

@JeGr said in Routing between interfaces/VLANs: Or the VLAN isolation isn't throrough and leaking through. I thought to remember sth like that from the smallest TP-Link Switches a few years ago... And also TP-Link access points. I have one here and can't configure a 2nd SSID because of leaks between VLAN and native.

That was the original observation, but in practice, several other scenarios were also impacted by that bug, so it's most likely fixed no matter what was being observed.

Hi, I appreciate this is an old thread but I have the same setup (pfsense, HP microserver with ESXI, BT IPTV). I have the following config: Openreach modem connected to dedicated WAN port of pfsense BT TV Youview box connected to dedicated IPTV port of pfsense Rest of house connected to LAN port of pfsense I have IGMP Proxy running on pfsense 2.4.4 (had to find an older version from 2.4.3). IPTV downstream 10.10.10.1/24 WAN upstream 224.0.0.0/24, 109.159.247.0/24 So far no luck with streaming TV. Can you share your settings? Thanks

HA Proxy?? Why would you think you should proxy this?? Your not going to proxy UDP..

I am very frustrated to report that the PulseSecure client has been fooling me! It appears PulseSecure connects even with the pfSense firewall scrub option enabled. After I successfully connected to my company VPN, I noted: I still got an error box popping up, after every login attempt. [image: 1578347814653-pulse-secure-failed.jpg] The Pulse Secure window continues to say Securing Connection, even after a successful connection! It never changes from Securing Connection, to Connected! [image: 1578347822165-puse-secure-connection-window-redacted.jpg] It appears my trust in the feedback messages from Pulse Secure was misplaced. PulseSecure appears to be a buggy, piece of crap, that has been misleading me!! I'm sorry for wasting your time with this!

Post a screenshot of your rules, you can drag the screen shots into the message window. Also it's worth killing the firewall states after changing firewall rules.

Check https://docs.netgate.com/pfsense/en/latest/book/config/troubleshooting.html#dns-resolution-issues -Rico

You should realy check if resolver is actually able to resolve :) There are two ways for a resolver to work One is by quering the dns system root servers, and following the tree with recursion and the second would be to use forwarding, meaning all requests go to a designated dns which handles everything In a highly managed scenario such as sat access, the latter should be the only option Please check DNS Query Forwarding Enable Forwarding Mode If this option is set, DNS queries will be forwarded to the upstream DNS servers defined under System > General Setup or those obtained via DHCP/PPP on WAN (if DNS Server Override is enabled there). in dns resolver settings And you really need a test environment for this. Its very easy to lock yourself out while "optimising" things. And in the middle of the ocean there aren't many alternatives too.

@johnpoz Why would you think you need to put wan net as destination? Is there something in the wan network you need to talk to from lan? because I don't want it to be able to talk to stuff in the lan but if I say any wouldn't allow it to talk to lan if it's https 443? It's for Seafile Server which is going to be in the DMZ and the client on the phone or pc connects over https. And I don't want it to access the lan If you don't want say lan to talk to dmz netnwork, then you would put a block rules above the any rule in lan. Ahh makes sense. You do not need return traffic rules, those are handled by state that is created. Ahh right how can I forget.

Update on this for anyone having similar issues. I ran a tcpdump on the FreePBX server and and realized the phone was trying to contact it. The firewall wasn't blocking it, but the TFTP Server wasn't responding due to an improperly configured option in the setup file. Although I could connect locally in my testing, I didn't try to download a file. Once I realized I couldn't download a known file, I was able to go into the configuration and fix the error. The phone is correctly connecting to the server and I have a new set of issues to deal with, but unrelated to network on the local network. Takeaway -- utilize tcpdump (if available) to diagnose the local interface traffic. You can then take that pcap file and analyze it in Wireshark to quickly identify issues. Happy New Year!