Make --passtos work

PMc

Is it only me who would wish that --passtos would actually work in real-life?

With version 2.5.6 it works only in test environments, but as soon as there is other traffic on the link, it works and fails randomly. (IPv6 traffic only, with IPv4 traffic there seems to be no problem)

TinCanTech

PMc wrote Is it only me who would wish that --passtos would actually work

Yes.

PMc wrotein real-life?

lol

PMc wrote With version 2.5.6 it works only in test environments, but as soon as there is other traffic on the link, it works and fails randomly. (IPv6 traffic only, with IPv4 traffic there seems to be no problem)

Could you expand that a little .. ?

PMc

TinCanTech wrote
PMc wrote Is it only me who would wish that --passtos would actually work
Yes.

So it is not useful?

Actually, I was just trying to try it out, and I cannot evaluate the usefulness when it doesn't work.

PMc wrote With version 2.5.6 it works only in test environments, but as soon as there is other traffic on the link, it works and fails randomly. (IPv6 traffic only, with IPv4 traffic there seems to be no problem)
Could you expand that a little .. ?

Hm, what kind of expansion would you need? I think this is quite obvious: tos 0x0
Or, more specifically, I configure my firewall to set codepoint 0x11 on DNS queries (I don't yet know if that helps or hurts, I just intended to find out). Then tcpdump shows tos 0x44 (IP4) or class 0x44 (IP6) for packets outbound on tun. Then for the respective encap UDP packets outbound on vtnet, it well shows 0x44 when the payload is IP4, and only immediately after also for IP6 payload. As soon as some other packets traverse the tunnel, it only shows tos 0x0 for these packets - until another IP4 packet with tos 0x44 is sent. (Then again it works for a moment.)

TinCanTech

Maybe worth reporting a bug ?

This is all I can find:
https://community.openvpn.net/openvpn/query?status=accepted&status=assigned&status=closed&status=new&status=reopened&summary=~passtos&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&desc=1&order=id

PMc

TinCanTech wrote Maybe worth reporting a bug ?

Either that, or going for a stroll into the source - that's how it looks to me, too.

This is all I can find:
https://community.openvpn.net/openvpn/query?status=accepted&status=assigned&status=closed&status=new&status=reopened&summary=~passtos&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&desc=1&order=id

Thank You! I found a mention of this in some mailing list. A diff of that fix might be helpful, but then it's probably too old to be really useful...

PMc

Oh crap... it's not intended to work:

# openvpn --help
OpenVPN 2.5.6 amd64-portbld-freebsd13.1 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Jun 19 2022
...
--passtos       : TOS passthrough (applies to IPv4 only).

So no bug report. And feature requests go here, anyway.

PMc

The source confirms: --passtos is only done when
1. the link does IPv4
2. the payload is IPv4
In that case the tos is configured onto the sending UDP socket with setsockopt().
And there it stays for the subsequent IPv6 packets, because they do nothing to change it. Until a v4 packet without tos comes along.

TinCanTech

Works as intended then ..