Resolved this by disabling inbound port forwarding for port 5060 and it works fine now

Without the Allow all communication on the LAN/VLAN subnet/address rule for that network I wasnt able to get it to work properly with internal addressing, as I had 1 Alias rule that could be updated for each of the LAN interfaces, and this one was being used to block communication on its own subnet as well as all the others….. e.g. (not my own I may add) Firewall: Aliases  Name    Values                        Description LANS    192.168.1.0/24,(LAN1)    Not Internal Networks              192.168.2.0/24,(LAN2)             192.168.3.0/24,(LAN3)             192.168.4.0/24 etc.... Firewall: Rules (for LAN1) ID    Proto    Source      Port    Destination        Port    Gateway    Queue    Schedule    Description       *          LAN1 net  *      ! LANS              *      *              none                      Allow LAN1 to Internet *          LAN1 net  *      LAN1 address      *      *              none                      Default allow SUBNET to LAN any Rule *          LAN1 net  *      192.168.100.0/24 *      *              none                    Default VPN allow 192.168.100.0 to 192.168.1.0

@Javik: In general on pfsense 2.0.1, if you remove the default rule of allow all on the LAN side, does the pfsense firewall also restrict web access for squid itself, running on the pfsense firewall? Or does squid on pfsense always have full access to WAN ports regardless of pfsense's firewall config? If you are using squid in transparent mode it will bypass interface rules.

10.71.9.251 isn't the default gateway on the lan, it doesn't need to. partially solved. Added a static route from servers to the opt1 net and now a can ping/trace from servers to client and viceversa. Now let me see if i can connect. Edit: SOLVED!

You have to enable the DHCP server on that interface for it to assign IPs.

WAN rules require reply-to in many circumstances for correct return routing, and that cannot be done on interface groups, it's only done on rules assigned to that particular WAN.

OK, the risk should be negligible then.  The wifi is only used by a couple of visitors a month during meetings.  Even if someone poked through, all file shares require user authentication and the server itself is only accessible through SSH with key-based authentication.  In fact, I may just eliminate all risk and disable the rule that lets me through and only re-enable it when absolutely needed.  Thanks for all the input.

@Nachtfalke: The other possibility could be squid + squidguard and block verizon.com That would only be for egress traffic, and only for *.verizon.com sites. Sounds like he's referring to every host on Verizon's network, and ingress rather than egress traffic. You'll have to create an alias with their CIDR IP blocks to accomplish that. Though I doubt that's actually going to accomplish much if anything for you, there are countless far more malicious networks. US ISPs in general will quickly shut down abuse when it's reported, but God help you with Eastern Europe, China, and many other regions. I report a lot of abuse against our networks, US and western Europe get the best response. Eastern Europe and much of Asia, as much as half the time the abuse emails bounce, and for the remainder you almost never hear back and commonly see abuse continuing. You should also determine whether it's really a port scan (blocking of TCP:S), or if it's backscatter noise from things like spoofed source TCP SYN floods (where you're blocking TCP:SA). The former is something to report to their abuse, the latter is just an unfortunate fact of life on the Internet when a host on their network is being attacked. And it's frequently misinterpreted as something on their network "scanning" you, SYN ACKs are not that.

@johnpoz: What pfblocker can do is prevent access from those bad ips to your services that are open.  But it can not "stop" port scanning. Now that's something I never considered before.  Thank you for that insight.

@cmb: @TechnoBob: The problem I've noticed is that pfSense is routing traffic from GUESTNET to LAN - which I don't want.  I've tried putting in rules to reject all traffic from GUESTNET to LAN - but it still did it. Putting them in where? You need that rule to be the first on GUESTNET. Yep - That's where I put them. @TechnoBob: I should mention that I originally defined the LAN as a gateway - with the thought the I might need to route traffic to the other pfSense box (which also has an interface on vlan2)… but decided to isolate this problem so I removed that gateway. No, don't do that, that's strictly for multi-WAN. You shouldn't even have a gateway on LAN in most cases. Thanks - good advice. The way I managed to get this working right is to eliminate the Trunk port and lagg0 and use physical interfaces for each VLAN (and on the switch changed them from Trunk to Access ports). Not sure why this was happening… but I was up against a deadline and needed to make it work without losing any more sleep.  :P

Forgot to mention protocol is IGMP.

Can you try to add a connection limit to your denied rules. Probably it will block 'offenders/portscanners' for about 2 hours.

it negates policy routing, you just have to add your own rules if you remove it to not force traffic out to a wrong gateway.

It used to be much worse, requiring a reboot or taking a few minutes to apply. A few seconds is nothing. Also adding/removing VLANs isn't something that happens very frequently in most networks.

you running open-vm-tools? I've seen that with it on amd64. You can increase vm.pmap.shpgperproc as it suggests to silence the log, 2048 is a good value. Add this to /boot/loader.conf.local vm.pmap.shpgperproc=2048 and reboot.

thank you.  I have 2 more perplexing questions, but I think I might have to start a new topic for that.

Having any kind of automation or shortcuts is never going to satisfy everyone. The scenarios for this kind of setup vary quite a bit. The best thing to do is to have explicit rules stating what you want them to be able to do and not do. This can be made easier if you make an rfc1918 alias containing (192.168.0.0/16, 172.16.0.0/12, and 10.0.0.0/8), then: pass from (this network) to (this network) block from (this network) to rfc1918 pass from (this network) to any Only downside of that is they can reach anything on the firewall on that segment, but you can toss a couple rules at the top of that to narrow it down: pass from (this network) to (firewall's ip on that network) on whatever ports you want, probably at least tcp/udp 53. block from (this network) to (firewall's ip) Alternately, toss all that, and use floating rules to block "out" quick on the other interfaces from the networks you don't want to get there.

Somehow you have an alias named WAN. I thought we prevented that from being allowed, as it will cause exactly this kind of problem. fix your alias name to something else, like WANIP or similar, and it should work.