OPNsense Forum

English Forums => 25.7, 25.10 Series => Topic started by: Jeffrey on December 10, 2025, 09:40:09 PM

Title: Blocking traffic? what am I doing wrong?
Post by: Jeffrey on December 10, 2025, 09:40:09 PM
This should be a no brainer, I have two rules applied to my wan interface, I have put them at the very top to block 170.239.160.0/22 & 187.108.240.0/20 (see attached image).

Traffic is not being blocked, there is a NAT rule forwarding all incoming traffic on port 443 to 172.18.19.2

If I run a tcpdump on the 172.18.19.2 system I see the following -

# tcpdump "tcp[tcpflags] & (tcp-ack) = 0" and port 443 -n -c20
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp6s0f0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
15:29:40.702817 IP 187.108.247.245.25743 > 172.18.19.2.https: Flags [S], seq 3175197668, win 16384, options [mss 1452,sackOK,TS val 2883870863 ecr 0,nop,wscale 6], length 0
15:29:40.702818 IP 187.108.247.245.25743 > 172.18.19.2.https: Flags [S], seq 3175197668, win 16384, options [mss 1452,sackOK,TS val 2883870863 ecr 0,nop,wscale 6], length 0
15:29:40.703251 IP 187.108.247.245.25743 > 172.18.19.2.https: Flags [S], seq 3175197668, win 16384, options [mss 1452,sackOK,TS val 2883870863 ecr 0,nop,wscale 6], length 0
15:29:40.898930 IP 179.106.77.68.14350 > 172.18.19.2.https: Flags [S], seq 1585738757, win 65535, options [mss 1460,sackOK,TS val 1946498062 ecr 0,nop,wscale 5], length 0
15:29:40.914092 IP 187.108.249.81.30930 > 172.18.19.2.https: Flags [S], seq 1291127091, win 65535, options [mss 1452,nop,wscale 6,nop,nop,sackOK], length 0
15:29:40.914092 IP 187.108.249.81.30930 > 172.18.19.2.https: Flags [S], seq 1291127091, win 65535, options [mss 1452,nop,wscale 6,nop,nop,sackOK], length 0
15:29:40.914413 IP 187.108.249.81.30930 > 172.18.19.2.https: Flags [S], seq 1291127091, win 65535, options [mss 1452,nop,wscale 6,nop,nop,sackOK], length 0
15:29:41.074932 IP 187.108.247.245.25743 > 172.18.19.2.https: Flags [S], seq 3175197668, win 16384, options [mss 1452,sackOK,TS val 2883870863 ecr 0,nop,wscale 6], length 0
15:29:41.179480 IP 179.106.76.240.18672 > 172.18.19.2.https: Flags [S], seq 1368460929, win 64240, options [mss 1452,nop,wscale 6,nop,nop,sackOK], length 0
15:29:41.179481 IP 179.106.76.240.18672 > 172.18.19.2.https: Flags [S], seq 1368460929, win 64240, options [mss 1452,nop,wscale 6,nop,nop,sackOK], length 0
15:29:41.180150 IP 179.106.76.240.18672 > 172.18.19.2.https: Flags [S], seq 1368460929, win 64240, options [mss 1452,nop,wscale 6,nop,nop,sackOK], length 0
15:29:41.286667 IP 187.108.249.81.30930 > 172.18.19.2.https: Flags [S], seq 1291127091, win 65535, options [mss 1452,nop,wscale 6,nop,nop,sackOK], length 0
15:29:41.550143 IP 170.239.161.23.249 > 172.18.19.2.https: Flags [S], seq 2311986662, win 65535, options [mss 1412,sackOK,TS val 501677817 ecr 0,nop,wscale 7], length 0
15:29:41.550200 IP 170.239.161.23.249 > 172.18.19.2.https: Flags [S], seq 2311986662, win 65535, options [mss 1412,sackOK,TS val 501677817 ecr 0,nop,wscale 7], length 0
15:29:41.550249 IP 170.239.161.23.249 > 172.18.19.2.https: Flags [S], seq 2311986662, win 65535, options [mss 1412,sackOK,TS val 501677817 ecr 0,nop,wscale 7], length 0
15:29:41.551891 IP 179.106.76.240.18672 > 172.18.19.2.https: Flags [S], seq 1368460929, win 64240, options [mss 1452,nop,wscale 6,nop,nop,sackOK], length 0
15:29:41.893931 IP 179.106.73.138.16542 > 172.18.19.2.https: Flags [S], seq 2137856657, win 65535, options [mss 1452,nop,wscale 6,nop,nop,sackOK], length 0
15:29:41.895644 IP 179.106.73.138.16542 > 172.18.19.2.https: Flags [S], seq 2137856657, win 65535, options [mss 1452,nop,wscale 6,nop,nop,sackOK], length 0
15:29:41.895645 IP 179.106.73.138.16542 > 172.18.19.2.https: Flags [S], seq 2137856657, win 65535, options [mss 1452,nop,wscale 6,nop,nop,sackOK], length 0
15:29:41.921318 IP 170.239.161.23.249 > 172.18.19.2.https: Flags [S], seq 2311986662, win 65535, options [mss 1412,sackOK,TS val 501677817 ecr 0,nop,wscale 7], length 0
20 packets captured
22 packets received by filter
0 packets dropped by kernel


If I look at the live view, I see the traffic is listed as pass but it is on the inside interface with the label of "let out anything from the firewall host itself" which is one of the automatically generated rules.  I don't think this traffic should ever have made it this far, it should be blocked at the outside/wan interface.

As I said this shouldn't be very difficult, so what did I do wrong?

Jeff
Title: Re: Blocking traffic? what am I doing wrong?
Post by: Patrick M. Hausen on December 10, 2025, 09:50:05 PM
NAT rules take precedence over firewall rules. So if you have a NAT > Port forwarding rule that forwards e.g. WAN address:443 to 172.18.19.2:443 and if you have the "Firewall rule association" for that NAT rule set to "pass" - that will permit the traffic.

Either change that "pass" to an explicit rule and then e.g. put all those networks supposed to be blocked in a network or group alias and use "source invert" to only allow "! bad boys". Or place the block rules into the floating category with an explicit "WAN" interface selection, because also: floating before interface.
Title: Re: Blocking traffic? what am I doing wrong?
Post by: Jeffrey on December 10, 2025, 10:01:16 PM
I disabled the NAT rule temporarily (image attached) and the traffic continues

Title: Re: Blocking traffic? what am I doing wrong?
Post by: Jeffrey on December 10, 2025, 10:17:22 PM
With the NAT disabled I do see much of the traffic being blocked but not all of it...


# tcpdump "tcp[tcpflags] & (tcp-ack) = 0" and port 443 and net 170.239.160.0/24 -n -c20
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp6s0f0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
16:08:41.852675 IP 170.239.160.240.18672 > 172.18.19.2.https: Flags [S], seq 1368460929, win 64240, options [mss 1452,nop,wscale 6,nop,nop,sackOK], length 0
16:08:41.854005 IP 170.239.160.240.18672 > 172.18.19.2.https: Flags [S], seq 1368460929, win 64240, options [mss 1452,nop,wscale 6,nop,nop,sackOK], length 0
16:08:41.854053 IP 170.239.160.240.18672 > 172.18.19.2.https: Flags [S], seq 1368460929, win 64240, options [mss 1452,nop,wscale 6,nop,nop,sackOK], length 0
16:08:44.481879 IP 170.239.160.4.51266 > 172.18.19.2.https: Flags [S], seq 465277211, win 65535, options [mss 1460,sackOK,TS val 2434516034 ecr 0,nop,wscale 8], length 0
16:08:44.481880 IP 170.239.160.4.51266 > 172.18.19.2.https: Flags [S], seq 465277211, win 65535, options [mss 1460,sackOK,TS val 2434516034 ecr 0,nop,wscale 8], length 0
16:08:44.483950 IP 170.239.160.4.51266 > 172.18.19.2.https: Flags [S], seq 465277211, win 65535, options [mss 1460,sackOK,TS val 2434516034 ecr 0,nop,wscale 8], length 0
16:08:44.852749 IP 170.239.160.4.51266 > 172.18.19.2.https: Flags [S], seq 465277211, win 65535, options [mss 1460,sackOK,TS val 2434516034 ecr 0,nop,wscale 8], length 0
16:08:49.442890 IP 170.239.160.37.57579 > 172.18.19.2.https: Flags [S], seq 3965481071, win 29200, options [mss 1460,sackOK,TS val 1886380011 ecr 0,nop,wscale 5], length 0
16:08:49.443691 IP 170.239.160.37.57579 > 172.18.19.2.https: Flags [S], seq 3965481071, win 29200, options [mss 1460,sackOK,TS val 1886380011 ecr 0,nop,wscale 5], length 0

(https://jr.bubble.org/opn1.png)
Title: Re: Blocking traffic? what am I doing wrong?
Post by: Patrick M. Hausen on December 10, 2025, 10:19:53 PM
Did you clear the firewall states after the change?
Title: Re: Blocking traffic? what am I doing wrong?
Post by: Jeffrey on December 10, 2025, 10:53:58 PM
clearing the states seems to have done it.

I did go back and create an alias and applied it to the NAT rule.  Personally I would have thought "block rules" applied to an interface would have been processed before NAT, I guess there is a reason it isn't. I need to look at the documentation to see what the processing order is.

Thanks, I knew this shouldn't have been very difficult.

Jeff
Title: Re: Blocking traffic? what am I doing wrong?
Post by: Patrick M. Hausen on December 10, 2025, 11:13:47 PM
It isn't and it is well documented, although one could argue that the "NAT before filtering" is a bit surprising.

https://docs.opnsense.org/manual/firewall.html#processing-order