netfilter buglog - Aug 2013 - [Bug 839] New: SNAT66 does not work for bidirectional UDP

https://bugzilla.netfilter.org/show_bug.cgi?id=839

           Summary: SNAT66 does not work for bidirectional UDP
           Product: netfilter/iptables
           Version: unspecified
          Platform: x86_64
        OS/Version: Gentoo
            Status: NEW
          Severity: normal
          Priority: P5
         Component: NAT
        AssignedTo: netfilter-buglog at lists.netfilter.org
        ReportedBy: saltyacid at gmail.com
   Estimated Hours: 0.0


Created attachment 410
  --> https://bugzilla.netfilter.org/attachment.cgi?id=410
kernel configuration

Tested on linux 3.10.4 gentoo KVM with iptables v1.4.19.1. I have attached the
kernel configuration file.

Setup SNAT using:
ip6tables -t nat -A POSTROUTING -o eth2 -j SNAT --to <public_ip6_addr>
Also tested with -p udp and using -s ip6_addr instead of -o but the result is
the same...

We send a packet from COMP1 which is behind NAT and attached to the gentoo
machine performing NAT via eth1, and COMP2 attached via eth2 will reply. When
using TCP or ICMPv6 everything works as expected but with UDP the reply is
dropped by the NAT device. So the first packet, sent from behind NAT is
properly translated and then received by COMP2, but the reply does not leave
netfilter on gentoo machine.

Using conntrack -f ipv6 -L it is possible to see that connection tracking is
set up as expected (but it is marked UNREPLIED - in the IPv4 case it does say
ASSURED).

Any ideas?

-- 
Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

https://bugzilla.netfilter.org/show_bug.cgi?id=839

Phil Oester <netfilter at linuxace.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |netfilter at linuxace.com

--- Comment #1 from Phil Oester <netfilter at linuxace.com> 2013-08-06
18:38:00 CEST ---
Works fine for me here on 3.10.  5857::129 is the SNAT box

09:33:34.664987 IP6 5858::200.57294 > 5854::1.53: 24043+ [1au] A? ibm.com.
(36)
09:33:34.665060 IP6 5857::129.57294 > 5854::1.53: 24043+ [1au] A? ibm.com.
(36)
09:33:34.666017 IP6 5854::1.53 > 5857::129.57294: 24043 1/4/5 A 129.42.38.1
(226)
09:33:34.666044 IP6 5854::1.53 > 5858::200.57294: 24043 1/4/5 A 129.42.38.1
(226)

and conntrack output:

udp      17 28 src=5858::200 dst=5854::1 sport=40687 dport=53 src=5854::1
dst=5857::129 sport=53 dport=40687 mark=0 use=1

Suggest doing some tcpdumps to see where your packets are going.  And also
confirming the UDP service is actually responding to v6 packets.

-- 
Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

https://bugzilla.netfilter.org/show_bug.cgi?id=839

--- Comment #2 from Sebastian <saltyacid at gmail.com> 2013-08-08 16:24:46
CEST ---
Thank you for your time and for the quick reply! I have done further research
as you suggested, and came to the conclusion that you are right. For the
record, and if someone experiences the same problems, here are possible
reasons:

1) I used an application which calculated UDP checksums incorrectly when the
payload length was over 255 bytes. I think this is the reason for netfilter
throwing my reply packet away (the first packet had a correct checksum since it
was small, the answer did not). However, I noticed that setting the UDP
checksum to zero is allowed and this works fine with NAT. According to RFC2460
the value is not allowed to be zero. Although it is up to the receiver to check
it, it seems inconsistent if netfilter cares about incorrect values but not
invalid values. Correct me if I'm wrong about this. 

2) Using Nmap's ncat and watching the IPv6 UDP packets with tcpdump 4.3.0
also
yields a "bad udp cksum" (default payload length for ncat is
apparently 8200 so
the packets require fragmentation which probably affects they way tcpdump looks
at the packets).

3) Also tested with Iperf version 2.0.5 (8 july 2010, exactly 3 years ago)
single threaded instance. This did not work, apparently because a single
threaded instance of Iperf does not allow the option -d (bidirectional), but
fails rather silently. 

4) I was reading http://atoomnet.net/howto-ipv6-nat-in-centos-6/ where the
author reported the same issue with UDP while TCP/ICMP worked fine.

-- 
Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

https://bugzilla.netfilter.org/show_bug.cgi?id=839

Phil Oester <netfilter at linuxace.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID

--- Comment #3 from Phil Oester <netfilter at linuxace.com> 2013-08-08
17:07:49 CEST ---
Most nics support checksum offload, so the incorrect checksums you are seeing
are false positives.  Disable checksum offloading via:

  ethtool --offload  ethX  rx off  tx off

then you should see valid checksums in tcpdump.  See
http://wiki.wireshark.org/CaptureSetup/Offloading#Checksum_Offload for further
info.

Closing.

-- 
Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.