Firewall live view of TCP flows not working anymore - "Unknown Option %u" in log

[reinosathe]

For a while now, I can't see any TCP flow logging in the firewall live view log. Only UDP flows show up. The Firewall plain view does show all flows but the TCP flows have an Unknown option %u ending.

Here is an example:
109,,,eed75d558cce27a033cbd0ba409b0cd2,em1,match,pass,in,4,0x0,,222,1451,0,DF,6,tcp,72,3.130.141.237,192.168.1.200,8462,8443,0,S,358758990,,28000,,mss;sackOK;TS;nop;wscale;Unknown Option %u

I've checked this forum and the internet at large and noticed this ticket: https://redmine.pfsense.org/issues/12056  and a reference to this code snippet: https://github.com/pfsense/FreeBSD-ports/blob/95209049501e8372d0f31dcf2dfb45269a179151/sysutils/filterlog/files/print-tcp.c#L211

Could it be that the opnsense code base has the same issue ?

Version details:
OPNsense 23.1.1_2-amd64
FreeBSD 13.1-RELEASE-p6
OpenSSL 1.1.1t 7 Feb 2023

It would be great if this issue can be fixed.

[franco]

The %u baffles me a bit because... it's meant to return the value in question but it doesn't. Might throw of the encoding but it shouldn't destroy the parsing attempt. Let me try this locally...

Underneath, however, it seems to be caused by a previously unknown TCP option value being used and the code is pretty old when it was copied from tcpdump so one way would be to find the TCP option that is unkown and patch it but this might start again in a few years when something else is being introduced into the TCP stack.


Cheers,
Franco

[franco]

That would be it I think. The parser doesn't like the spaces and we should remove them.

https://github.com/opnsense/ports/commit/e19a36952934

The old logs are trashed, but once the new version is installed and started it should generate the proper output and you can let me know the "unknown" value to patch later.

Test package in a few minutes...


Thanks,
Franco

[reinosathe]

Ok, so your reply triggered me to have a dual look at the flows that caused the issue. I logged into the opnsense firewall appliance and ran tcpdump manually. This is a capture of a flow that may show the offending option:

options [mss 1400,sackOK,TS val 1315226242 ecr 0,nop,wscale 7,mptcp capable {0xd67e012adf941119}]

I am running an ADSL/4G multi path TCP connection (living rural so 4G is the main connection but every connection starts on ADSL. I am pretty sure the mptcp option is the offending one. I will validate by disabling the 4G link but I am not sure if that forces my provider to not add the mptcp option anymore. Worth a try though.

But to your point, the code should not barf on unknown options and be future / new options safe.

[franco]

Works on my end... here you go:

# pkg add -f https://pkg.opnsense.org/FreeBSD:13:amd64/snapshots/misc/filterlog-0.7.pkg
# /usr/loca/etc/rc.routing_configure

Log removal might not be needed, the old entries just can't be read.


Cheers,
Franco

[franco]

I'm guessing this then:

"a new TCP option for MPTCP, assigned a value of 30 (decimal) from the TCP option space"

https://www.rfc-editor.org/rfc/rfc6824#section-8


Thanks so far,
Franco

[reinosathe]

Thank you Franco. That was snappy and smooth ;-)

[reinosathe]

Ok, I've applied the patch  and all is good now. I see the log entries that I expect. Both in the plain view but more importantly now also in the Live view. In plain view the option is report as Unknow(30) which is correct for my case
according to the RFC spec (   30      N        Multipath TCP (MPTCP)  )

Problem solved. Thanks again Franco !

[franco]

Nice, thanks for testing. :)

I'm adding https://github.com/opnsense/ports/commit/177707e8589 as a follow up and it shows up correctly then in 23.1.2.


Cheers,
Franco