[Bug 851] New: IPv6 SNAT target with --random doesn't work

[bugzilla-daemon at netfilter.org]

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

           Summary: IPv6 SNAT target with --random doesn't work
           Product: netfilter/iptables
           Version: unspecified
          Platform: x86_64
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P5
         Component: NAT
        AssignedTo: netfilter-buglog at lists.netfilter.org
        ReportedBy: netfilter at null.bumpern.de
   Estimated Hours: 0.0


Hi,

I would like to use the IPv6 SNAT target with --random, and that does not seem
to work (on an experimental network I'm preparing, not in the open Internet).
The situation is as follows:


           +----------------+                       +------------------+
           |                |                       |      monitor     |
           |                |                       |                  |
           |                |                       |                  |
           |     gw     eth2|<---------------------+|eth0              |
           |                |                       |                  |
           |                |                       |                  |
           |     eth1       |                       |                  |
           +----------------+                       +------------------+
                   +                             
fd73:d95d:a475:1001:255:64ff:fe9c:6eef
                   |
                   |
                   |
                   v fd73:d95d:a475:1000::1
           +-----------------+
           |      eth0       |
           |                 |
           |                 |
           |                 |
           |                 |
           |     other       |
           +-----------------+

I have a gateway and two other clients called "monitor" and "other". When
"monitor" communicates with "other", the source ip address should be translated
to an IP address between fd73:d95d:a475:ffff::1 and fd73:d95d:a475:ffff::a.

When a SNAT rule is inserted on the gateway, this works. On gw

This basically works, as the following tcpdump (on gw) output shows:

    # ip6tables -t nat -A POSTROUTING -o eth1 -s fd73:d95d:a475:1001::/64 -j
SNAT --to-source fd73:d95d:a475:ffff::1-fd73:d95d:a475:ffff::a
    # tcpdump -n -i eth1 ip6
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
    20:42:23.210428 IP6 fd73:d95d:a475:ffff::a > fd73:d95d:a475:1000::1: ICMP6,
echo request, seq 1, length 64
    20:42:23.210704 IP6 fd73:d95d:a475:1000::1 > fd73:d95d:a475:ffff::a: ICMP6,
echo reply, seq 1, length 64
    20:42:24.209394 IP6 fd73:d95d:a475:ffff::a > fd73:d95d:a475:1000::1: ICMP6,
echo request, seq 2, length 64
    20:42:24.209669 IP6 fd73:d95d:a475:1000::1 > fd73:d95d:a475:ffff::a: ICMP6,
echo reply, seq 2, length 64
    ^C
    4 packets captured
    4 packets received by filter

When the option --random is used, it does not work any more (again, on gw):

    # ip6tables -t nat -D POSTROUTING -o eth1 -s fd73:d95d:a475:1001::/64 -j
SNAT --to-source fd73:d95d:a475:ffff::1-fd73:d95d:a475:ffff::a
    # ip6tables -t nat -A POSTROUTING -o eth1 -s fd73:d95d:a475:1001::/64 -j
SNAT --to-source fd73:d95d:a475:ffff::1-fd73:d95d:a475:ffff::a --random
    # tcpdump -n -i eth1 ip6
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
    20:50:31.523526 IP6 fd73:d95d:a475:ffff::a > fd73:d95d:a475:1000::1: ICMP6,
echo request, seq 1, length 64
    20:50:31.523786 IP6 fd73:d95d:a475:1000::1 > fd73:d95d:a475:ffff::a: ICMP6,
echo reply, seq 1, length 64
    20:50:31.523830 IP6 fe80::21b:21ff:fe69:5fdd > fd73:d95d:a475:1000::1:
ICMP6, destination unreachable, unreachable route fd73:d95d:a475:ffff::a,
length 112
    20:50:32.530121 IP6 fd73:d95d:a475:ffff::a > fd73:d95d:a475:1000::1: ICMP6,
echo request, seq 2, length 64
    20:50:32.530368 IP6 fd73:d95d:a475:1000::1 > fd73:d95d:a475:ffff::a: ICMP6,
echo reply, seq 2, length 64
    20:50:32.530405 IP6 fe80::21b:21ff:fe69:5fdd > fd73:d95d:a475:1000::1:
ICMP6, destination unreachable, unreachable route fd73:d95d:a475:ffff::a,
length 112
    ^C
    6 packets captured
    6 packets received by filter
    0 packets dropped by kernel

Although a connection tracking entry is created, which looks valid (at least
for me), on gw:

    # conntrack -n -L -f ipv6
    icmpv6   58 23 src=fd73:d95d:a475:1001:225:64ff:fe9c:6eef
dst=fd73:d95d:a475:1000::1 type=128 code=0 id=24124 [UNREPLIED]
src=fd73:d95d:a475:1000::1 dst=fd73:d95d:a475:ffff::a type=129 code=0 id=1
mark=0 use=1
    conntrack v1.2.1 (conntrack-tools): 1 flow entries have been shown.


I have no idea on how to debug this further. This was tested on a Ubuntu 13.04
system with the default kernel (3.8) and 3.11.0:

    # uname -a
    Linux gw 3.11.0-7-generic #13-Ubuntu SMP Tue Sep 10 20:55:38 UTC 2013
x86_64 x86_64 x86_64 GNU/Linux

I also had a look at the recent commits to the kernel-code git-repository, but
found no patches which touch this functionality.

Did I do something wrong? Is this a bug? I'm happy to help debbuging this...

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