NAT64 and UDP-with-zero-checksum
-
I know that pfSense has its own implementation of NAT64 and it's not relying on tools like Tayga or Jool.
I'm currently dealing the the major issue in moving to a IPv6-mostly setup with regards to VoWiFi (WiFi Calling), and in my testing it seems that the ePDG that's used for tunneling the traffic, is using UDP 4500 with zero-checksum. This is perfectly acceptable in IPv4 world but according to RFC2460 a big no-no in IPv6.
This therefore means that a regular SIIT has some quirks in dealing with IPv4 UDP packets with a zero checksum, either requiring the translator to drop the packet (because it would be invalid in IPv6), calculate the checksum (which is a lot of work for a router), or forward an invalid IPv6 packet. It's also not possible to calculate a checksum when the packet is fragmented without reassembling it, or to even know if a checksum exists in later fragments, which further complicates trying to be RFC2460-compliant without just dropping zero-checksum packets.
But RFC8200 later added a concession that some VPN applications do not need transport layer checksums, and eventually SIIT permitted translation with zero checksum because it will eventually reach IPv4 where it will be accepted. And because of this, latest packages from Tayga have added a flag to allow forwarding of zero-checksum UDP packages.
My question is, how is pfSense handling this issue and can I ask if a similar flag can be added to its native NAT64 implementation?
-
@IonutIT said in NAT64 and UDP-with-zero-checksum:
... can I ask if a similar flag can be added to its native NAT64 implementation?
pfSense uses FreeBSD pf
af-tokeyword for NAT64 (although the feature was AFAIK sponsored by Netgate).I think FreeBSD's bugzilla would be the place to report it, if it is an issue, which I don't know.There is a commit called 'pf: teach nat64 to handle 0 UDP checksums', it may already work.
-
As @patient0 said, pfSense already handles this case. It should just work.
If there's a zero UDP checksum on the IPv4 side pf will calculate it when it translates the packet to IPv6. -
One thing that should be noted, Tayga now has 3 options for handing these packets.
Drop as it always has.
Forward without touching the checksum.
Forward while calculating the checksum, like pfSense does.
VoWiFi/Wifi Calling / IPSec works perfectly fine with the 2nd option of forwarding without touching the checksum.
Need some further testing, but that maybe that the key, maybe some things break when the checksum is inserted when it should be.
Just a thought, might not matter.
-
Yeah, considering I'm stuck and even though it seems that pfSense does pass the zero-checksum packet, VoWiFi still does not work, which makes me thing you might be right and it's HOW it passes it.
So far I can't get it to work when using pfSense NAT64 setup...