Help with Blocking DoS and Managing Rule Priority in OPNsense

[solaris]

Hi,

I'm facing issues with outgoing traffic and possible DoS attacks. Here are my questions and observations:

A. How can I block outgoing traffic related to DoS attacks?
B. How do I change the priority of manually added firewall rules or lower the priority of automatically generated rules?

Background Details:
I've noticed repeated DoS alerts (RST Scan) in my Netgear router logs:
[DoS Attack: RST Scan] from source: 185.59.223.192, port 443, Sunday, December 29, 2024 20:23:56

My OPNsense logs show outgoing traffic to the same IP (185.59.223.192:443) despite having a rule to block it. The outgoing traffic seems to bypass my rule due to an automatically generated floating rule: "let out anything from firewall host itself (force gw)"

Firewall (opnsense) Configuration:

I created an alias with a list of IPs (including 185.59.223.192) and added a rule to block outgoing traffic to those IPs.
Despite this, outgoing traffic is being allowed, as seen in the OPNsense logs:
2024-12-30T01:23:36   filterlog[10352]   75,,,ff761fc54aa881cf05997aa13783aa54,ue0,match,pass,out,4,0x0,,126,14261,0,DF,6,tcp,52,6x.8x.8x.x,185.59.223.192,6660,443,0,S,283913834,,64240,,mss;nop;wscale;nop;nop;sackOK   
2024-12-30T01:23:36   filterlog[10352]   75,,,ff761fc54aa881cf05997aa13783aa54,ue0,match,pass,out,4,0x0,,126,14260,0,DF,6,tcp,52,6x.8x.8x.x,185.59.223.192,45650,443,0,S,730767861,,64240,,mss;nop;wscale;nop;nop;sackOK


1. What steps should I take to effectively block this outgoing traffic and stop the DoS?
2. How can I adjust the priority of manually added rules or lower the priority of the automatically generated "let out anything from firewall host itself (force gw)" rule?
3. What exactly is this RST Scan, and how do I mitigate it?
Any guidance would be appreciated!


Network Setup:
Netgear Wi-Fi Router: 2x.2xx.2xx.2/24 (Wi-Fi network: 1x.1xx.1xx.1/4)
OPNsense LAN: 2x.2xx.2xx.1/24
WAN IP: 6x.8x.8x.x 

[cookiemonster]

The  "let out anything from firewall host itself (force gw)" rule is not the one giving you trouble. This is the leg of traffic from the firewall, _after_ it was received from your network (LAN presumably). This is the first part where your own rules must be made to work.
So client sends traffic, arrives at the firewall, firewall sends it out.
As you can see, your rule needs to be applied immediately upon arriving.
That out of the way, we need to find why your rule to block it has not worked. Did you reset the state table after applying the new rule? If not, then connections established would continue.
Can you show your rules with a screenshot here (not linked)?

p.s. you probably also want to stop the traffic at the source.

[solaris]

Here are the screenshts:

WAN: https://drive.google.com/file/d/1jLqhJHoBM8xOdl1rla05EGOBgvfMtxXV/view?usp=sharing
LAN: https://drive.google.com/file/d/1B0z-7ZrU1hdcW9onYnY3OWXk0WfSMeJD/view?usp=sharing
Floating: https://drive.google.com/file/d/1TFLTbfDhM9ATCrspj2g81_EnQQs8huOx/view?usp=sharing
Loopback: https://drive.google.com/file/d/1a4ttoO65K_7QMLtAaWByabUMOS8QbPKf/view?usp=sharing

[cookiemonster]

sorry, no links for me. You can attach the screenshots to the post

[solaris]

wan and lan

[solaris]

loopback and floating

[EricPerl]

If the connection is already established, I don't believe a new rule will affect it.

Your logs seem to indicate which client on your network is initiating traffic.
Why don't you look there for the process owning the source port?

BTW, are you not using RFC 1918 ranges on your LAN?
Edit: I'm actually not getting a clear picture of your topology. Internet and your 2 routers (OPN & Netgear).

[EricPerl]

Internet <-> OPN <-> Netgear (not in AP mode?)
Is that it?

It's out to 185.59.223.192:443 on OPN WAN. You should be able to locate the in on your LAN in the same log.
The connection might still exist. You can check in Firewall > Diagnostics > Sessions or States.
Again, if it's established, all traffic on that connection will continue to flow while the state exists.

The client is likely your Wi-Fi router (since it's reporting an alert).
If it's not in AP mode (so doing NAT), you'll have to get in there to find the source (if that's even possible).
My guess is that you're seeing a false alarm from your router (per quick search on Netgear forums, not unusual).

FWIW: My old Tp-link router was happily reporting it blocked plenty of attacks but provided no source or destination in most of the logs, making such reports completely unactionable. The only recurrent report featuring a source pointed to a device on my LAN as the source (a Ring camera sending little bursts of ICMP traffic)... Useless.

[solaris]

I initially thought I could ignore the Netgear router log, but when I saw corroborating messages and connections in OPNsense, I realized I needed to investigate further.

From the Netgear router, I can't identify the source because the router's UI is very limited. However, on OPNsense, I can see that the traffic originates from the Netgear router and is going out to 185.59.223.192:443. I tried to block this traffic, but an automatically generated rule is allowing it to pass.

Regarding RFC 1918 compliance, there's one segment of my network that doesn't use an RFC 1918 range—the connection between the Netgear router and OPNsense.

Network Topology:

• LAN (Netgear router): Multiple RJ45 and Wi-Fi connections using 1x.1xx.1xx.0/24.
• Netgear <-> OPNsense: Single RJ45 connection using 2x.2xx.2xx.0/24 (non-RFC 1918 range).
• OPNsense <-> Cable Modem: Single RJ45 connection using a public DHCP address assigned by the ISP (6x.8x.8x.x).

[EricPerl]

If you still have the connection, there's a state for it in Firewall > Diagnostics > States.
You can delete the state from there. If you now have a rule blocking that traffic, it should fail to reestablish...
Maybe you'll notice something stuck on a client.

In one of the Netgear forums posts I found with a quick search, the author had figured out it happened while streaming from reputable sources.
The fact that it's reported by your inner router on outgoing connections makes it fairly likely it's a false alarm IMO.

Putting the Netgear in AP mode (and changing OPN's LAN to match the Netgear range) would eliminate double NAT, make it way easier to identify the source and get rid of that intermediate routable range...