pfSense

Using TCP RST and ICMP Destination Unreachable, trying to be kind to un-authenticated CP clients

add 65530 set 1 fwd 127.0.0.1,8000 tcp from any to any 80 in
add 65531 set 1 pass tcp from any to any out
# Deny the rest
add 65532 set 1 reset tcp from any to any
add 65533 set 1 unreach port udp from any to any

Following up this old request, I wonder, is it really necessary to fwd all traffic to lighttpd listening at port 8000, since it can only respond to HTTP anyway ?

Last year I tested some changes to the CP ipfw rules:

[snip]
65318      0          0 allow ip from any to table(7) in
65319      0          0 allow ip from table(8) to any out
65320      0          0 pipe tablearg ip from any to table(9) in
65321      0          0 pipe tablearg ip from table(10) to any out
65322 583159   40179494 allow ip from table(1) to any in
65323 952054 1346348093 allow ip from any to table(2) out
65510     84      14142 fwd 127.0.0.1,8000 tcp from any to any dst-port 80 in
65511     77      42384 allow tcp from any to any out
65512     12       1796 reset tcp from any to any
65513   1014      54357 unreach port udp from any to any
65533      0          0 deny ip from any to any
65534      0          0 allow ip from any to any layer2
65535      0          0 allow ip from any to any

In another test I added a ipfw dynamic rule (... limit src-addr x) in an attempt to protect lighttpd listening on port 8000/8001 from intentional or unintentional abuse ...

I do not like sending resets or destination uncreachble since sometimes they will just exit the wrong interface.
Especially on system with more than 2 interfaces on the CP side or clients behind aps that are not on the same subnet of the CP.
For forwarding only port 80 it makes sense and will change the code for 2.1 to that.

Ermal, I can't imagine how TCP resets and UDP destination unreachable could "sometimes just exit the wrong interface" ... but you're the FreeBSD expert ...

It will follow the routing table.
If you see there are a lot of tricks with route-to/reply-to on our rulesets.