You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
x86_64, generic (in this case, Supermicro SYS-5018D-FN8T)
Software versions of OpenWrt/LEDE release, packages, etc.
OpenWrt master
Steps to reproduce
This is fairly easy. A while back (around 1997) Sun (which then was the go-to manufacturer for Web servers) decided that a clean 2-way close of a socket (including quiet-time) was too time consuming and that in an effort to be able to cycle through the 5-tuple space more quickly (i.e. in under 250 seconds... keep in mind we were still using HTTP 1.0 back then which didn't allow connection reuse) they'd do a RESET on the connection to circumvent the clean shutdown and quiet-time.
Well, it worked, and now lots of servers tend to do a RESET on the connection. Some still do a 2-way close...
The problem is that this confuses NAT state on firewalls, which drop the connection information as soon as they see the outbound (since it's closer it's usually seen first) RESET packet, but then they see the inbound reset and they're confused because they've already dropped the state associated with the connection. Or else the firewall sees the outbound FIN, ACK but doesn't bother to wait for the FIN at this point before deleting NAT state, since it's the server's problem if he doesn't get it...
If they held onto it (connection state) for a couple of seconds, then it would make more sense... but it would also interfere with cycling through the 5-tuple space quickly. So they can't.
As a result (you were wondering when I was going to get to the point, right? I know I was...), you end up seeing a lot of these harmless but annoying messages in your logs:
For UDP, there's so connection state so messages related to packets which can't get admitted will always be logged. That's fine, and most traffic isn't UDP anyway, so that's not a problem.
But for TCP, logging incoming connection attempts or obviously wrong connection state makes sense... but do we need to log sloppy connection closes?
Can we filter out FIN packets? I guess that would leave us unaware of stealth scans, but I can't think of a better solution... especially on boxes with limited persistent logging resources.
The text was updated successfully, but these errors were encountered:
pprindeville:
Supply the following if possible:
x86_64, generic (in this case, Supermicro SYS-5018D-FN8T)
OpenWrt master
This is fairly easy. A while back (around 1997) Sun (which then was the go-to manufacturer for Web servers) decided that a clean 2-way close of a socket (including quiet-time) was too time consuming and that in an effort to be able to cycle through the 5-tuple space more quickly (i.e. in under 250 seconds... keep in mind we were still using HTTP 1.0 back then which didn't allow connection reuse) they'd do a RESET on the connection to circumvent the clean shutdown and quiet-time.
Well, it worked, and now lots of servers tend to do a RESET on the connection. Some still do a 2-way close...
The problem is that this confuses NAT state on firewalls, which drop the connection information as soon as they see the outbound (since it's closer it's usually seen first) RESET packet, but then they see the inbound reset and they're confused because they've already dropped the state associated with the connection. Or else the firewall sees the outbound FIN, ACK but doesn't bother to wait for the FIN at this point before deleting NAT state, since it's the server's problem if he doesn't get it...
If they held onto it (connection state) for a couple of seconds, then it would make more sense... but it would also interfere with cycling through the 5-tuple space quickly. So they can't.
As a result (you were wondering when I was going to get to the point, right? I know I was...), you end up seeing a lot of these harmless but annoying messages in your logs:
May 12 10:54:09 OpenWrt3 kernel: [481026.650247] DROP(src wan): IN=eth5 OUT= SRC=17.249.44.10 DST=66.232.81.197 LEN=117 TOS=0x00 PREC=0x00 TTL=54 ID=30282 DF PROTO=TCP SPT=443 DPT=49664 WINDOW=235 RES=0x00 ACK PSH URGP=0
May 12 10:54:09 OpenWrt3 kernel: [481026.700207] DROP(src wan): IN=eth5 OUT= SRC=17.249.44.10 DST=66.232.81.197 LEN=64 TOS=0x00 PREC=0x00 TTL=54 ID=30283 DF PROTO=TCP SPT=443 DPT=49664 WINDOW=235 RES=0x00 ACK FIN URGP=0
May 12 10:54:09 OpenWrt3 kernel: [481026.984519] DROP(src wan): IN=eth5 OUT= SRC=17.249.44.10 DST=66.232.81.197 LEN=64 TOS=0x00 PREC=0x00 TTL=54 ID=30284 DF PROTO=TCP SPT=443 DPT=49664 WINDOW=235 RES=0x00 ACK FIN URGP=0
May 12 10:54:10 OpenWrt3 kernel: [481027.855512] DROP(src wan): IN=eth5 OUT= SRC=17.249.44.10 DST=66.232.81.197 LEN=117 TOS=0x00 PREC=0x00 TTL=54 ID=30285 DF PROTO=TCP SPT=443 DPT=49664 WINDOW=235 RES=0x00 ACK PSH FIN URGP=0
For UDP, there's so connection state so messages related to packets which can't get admitted will always be logged. That's fine, and most traffic isn't UDP anyway, so that's not a problem.
But for TCP, logging incoming connection attempts or obviously wrong connection state makes sense... but do we need to log sloppy connection closes?
Can we filter out FIN packets? I guess that would leave us unaware of stealth scans, but I can't think of a better solution... especially on boxes with limited persistent logging resources.
The text was updated successfully, but these errors were encountered: