Still weird issues with fragmented IPv6 (DNS) packets 2.4.4-p1

johnpoz

Why would it need to be fragged out of the gate?

lst_hoe

Dec 5 14:49:30 10.5.0.3 charon: 05[NET] <con-mobile|76> sending packet: from 2a03:3500:0:a003::100[4500] to 2003:f8:abc0:8401:a05e:95f9:3d24:81c7[4500] (1984 bytes)

Strongswan manage the (UDP) IKEv2 connection and if the remote does not support IKEv2 Fragmentation (at application layer) the packet is because of certificates/keysize used too big to send in one IP(v6) piece. With this the only chance to get it out is to fragment at IP layer as UDP has no concept of a stream like TCP does. So the smartes move would be to send out two (or more) fragmented UDP packets with max MTU of 1280 in case of IPv6 to prevent PMTU issues, which is cumbersome for UDP anyway.

JKnott

@johnpoz said in Still weird issues with fragmented IPv6 (DNS) packets 2.4.4-p1:

Why would it need to be fragged out of the gate?

A source can fragment as necessary, if a packet is too large to fit. This might happen with UDP, where the packet contains a lot of data. Of course, routers are not allowed to fragment IPv6 at all and the trend is to using the do not fragment flag on IPv4.

lst_hoe

Strongswan is bound to the WAN interface so there is no routing at this point and pfsense (WAN) is the source. For the OP this might not be true as the DNS case is only relevant for a DNS Server which is not common to operate on the pfsense box. But either way it looks like pfsense or FreeBSD is not able to create outbound fragmented UDP packets, at least not for IPv6.

sigi

@gertjan said in Still weird issues with fragmented IPv6 (DNS) packets 2.4.4-p1:

Say "Ok !". No MTU erros, no fragment errors :

I'm using pfSense 2.4.4p1, the Resolver (activated DNSSC support) and an extra GIF interface for the ipv6.he.net tunnel.

Ok, this should not be a problem, if pfSense is terminating the HE tunnel. Passing is another story.

lst_hoe

So my issue might be related to the OP if FreeBSD does not create/forward any outbound IPv6 UDP packets at all, or it might be two different issues.

lst_hoe

A short test with IPv4 is working as expected. With IPv4 two UDP fragments are created and send out and therefore the tunnel start working, with IPv6 the oversized UDP datagram (around 2000 bytes) is missing.

sigi

At least for DNS/DNSSEC i could solve the issue, because BIND allows to tune maximum udp packet size on application level. With the value 1460 for max-udp-size the tests from http://dnsviz.net/ and https://dnsflagday.net/ works for both IPv4 and IPv6. Still have Issues with SNMPv3 and big packets over IPv6. For me this is a proof, that there is a difference how MSS works on the same OS/Interfaces between IPv6 and IPv4. This could happen on different stages, maybe even on the interface driver, #device re # RealTek 8139C+/8169/8169S/8110S in my case. Will check if Intel Cards make a difference, if time allows.

sigi

@johnpoz said in Still weird issues with fragmented IPv6 (DNS) packets 2.4.4-p1:

Only real solution then is to make sure your end devices never send IPv6 larger than the min 1280 mtu...

This was the "cloudflare-solution" for long time..
https://blog.cloudflare.com/increasing-ipv6-mtu/

maverick_slo

Hello.

Well this seems to be a problem.
domain.com. @85.xx.xx.xx (ns1.domain.com.): dns=ok edns=ok edns1=ok edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok docookie=ok,cookie edns512tcp=ok optlist=ok,expire,cookie,subnet

domain.com. @2001:xxxx:xxx:xxx::92 (ns1.domain.com.): dns=ok edns=ok edns1=ok edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok docookie=timeout edns512tcp=ok optlist=ok,expire,cookie,subnet

With HE.NET IPv6 servers all OK.
Also dnssec complains about packet size.

If I understood correctly thhere is nothing I can do on my side to mitigate this issue?

Thanks!

sigi

@maverick_slo The only solution i found was to adjust/reduce max-udp-size on BIND side. (Not MTU!!)

maverick_slo

Did just that:
max-udp-size 1460;

No go, still timeout.
I`m not sure this is pfsense issue.

sigi

@maverick_slo this means not that the same value is ok in your network. Try to go down further....