Problem partially solved. Determined it is not related to pfSense. Thread can be dismissed.

Tried killing the firewall states ?

Hummm. This was a puzzle in a puzzle. Didn't understand the answer of@Konstanti . Then I focused on "120000", a rule number that exist for all of us, under 'special' conditions'. @schalex said in Firewall blocks RDP connection: When i go on the Red X i get the message "block/12000". @Schalex : asking the WAN to block local IP addresses (192.168.1.x and family) if you have a router (the ISP router) in front a a router (pfSense) that will kill (99.9999999 %) of all incoming NAT connections (because they will be 'local'). @Konstanti

I found this thread today while I also try to get my fw rules right for allowing traffic between VLANs. What puzzles me is that I don't see any blocked packages in the system logs, so the theory that they are routed somewhere else sounds valid ;-) Could someone pls be more specific? Do I need a PASS-rule on every VLAN-interface tab for bypassing?

You are correct though there are cases were the source IP would be different than the net the interface is connected to.. If this was the case any could be used as source, or restrictive cidr containing all your possible downstream... But there would never be a case where lan 2 was seen on lan 1 as source... Unless you had a LOOP and crossover between your L2 networks.. Which would be BAD! ;) He was putting in his other networks as source.. Which would never be the case.

Nevermind, the issue was my own stupidity. I enabled some random unrelated rule that had port 80 listed in the port column in Windows Firewall. All I had to do was add a custom rule on port 80 and allow traffic. Everything works. This can be closed.

@helgew said in [Solved] Unable to access one of two VLANs from outside: @brians I didn't post those because they are a bit more complex. I was doing all the trouble shooting from a WLAN client. That said, I nuked the IPCAMS VLAN and interface, re-added both as well as the DHCP server and now everything works. Good that you got it working.

@jenningsb said in Java downloads not getting through despite Allow All rule: We have some software that tries to download a Java package every time it is opened. If I disable the firewall completely, the download works fine. If the firewall is enabled, the download fails. I've tested by creating an Allow All rule on the Lan interface and disabling all other outbound rules with no success. I've disabled all add-on packages (squid, snort, etc) with no success. The only thing that works is to disable the firewall in System\Advanced\Firewall. This is a very simple setup. Single LAN interface and single WAN interface. When you disabled Snort, did you go in to the BLOCKED tab and flush all the blocked IP addresses? Simply turning off Snort will not remove any previously Snort blocked IP addresses.

@jknott said in Wifi router behind pfsense appliance - bypass risk?: @akuma1x said in Wifi router behind pfsense appliance - bypass risk?: Give it NO access to your network(s), and only let it talk out to the internet. That would be appropriate if he wants a guess WiFi, but I didn't see that mentioned. If he wants to access his network via WiFi, as is often done in homes and businesses, then that's not a such a good idea. True, he didn't say one way or the other how he wanted to do it. Here's one: guest network with a good WPA2 passcode, like above. Limit, or give it no access, to your main LAN network. Here's the other: on and part of your main LAN network. Use a good WPA2 passcode, maybe make the SSID hidden (but it can be found by anybody with basic wifi tools), make sure it's firmware stays up-to-date to plug up any security holes. Remember, you're dealing with consumer gear, the manufacturer tends to not update firmware for too long, they want to sell more, newer, better wifi gear. It's just going to be a simple access point, so you won't get much, if any, in the way of firewalling or routing. Is getting newer wifi gear out of the question? I ask, because most, if not all, of the newer access point things offer VLAN capabilities. That means, with 1 wifi box, you can offer up multiple wifi networks, guest and main LAN, as an example. Add a simple 5-8 port managed switch to the mix to move this traffic in the right directions, and you can be done. This gives you 2 wifi signals, 1 that can be isolated to just the internet, the other that sits on your main LAN. Jeff

@lpacor IGMP:- https://en.wikipedia.org/wiki/Internet_Group_Management_Protocol NetBIOS:- https://en.wikipedia.org/wiki/NetBIOS

Thanks for the clarification jknott, I was trying to keep it simple in terms of multicast should normally not be routed out the wan, etc. And it shouldn't be since it wouldn't actually be sent to the gateway. Router doesn't just take a multicast packet and say, hey I should send this out my wan to help get where its going.. If so then all the nonsense multicast SSDP traffic windows clients send would get sent out the wan, etc.

@KOM No, but, after comparing it to similar configs, I tracked it down to a floating firewall rule (used for traffic shaping) that had a Pass action instead of a Match action.

You are a genius :) Thanks very much, tried it and viola, first time :)

The alias should be applied to each included IP in the same way. However, consider that already existing connections (existing states) are not closed when the scheduled block rule gets active. You can set up a scheduled pass rule (you will have to adjust the schedule time) followed by a static block rule to achieve this.

I checked the tables and there were some (empty) old entries, I took the opportunity to update and reboot. The ip addresses on mixed fqdn/ip aliases look fine and the empty tables are gone. Perhaps I typed something wrong. Anyhow, I forgot about the tables tool, thanks johnpoz

If you don't trust your own LAN, what do you trust? If you want to block everything on your LAN from Internet access then do that via firewall rules or web proxy. Besides, you will find that malicious traffic will happily use tcp80,443 to talk because: The bad traffic will get mixed into all the other http/s traffic and be harder to detect. Standard ports are likely to be blocked off while tcp80,443 are almost always available.

Ok, Thankyou - I'll try.