@stephenw10 Thank you I will have a look at it

@jonathanlee
Thank you. I did not know that Suricata can be configured to block Nmap attacks. The image you provided is very helpful. Crackers are said to "taste" the target router,

and when they attack the same target again (the victim notices an anomaly and resets the entire network), they use Nmap to investigate the manufacturer and model of the router. If such a thing happens, knowing whether the attacker came to "taste" with Nmap could be a clue to record the attacker's footsteps.

If you're able to I would check the packet counters on each tunnel. That does mean other traffic not using it which may not be possible.

I would bet this is a missing P2 though. Can we see what you have configured?

The local private subnet is usually just to access the modem for diagnostics and it's usually only available when the upstream cable connection has lost sync. I wouldn't expect it to appear on a normal connection.
However you can stop pfSense pulling a lease from the local server by adding it's IP to the Reject leases from field in the DHCP client config on WAN. So it's probably 192.168.100.1 or 192.168.100.254.

Steve

@stephenw10 I re-followed provided wiki and got it working. One thing I had trouble with, all of the sudden was my Wiregard road warrior user setup stopped providing route. Fixed it by pfsense reboot.

Thank you for your help!!!

@stephenw10 Thanks for the hint, I've installed the package, applied the recommended patches and rebooted. I'll watch ;-)

@jbob said in Random Website Outages?:

@stephenw10
OH FOUND IT. Snort had picked up the IP as suspicious and blocked it. Now just need to figure out how to add an FQDN to the snort pass list

Create a FQDN alias under FIREWALL > ALIASES in the pfSense menu. Then either create a new Pass List (or edit any existing one already assigned to the interface) and add the FQDN alias to the Pass List. When editing a Pass List, there are controls at the bottom of the page for adding, editing, or deleting IP addresses, networks, and host or network aliases.

Once the Pass List has been edited to include the FQDN alias, go edit the Snort interface and assign the Pass List using the drop-down selector for Pass List. Save the change and then restart Snort on the interface so that the binary daemon will see the change.

Note that FQDN aliases are resolved only once every 5 minutes. A host or domain that changes addresses more frequently than that may not be reliably resolved. Also, if the host or domain in question is part of a CDN (content delivery network), then the IP address will likely change too often to be effectively resolved for use in the Pass List.

Here is a post I created back a couple of years ago when the FQDN feature was added. There are some screenshots in the post of the feature in action, and from those you can also see how to configure them in a Pass List.

https://forum.netgate.com/topic/160771/new-often-requested-snort-feature-coming-soon

@hoandco

Final SLD with all devices connected
93fcb284-0676-4063-a735-e2d7c4a1585c-image.png

Hmm, but OPT1 always does?

In 2.6?

It's a miracle! 😁

Yeah, if you've removed the IPv6 traffic that was triggering it you should be fine. 23.05 is not far off now anyway.

This has been moved to a new Redmine issue.

@maverickws Well, note that BSDCan is the thing that is later this month... not specifically a release but the CTO made the above comment on Reddit recently and he's someone that would know, I suspect. 😁

It's this: https://redmine.pfsense.org/issues/13984

Resave the reverse proxy page as shown there.

Steve

@gertjan yeah because it doesn't come from some ipv6 link-local address ;)

@stephenw10

I don't have email notification enabled. I turn it on and check right now.

Setting that only does so for connections from the firewall itself. It doesn't affect connections form clients behind it.

@atafm2 yes on both counts. The pid is normally only there if it’s running so it must have crashed once. IIRC the stream memory is related to CPU cores/threads not RAM but we usually don’t need to adjust it.

In that situation it's likely Linode controls the actual VLAN config and the hosts within each VLAN do not see the VLAN tags etc. So I would not expect to need to use any VLAN config in pfSense directly.
However I've not used Linode in that way so I'm not sure exactly what they expose to the user.

Indeed the console does not require a login by default there. In general if you can access the local console on a machine you can bypass a login there anyway so that becomes a physical security issue.

Steve