It sounds like you're setting up a guest WiFi. Here are my rules for mine: [image: 1614951391361-c7d99d11-3069-4125-8415-402887aa90b0-image.png] Private and prefix are aliases.

@phil-davis Agreed. Yea, I'm resurrecting an old thread. But this is a detail that should be in the floating rule documentation. Truth be told that is where I went first for an answer and ended up here instead.

@mrfrenchfry said in pfB_PRI1_v4 - blocking common websites: I want to remove that IP from the table. Go here : [image: 1614885361491-5af41702-c0ba-4bc9-9979-a06ed6aceab3-image.png] Go downwards. You'll find : [image: 1614885391360-7de04c99-d3b5-4e54-afd1-52b2124b88bf-image.png] Click on the + sign on the right. [image: 1614885530188-b80b5db2-c2a0-47bd-941d-732cd1d14e1a-image.png] Add your IP and mask. Save with the blue button at the bottem of the page. Update > Reload > All. Done. The IP is removed from the Alias table. Btw : the IP is listed by some IP feeds that you included yourself.

@johnpoz Synopsis: Unclear as to why an IDS/IPS blocking (for reason 'X') an attempt to an unused proto/port combination is acceptable, but PF doing it for simply attempting would not be? They both arrive at the same destination, just very different in terms of resources to arrive at the same conclusion. You're likely already consuming an interesting measure of resources between pass/block lists, GeoIP blocks (limited value), IDS/IPS block injection and so on. How would that be any different whether its v4 or v6 - you're still going employ those equivalent protections, right? In one of those tracks you're paying a premium for processing by the IDS/IPS, then the proxy, then ... and finally the service/application to process vs. "source exhibited potentially problematic behavior, prescribe cooling off interval before allowing any more connection attempts" via the least expensive, lowest latency means possible. Like most things, careful consideration is necessary. It's simply another tool in the kit. Exposing the ability to use 'overload' and 'flush global' on rules for both TCP and UDP enables an administrator to address by crafting rule(s) accordingly. -- Outermost is a transparent bridge running Snort (blocking IP-based categories + categorical rules that pertain to scanning). There's also a laundry list of IPs and networks for pass/block. The outer takes care of 99% of useless/bad traffic. The next layer is a pfSense firewall (w/NAT) running Suricata + pfBlocker and various other packages. Suricata on the external interface blocks all IP-based categories + numerous additional categories (each interface has its own Suricata instance with rulesets applicable to each interface's purpose). Yes, such things as a haproxy are used to increase security posture and nothing is 'exposed' directly. Patching and updates are done daily to weekly. (followed by successive internal layers) The aspect of the attempts didn't look like anything interesting until looking back and seeing that they originated across different netblocks/SPs and different locations (appear to be cellular/consumer residential). It wasn't a singular source. Given a small number of packets, some spread out, some in succession and non-repeating IP Addresses made it far less visible. The common aspect was target proto/port (proto in this case was UDP). This could have been easily overlooked as just noise and possibly could be just that - noise. Having Suricata bark the same message when it occurs - isn't stating anything new (but does validate that its doing its job). If something changes about the packet construct (same targeting, different payload), is it a gamble as to whether Suricata would catch it? Sure, it would still be blocked by the firewall (unused proto/port), but in essence something is still 'attempting'. This is where an alternative means (as was described) has merit. The primary difference in the suggestion is that an IDS/IPS (in its most valuable context) is inspecting payload to determine if something should be blocked - potentially even for an unused proto/port. Arguably, a finely tuned IDS/IPS won't consider those packets but its those packets that also signal to the IDS/IPS that this source should be blocked if its behavior(s) aren't those that conform to expectation. We're just short-circuiting the overhead by using the lowest resource/latency means to address (PF). Proactively blocking based on blacklist only addresses already known bad actors - it doesn't address sources that aren't on the blacklist or are too spurious/minimal to qualify for blacklisting. Yes, relying on the eventual destination service (and the steps to go there) and associated strengths (or weaknesses) is certainly viable and part-and-parcel. Preventing the ability to reach the service (in the first place) by sources that exhibit less than desirable behavior when the service must be 'otherwise publicly accessible' (non-veiled, eg: not behind a VPN) - is pragmatic. You are in essence doing same with an IDS/IPS... As far as v4 vs. v6 - you're likely already utilizing means that pass/block addresses (ad nauseum) as a result of external traffic being rife with scanning, probing and a litany of qualifiers for 'drop/block/discard'. There's substantial overhead to have an IDS/IPS or to have the service, address this (even if to reject) than for PF to prescribe blocking based on recently behavioral pattern of attempt(s) to ports that should never be attempted (externally). Given your 1K+ example, if there was an attempt to a [trigger] port it would have resulted in the source being blocked with comparatively no processing overhead and a lot less logging to traverse (if one is logging, as only the initial catch needs to be logged and not the successive denials). Obviously, if the source never attempted an unused [trigger] proto/port - then it won't help. But what did that cost in terms of resources to have a set of unused [trigger] proto/port combinations defined? If compute resources are a consideration, then this could certainly up the ante. For busier firewalls, this provides an opportunity to potentially log even more strategically. If nothing else, the block interval for the IDS/IPS could be reduced due to the fact that attempts to an unused [trigger] proto/port could have a much longer block interval. From a service delivery perspective, the potential for "lockout" can [conceivably] be shortened when the block is prescribed via the IDS/IPS while using these two methods in tandem (as one would be able to prescribe a longer blocking interval for those connections captured via PF). As a random example, if one only uses OpenVPN for all VPNs and uses an unusual port (hopefully) - why would UDP/500 ever be targeted for connection by an "expected" consumer? It shouldn't. Block all connection attempts to/from address for <interval> and move on. Don't waste resources to even consider what was in the payload, nor allow it to attempt connection to anything else. Much like the incessant connection attempts to TCP/1433, if it attempts (its not something that you want connecting to anything), just block the source for interval from being able to connect to anything and move on. Why even waste the IDS/IPS's time on traffic that originates from sources that have exhibited such behavior? Seems unclear as to why there's acceptance to an IDS/IPS blocking a source attempting connection to an unused proto/port combination for 'payload matching on X' and resistance to being able to craft a rule where PF simply blocks that same source for attempting connection to that same unused proto/port combination. Both result in the same logical overhead - one of those just requires far more resources and adds latency to get there.

A vpn client on a machine sends all traffic down the tunnel.. Unless you can setup split tunnel, it won't send any traffic even to your own local network, let alone a vlan on your network. I have the same issue with my work machine to be honest - it forces login to work vpn. So have no access to even my local printer or nas.. And its pretty much impossible to not get it to log into the vpn ;)

@robatwork So pfSense should response. The gateway doesn't matter.

@viragomann Alright, that did it. I'll have to read up on that because i never heard of it before. Thanks for your help, i really appreciate it

@xterro2021 ???? What does that have to do with rules? Also, these days, most things are encrypted, so what info can be found out?

@jegr Hey JeGr, it seems to be a p2p-filesharing-application and or dns. I use 8.8.8.8 as the default dns for several interfaces. Because I couldn't stop it happening, I enables "Do not create rules when gateway is down" in the advanced settings and created reject rules as necessary. Now I have a clean log at least...

But now you have me curious why the firewal log say for OPT was triggered on the LAN interface? That makes no sense at all..

@bhagya_jani2277 said in Having issues in accessing Pfsense using SSH: is in the series of Dynamic ip’s by default it will block all the incoming ports at isp’s router/firewall. So like I said - something upstream blocking ;)

Definitely something not right.. I have pfSense as a virtual machine running on an ESXi hypervisor. With the LAN interface re-enabled, as mentioned earlier I no longer get the strange behavior. But now I cannot access the management IP of my hypervisor, which is on the same subnet as my PC. Can't ping it from pfSense either. It's supposed to be a getting a static DHCP lease. On my switch/wireless AP, all ethernet ports are on a single VLAN with the exception of the trunk port, going into the hypervisor. Pretty straightforward interface assignment: [image: 1614412869804-capture.png] Physically, vmx1 is the port going to the switch, and vmx0 is going to the modem out to WAN. In ESXi I have one virtual switch for LAN and one for WAN. The WAN side is pretty straightforward, one port group and no VLAN tagging, assigned to the vmx0 interface. On the LAN vSwitch I have 3 port groups; one trunk (tagged 4095 as this is a special number to ESXi), one for VLAN 24 and the Management port group tagged VLAN 103. The port group tagged 4095 is assigned to the pfSense VM's LAN interface. Any thoughts on my mistake here would be appreciated. I supposed this thread would be better placed in L2/Switching/VLANs.. EDIT: Well, fixed my issue with accessing the ESXi management interface. Looked at the local console and it was complaining about not getting a DHCP lease. This is probably due to me accidentally disabling the DHCP client... In any case, I just gave it a static IP.

^ as stated.. Unless you can disable nat - there is really no way to determine what is traffic is natting to its own traffic. Now one trick you could try.. Is since traffic through the router should have its TTL reduced by 1, you "could" filter on the TTL, common ttls are 64, 128, etc. as it passes through a router its ttl should be lowered by 1 so 63 and 127.. So you would allow that traffic - but not allow full ttl traffic 64,128, 254, etc. That is if the router is actually doing that.. And if there was someway to filter that in pfsense - have never looked to see if could be done.. This is actually a common way to detect for NAT.. But different OSes might use different TTL values.. Its a bit dated but here is a listing https://subinsb.com/default-device-ttl-values/ Notice here on a linux box PING localhost (127.0.0.1) 56(84) bytes of data. 64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.086 ms 64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.090 ms Using 64 as its ttl.. While windows $ ping localhost Pinging I5-Win.local.lan [127.0.0.1] with 32 bytes of data: Reply from 127.0.0.1: bytes=32 time<1ms TTL=128 Reply from 127.0.0.1: bytes=32 time<1ms TTL=128 See here - this is pfsense monitoring its gateway with ping 20:46:50.003218 00:08:a2:0c:e6:25 > 00:01:5c:b9:06:46, ethertype IPv4 (0x0800), length 43: (tos 0x0, ttl 64, id 21174, offset 0, flags [none], proto ICMP (1), length 29) 64.53.x.x > 64.53.x.x: ICMP echo request, id 15585, seq 24375, length 9 Notice the ttl of 64.. But if I ping say 8.8.8.8 from behind pfsense.. From my linux box 20:48:35.288767 00:08:a2:0c:e6:25 > 00:01:5c:b9:06:46, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 41878, offset 0, flags [DF], proto ICMP (1), length 84) 64.53.x.x > 8.8.8.8: ICMP echo request, id 1500, seq 1, length 64 Notice how the ttl is now 63 Same thing from my windows machine 20:50:06.740581 00:08:a2:0c:e6:25 > 00:01:5c:b9:06:46, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 127, id 35663, offset 0, flags [none], proto ICMP (1), length 60) 64.53.x.x > 8.8.8.8: ICMP echo request, id 9961, seq 36, length 40 Notice the 128 ttl got reduced to 127.. Off the top though - I do not know if pfsense has anyway to look for specific TTL, and then either allow or block.. edit: I looked at the advanced firewall options - don't see anyway to look for TTL.. Its possible the source OS type might be helpful.. But not exactly sure what its looking at to determine OS, and since your clients are behind the router.. That might not work at all.. Best idea might be to not have any clients behind it, and monitor it - does it create any traffic that you do not like? If so you could block that traffic. Based on destination, port, etc..

@lucas-0 Yep. That is how I have my rules ordered. The x3 block rules for "HiddenWasp Linux Malware" will never be reached because they are below the two allow all rules (Default allow LAN to any rules) for IPv4 and IPv6. Same for the NORDVPN_VPNV4 rule. It will never be reached because LAN traffic will take the "Default allow LAN to any rules). Rules are processed in a top to bottom order (with an exception of floating rules). I will not get into detail. But this is a good read to explain how to order rules. If the pfsense box has at least x3 ports it could be set up as follows: port1: WAN port2: LAN --> Switch1 port3: LAN_IOT --> Switch2 This would give the same result as using VLANs to separate LAN from LAN_IOT. If LAN devices need to access LAN_IOT devices then a firewall rule will need to be put into place. Depending on how the IOT device is configured a NAT Outbound rule may also need to be put into place if the IOT device does not respond to IPs out of its IP address range. For me, I just set up a generic NAT Outbound rule (allow LAN to LAN_IOT). The NAT rule does not do anything until there is a firewall rule setup which also allows (LAN.deviceX to LAN_IOT.deviceY). Don't be afraid to put pfsense into hybrid outbound NAT mode. It just moves the auto-generated rules to the bottom and allows the creation of custom rules. But as always; before any changes are made to the pfsense box make sure there is recent backup configuration easily available for restoring in the event a mistake is made during the learning process. Good luck and have fun!

@hieroglyph Thank you very much for that detailed response. This helps greatly. For the most part, our pfsense box is in a allow all mode but we restrict access by IP address at the OS level. Obviously, this is an issue for users that do not have static IP addresses but we want to restrict access at the pfsense level. So our thought is to create aliases and with monitoring and scripting, add block rules dynamically for IP addresses that are from specific countries as well as brute force attempts. I am sure pfblocker is probably a better route but I am just not familiar enough with it to know if it is working or not. Plus I had an issue where all traffic was blocked after a reboot and had to disable it. Anyway, thanks again for taking the time to answer my question. Our hardware is an old dell R710 dual cpu server with I think 128gb of ram. Take care! Kud

@wc2l said in SG3100 Single WAN NAT Issues.: @mcury flushdns did the trick!! I can now telnet, browse and have to check out some of the services.. Looks like were successful! Now I can do some of the other things on my list!! Good new, the office is quiet and I'm working from home today. I may be able to make myself useful Nice, enjoy :)