Server --block-ipv6 leaks IPv6 router solicitation

[tct]

Passive Tunnel - A TLS tunnel which uses --keepalive 0 0.

A passive tunnel only exchanges data packets while the tunnel is active. After a period of inactivity the client would be expected to float on the server to re-establish the VPN.

(I understand, this may not be possible etc.. )

Trying to create a passive tunnel I discovered that the server appears to leak IPv6 RS messages. I cannot decode the packets so I have tcpdumps on the tun device to view traffic.

After the tunnel is establish then both peers go quiet. There are no further packets which egress from the client. However, the server does leak OpenVPN data packets and these coincide with IPV6 Router Solicitation messages sent from the server to the tun device.

To confirm, the server uses:

block-ipv6
push "block-ipv6"

The client log shows:

PUSH: Received control message: 'PUSH_REPLY,block-ipv6,topology subnet ... foo

Additional:

• Server uses sitnl
OpenVPN 2.5.0 [git:makepkg/a73072d8f780e888+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Nov 6 2020
• Client uses /sbin/ip
OpenVPN 2.5.0 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Oct 28 2020

---

Server tcpdump on eth0:

21:07:13.243072 IP 92.1.246.125.1807 > 10.10.201.226.55111: UDP, length 50

^ Final packet establishing the tunnel above

These following packets coincide with RS messages on tun0 below.

21:07:43.852919 IP 10.10.201.226.55111 > 92.1.246.125.1807: UDP, length 73
21:08:41.880063 IP 10.10.201.226.55111 > 92.1.246.125.1807: UDP, length 73
21:10:43.052834 IP 10.10.201.226.55111 > 92.1.246.125.1807: UDP, length 73
21:14:35.159686 IP 10.10.201.226.55111 > 92.1.246.125.1807: UDP, length 73
21:22:05.720155 IP 10.10.201.226.55111 > 92.1.246.125.1807: UDP, length 73

Server tcpdump on tun0:

21:07:43.852622 IP6 fe80::6b76:ea66:1134:52c2 > ff02::2: ICMP6, router solicitation, length 8
21:08:41.879612 IP6 fe80::6b76:ea66:1134:52c2 > ff02::2: ICMP6, router solicitation, length 8
21:10:43.052560 IP6 fe80::6b76:ea66:1134:52c2 > ff02::2: ICMP6, router solicitation, length 8
21:14:35.159258 IP6 fe80::6b76:ea66:1134:52c2 > ff02::2: ICMP6, router solicitation, length 8
21:22:05.719384 IP6 fe80::6b76:ea66:1134:52c2 > ff02::2: ICMP6, router solicitation, length 8

Client tcpdump on tun0:

21:07:43.863055 IP6 fe80::6b76:ea66:1134:52c2 > ff02::2: ICMP6, router solicitation, length 8
21:07:44.469480 IP6 fe80::14bd:1204:3091:cf04 > ff02::2: ICMP6, router solicitation, length 8
21:07:44.469610 IP6 fe80::7 > fe80::14bd:1204:3091:cf04: ICMP6, destination unreachable, unreachable route ff02::2, length 56
21:08:21.333479 IP6 fe80::14bd:1204:3091:cf04 > ff02::2: ICMP6, router solicitation, length 8
21:08:21.333678 IP6 fe80::7 > fe80::14bd:1204:3091:cf04: ICMP6, destination unreachable, unreachable route ff02::2, length 56
21:08:41.890803 IP6 fe80::6b76:ea66:1134:52c2 > ff02::2: ICMP6, router solicitation, length 8
21:09:33.013475 IP6 fe80::14bd:1204:3091:cf04 > ff02::2: ICMP6, router solicitation, length 8
21:09:33.013584 IP6 fe80::7 > fe80::14bd:1204:3091:cf04: ICMP6, destination unreachable, unreachable route ff02::2, length 56
21:11:54.325473 IP6 fe80::14bd:1204:3091:cf04 > ff02::2: ICMP6, router solicitation, length 8
21:11:54.325603 IP6 fe80::7 > fe80::14bd:1204:3091:cf04: ICMP6, destination unreachable, unreachable route ff02::2, length 56
21:16:32.853491 IP6 fe80::14bd:1204:3091:cf04 > ff02::2: ICMP6, router solicitation, length 8
21:16:32.853681 IP6 fe80::7 > fe80::14bd:1204:3091:cf04: ICMP6, destination unreachable, unreachable route ff02::2, length 56
21:26:06.293502 IP6 fe80::14bd:1204:3091:cf04 > ff02::2: ICMP6, router solicitation, length 8
21:26:06.293677 IP6 fe80::7 > fe80::14bd:1204:3091:cf04: ICMP6, destination unreachable, unreachable route ff02::2, length 56

Note: All Client RS messages are replied to with dest-unreach.

Client tcpdump on eth0 showed zero packets after the VPN setup is completed.

[tct]

Server log --verb 6

[tct]

Client log --verb 6

[tct]

By increasing UDP NAT timeout I was able to receive these messages decoded on the client.

Reading the manual:

--block-ipv6

On the client, instead of sending IPv6 packets over the VPN tunnel, all IPv6 packets are answered with an ICMPv6 no route host message. On the server, all IPv6 packets from clients are answered with an ICMPv6 no route to host message.

Server side IPv6 is not blocked.

[Gert Döring]

Please do not all this "leak". A "leak" in VPN terminology is "packets intended to go through the VPN leak to your normal router", which this is clearly not.

It seems that the logic for "after an incoming IPv6 packet is answered by an ICMPv6 unreachable, drop the incoming IPv6 packet, instead of forwarding to the server" is not working right for (at least) multicast packets. So this would be a bug indeed.

Need to re-test this...

[tct]

On the server end, --block-ipv6 does not block all IPv6 packets.

I have no better term to define this than leak.

[Gert Döring]

Ah. I misunderstood. I read this as "you have configured this on the client and it still sends packets to the server".

Yes, this would be something of a leak, if the server lets multicast packets "out" even though it sent a proper ICMPv6 packet back before. OTOH, all it leaks them *to* is "to the kernel side of the server", and from there, they go nowhere else.

So, maybe not worth actually fixing with more than a remark about multicast packets.

The important thing about --block-ipv6 is "packets from the client to a dual-stacked server in the Internet will not leak around an IPv4-only VPN provider". Which these multicast packets don't do.

[tct]

Replying to Gert Döring:

Ah. I misunderstood. I read this as "you have configured this on the client and it still sends packets to the server".

No, the server sends packets to the client.

Yes, this would be something of a leak, if the server lets multicast packets "out" even though it sent a proper ICMPv6 packet back before. OTOH, all it leaks them *to* is "to the kernel side of the server", and from there, they go nowhere else.

My test shows that blocked IPv6 packets from the server do traverse the tunnel and are seen on the client.

So, maybe not worth actually fixing with more than a remark about multicast packets.

Your decision.

The important thing about --block-ipv6 is "packets from the client to a dual-stacked server in the Internet will not leak around an IPv4-only VPN provider". Which these multicast packets don't do.

That is true, my tests showed no leak from the client side.

[Gert Döring]

Replying to tincantech:

Replying to Gert Döring:

Ah. I misunderstood. I read this as "you have configured this on the client and it still sends packets to the server".

No, the server sends packets to the client.

If I'm not mistaken this is totally outside the scope of --block-ipv6.

It is documented that if you run this on a client, it will block "host -> openvpn" packets, and if run on the server, it will block "openvpn client -> host" packets.

Packets going the other way are just not looked at.

Looking more closely, what you see in the client side tcpdump is "the RS packets from the client are answered with an ICMPv6 error, and not forwarded anywhere" (source IPv6 address ending in :cf04) and what you see in both tcpdumps is "the RS packets from the server's host side are received by the server tun (kernel -> openvpn) and forwarded to the client, and thus seen on the client tun. These are the ones coming from the ...:52c2 IPv6 address.

So, this works as intended, and as documented.

Since this can be easily worked around with a server-side ip6tables rule ("drop IPv6 RS in the OUTPUT table") there really is no need to have this in OpenVPN.

Sorry for misunderstanding twice what you were trying to report - and now I'm just closing this as "notabug". OpenVPN does exactly what is documented what it would do.

[tct]

Replying to Gert Döring:

Sorry for misunderstanding twice what you were trying to report - and now I'm just closing this as "notabug". OpenVPN does exactly what is documented what it would do.

OK. I was not sure of the expected behaviour because "technically" how --block-ipv6 effects the server is not documented. That is, only how the client IPv6 is blocked is clear but it is not clear that server initiated IPv6 is not blocked..

Packets going the other way are just not looked at.

This is the crucial tip.

[Gert Döring]

Hiya,

Replying to tincantech:

Replying to Gert Döring:

Sorry for misunderstanding twice what you were trying to report - and now I'm just closing this as "notabug". OpenVPN does exactly what is documented what it would do.

OK. I was not sure of the expected behaviour because "technically" how --block-ipv6 effects the server is not documented.

Well, you quoted that passage from the manual above already... "On the server, all IPv6 packets from clients are answered with an ICMPv6 no route to host message."

That is, only how the client IPv6 is blocked is clear but it is not clear that server initiated IPv6 is not blocked..

... and since it does not mention anything about packets going the other way, these are exactly what it does not block.

Could there be an extra sentence "IPv6 packets going from server to client are never blocked. If this is needed, local firewalling on the server tun/tap interface can be used"? Yes, sure. Patch welcome :-)

[tct]

Replying to Gert Döring:

Replying to tincantech:

Replying to Gert Döring:

Ah. I misunderstood. I read this as "you have configured this on the client and it still sends packets to the server".

No, the server sends packets to the client.

If I'm not mistaken this is totally outside the scope of --block-ipv6.

Renaming the option to --block-client-ipv6 before it is too late feels more appropriate on this occasion ?

[Gert Döring]

Replying to tincantech:

Renaming the option to --block-client-ipv6 before it is too late feels more appropriate on this occasion ?

It already is too late. An option that has shown up in a release version (not "somewhere in master") can not be renamed "just so".

I see adding appropriate wording to make clear which direction is filtered and which not as sufficient.

(FWIW, this is an option people should not be using anyway... "deploy IPv6, not filter it!". It's intended as stopgap measure if VPN server operators can't get their IPv6 stuff right... so what you are doing with it is interesting :-) - but can be solved as well with iptables)

[tct]

Gert,

sorry, I do not agree with the decision regarding the name of the option.

Therefore, I will not be submitting a patch for this.

[Gert Döring]

The option is what it is, and the documentation says what it does.

It's been in "master" since 2018 - two years time to change the option name. Now it is in a release version, and changing option names in a release branch causes lots of extra work (and then, extra complaints from users), so we don't change option names when we can avoid it. And even then, we carry around compatibility options and print warnings for a long time.

I understand that --block-ipv6 does not what you expect it to do - and that could be made explicit in the documentation, to save others from the same trap, an implicit assumption due to the documentation not being explicit here.

So - at this point, there's two options remaining

• improve documentation
• close the ticket and pout

your choice.

[tct]

Optionally:

• Alias --block-ipv6 for option --block-client-ipv6
• Deprecate --block-ipv6

With regard to IPv6 generally, I understand your personal desire to see v6 as the de-facto standard and v4 as a legacy protocol but the world moves much, much slower than you do.

[Gert Döring]

We might indeed introduce --block-ipv4 one day, when the first IPv6-only VPN offering shows up. But this is a few years down the road, maybe with 2.7 or so.

[tct]

Can that be --block-client-ipv4 ;-)

[Gert Döring]

commit 8a8ee283aa7a4b409a9dafc082a6c65b5539308b (master)
commit 490203e6a7594ed946fe3158a694f80be2c18c9c (release/2.5)
Author: Gert Doering
Date: Fri Dec 25 17:42:14 2020 +0100

Clarify --block-ipv6 intent and direction.