IPv6

Just a heads up for anyone deploying IPV6 with Monowall 1.32.

You should disable Monowall's Traffic Shaper (at least for initial testing) because it appears to break IPV6 routing quite badly.   Symptoms are 25% to 100% packet loss on IPV6 traffic.   IPV4 traffic is OK.

My testing today was using a Cisco 1841 router for my ADSL connection.  I can't be certain, but from a previous installation I think the traffic shaper may be OK with IPV6 if you use an ADSL modem in bridge mode instead of using a router.  But I would still disable the traffic shaper for initial testing.

Cheers,

- Martin

Martin,
What is your ipv6 connection type ? Sixxs ?

How are you seeing packet loss ? Ping ?

What shaper rules do you have and does thois happen under high traffic. Only ?

I use the shaper and have no issue with ipv6

Hi,

My IPV6 connection is native IPV6 over ADSL (UK BT 20CN, ISP www.aaisp.net.uk) using a Cisco 1841 router.

       Internet ADSL <--> Cisco <--> RAW subnet  <--> eth0 Monowall eth1 <-->  LAN subnet
                                                                                                     eth2 <---> DMZ subnet

Three subnets: RAW, LAN & DMZ.
- RAW has its own static /29 on IPV4, and /64 on IPV6. RAW is unfiltered.
- LAN  has its own /27 on IPV4, and /64 on IPV6.  LAN has ingress filtering.
- DMZ has its own /28 on IPV4, and /64 on IPV6.  DMZ has ingress & egress filtering.

IPV6 testing from a laptop in the "RAW" subnet worked OK.

Under low traffic conditions, I had IPV6 connectivity problems from the "LAN" subnet, so I tested by using ping6 to some sites like ipv6.google.com and bottomless.aaisp.net.uk.  That's when the packet loss became obvious.  Also, I couldn't ping6 the inside IP address of the router from the "LAN" subnet, but I could ping6 it from the "RAW" subnet.   Switching off the Traffic Shaper instantly fixed all those problems.

I seem to recall that the traffic shaper was OK when I ran IPV6 with a Draytek Vigor 120 ADSL modem running PPPoE instead of the Cisco router, so maybe there's no problem if Monowall runs PPPoE itself, rather than routing via a default gateway on the WAN side.

Hope this helps

- Martin

where did you get your 3 /64's from ?  did you get a /48 and subnet it further ?

Yes, the ISP allocated me a /48 block, and activated several /64 blocks inside that range.   

For IPV6, the convention seems to be that each customer gets a /48 block, which you then split into a /64 block for each network segment.   

My ISP takes it a bit further, with a control panel that allows you to control the routing for each of your /64 blocks.  This is useful if you have several ADSL lines, or if you have dial-up access as a fallback.  They are also looking at routing their blocks over 3G UMTS.

Cheers

- Martin

I don't see anything in the shaper code that could cause this from a quick check

from /exec.php , check if shaper is intentionally dropping packets by executing

ipfw pipe show

I couldn't ping6 the inside IP address of the router from the "LAN" subnet, but I could ping6 it from the "RAW" subnet

can you check the firewall logs in m0n0wall to see if it's being blocked ?  Is there a route back from the cisco to the LAN subnet ?

I'll re-create the Shaper rules and check whether IPV6 breaks again.  If so I'll do an ipfw pipe show.

The firewall wasn't blocking anything intentionally, but Wireshark showed that it wasn't passing ICMP6 out from the LAN subnet to the RAW subnet (where the router connects).   But there can't be anything wrong with the routes, because it all worked OK when the Shaper is removed (no other changes).

By the way, /exec.php was not able to ping6 the router with the Shaper enabled - very strange!

I will re-test when I can, and report back here.   If I can make it break again, I'll save the firewall config in case you need to look at it.

Thanks,

- Martin

OK, re-test done, and it's repeatable...

Creating a default Traffic Shaper configuration using the Magic Shaper Wizard re-created the IPV6 packet loss problem, as seen when using "ping6" to ping two hosts: ipv6.google.com and bottomless.aaisp.net (which is provided by my ISP for ping tests).

But there was no problem ping6ing the default gateway router at any time, so that issue wasn't repeatable.

I left two ping6 sessions running in different windows on my Macbook, one to ipv6.google.com and one to bottomless.aaisp.net, for 180 seconds.   Watching the ping responses scroll past, whenever packetloss occurred, it happened simultaneously on both sessions for a number of seconds... Then some ping6 replies would come in for a number of seconds.... Then the packetloss would start again.   

As before, turning off the Traffic Shaper fixed the problem: no packetloss in 180 seconds of ping6.

Ping6 statistics with the Traffic Shaper enabled:-

    ping6 ipv6.google.com
    ...
    ^C
    --- ipv6.l.google.com ping6 statistics ---
    177 packets transmitted, 60 packets received, 66.1% packet loss
    round-trip min/avg/max/std-dev = 38.912/61.445/624.117/104.222 ms

    ping6 bottomless.aaisp.net
    ...
    ^C
    --- bottomless.aaisp.net ping6 statistics ---
    182 packets transmitted, 68 packets received, 62.6% packet loss
    round-trip min/avg/max/std-dev = 32.574/51.587/393.065/73.112 ms

Ping6 statistics with the traffic shaper disabled:-

    ping6 ipv6.google.com
    ...
    ^C
    --- ipv6.l.google.com ping6 statistics ---
    183 packets transmitted, 183 packets received, 0.0% packet loss
    round-trip min/avg/max/std-dev = 37.120/41.015/43.692/0.955 ms

    ping6 bottomless.aaisp.net
    ...
    ^C
    --- bottomless.aaisp.net ping6 statistics ---
    190 packets transmitted, 189 packets received, 0.5% packet loss
    round-trip min/avg/max/std-dev = 30.787/34.739/103.051/5.149 ms

I've taken a backup of the Monowall config with the Traffic Shaper enabled.  Happy to send you a sanitized copy privately by email.

I checked the traffic graph, and there was very little WAN or LAN traffic during the packetloss.  The ADSL line was fairly quiet.

Hope this helps,

- Martin

Here's the IPFW Pipe Show, taken during a burst of packetloss:-

$ ipfw pipe show
00001: 540.000 Kbit/s    0 ms   50 sl. 0 queues (1 buckets) droptail
00002:   1.710 Mbit/s    0 ms   50 sl. 0 queues (1 buckets) droptail
q00001: weight 50 pipe 1   50 sl. 1 queues (1 buckets) droptail
    mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
  0 udp   217.169.18.185/62313   81.187.30.119/5060    34     1950  0    0   0
q00002: weight 30 pipe 1   50 sl. 0 queues (1 buckets) droptail
q00003: weight 15 pipe 1   50 sl. 1 queues (1 buckets) droptail
    mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
  0 tcp    81.187.151.35/80       81.52.143.35/40632    3      164  0    0   0
q00004: weight 4 pipe 1   50 sl. 1 queues (1 buckets) droptail

        mask: proto: 0x00, flow_id: 0x00000000,  ::/0x0000 -> ::/0x0000
BKT ___Prot___ _flow-id_ ______________Source IPv6/port_______________ _______________Dest. IPv6/port_______________ Tot_pkt/bytes Pkt/Byte Drp
  0       tcp 1610612736        2001:8b0:1b7:2:226:bbff:fe1a:64a2/53059                        2a02:200:3:1::101/80      553    39521  0    0   0
q00005: weight 1 pipe 1   50 sl. 0 queues (1 buckets) droptail
q00006: weight 30 pipe 2   50 sl. 1 queues (1 buckets) droptail

        mask: proto: 0x00, flow_id: 0x00000000,  ::/0x0000 -> ::/0x0000
BKT ___Prot___ _flow-id_ ______________Source IPv6/port_______________ _______________Dest. IPv6/port_______________ Tot_pkt/bytes Pkt/Byte Drp
  0       tcp 1611071822                        2a02:200:3:1::101/80           2001:8b0:1b7:2:226:bbff:fe1a:64a2/53059   400    30392  0    0   0
q00007: weight 10 pipe 2   50 sl. 0 queues (1 buckets) droptail
q00008: weight 60 pipe 2   50 sl. 1 queues (1 buckets) droptail
    mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
  0 udp     81.52.143.26/13687   81.187.151.35/53      22     1572  0    0   0

Can I also get the output of

Ipfw show ?

The Reason I don't see this problem is that I'm using a tunnel, so the ipfw rules are not in the path of this interface.

The ipfw rules are generated on traffic in/out of your WAN interface, which is separate to a tunnel interface.

I modified my ruleset to include my tunnel interface, and still don't see the problem, but would probably have to move to native ipv6 not a tunnel, to be able replicate.

The notes for ipfw state:

When used with IPv6 data, dummynet currently has several limitations.
     First, debug.mpsafenet=0 must be set.  Second, the information necessi-
     cary to route link-local packets to an interface is not avalable after
     processing by dummynet so those packets are dropped in the output path.
     Care should be taken to insure that link-local packets are not passed to
     dummynet.

in the case of m0n0wall , debug.mpsafenet=1 as this is the default.  This may be related to your problem.  I'll have to poke a bit more later

Can you test

http://m0n0.ch/temp/embedded-1.33-pre1.img

http://m0n0.ch/temp/generic-pc-1.33-pre1.img

it has mpasafenet=0

Hi, thanks for the update.

I will try to do this over the weekend and let you know how it goes.

Thanks!

- Martin

Hi,

I just tried this this evening.

Sorry to say, there does not seem to be any change.

I tried http://m0n0.ch/temp/generic-pc-1.33-pre1.img (because last time round the 1.32 Embedded image was missing 'device re' - the RealTek 8139C+ LAN card).

At first, the image passed no IPV6 traffic at all when the Traffic Shaper was enabled (so for example m0n0.ch and ipv6.google.com were unreachable).   So I deleted and re-created the Traffic Shaper rules.  This restored the previous performance: "ping6" shows intermittent IPV6 routing (heavy packet loss).

Mindful of your note about Link Local problems, I tried changing my laptop's default IPV6 route to 2001:xxxxx rather than fe80:xxxx.  This made no difference: still only intermittent IPV6 traffic.

After deleting the Traffic Shaper config completely, normal IPV6 routing is restored.

So, the advice remains that native IPV6 doesn't play well with Traffic Shaper.

Kind regards,

- Martin.

Just stumbled upon this.

I'm using a Sixxs tunnel and having similar symptoms if the shaper is enabled. First I have to say that I defined all shaper rules on the LAN and PPTP interfaces in order to be able to apply different rules depending on the LAN/PPTP IP Address. So in my case, the IPv6 traffic passes through an interface being shaped, despite using a tunnel.
But the thing that doesn't make it too bad is that the packet loss only occurs if the *download* pipe is at least about 80% saturated. On v6, HTTP browsing is very slow, SSH sessions keep getting connection aborts. The download pipe in my setup is the one that matches the download speed of my ADSL line, but is applied to *outgoing* traffic on LAN/PPTP. Disabling the shaper automagically fixes everything. Since most of the time the download link is pretty much idle plus I'm using v6 just for some experimenting, this isn't really a big issue for me... Traffic shaping is way more important, since most of the time, the upload is clogged and needs some treatment.
But now that I saw this topic here, I thought I should confirm that there seem to be problems.

I don't think this will be fixed in 1.3x , I will look at it with a freebsd8.2 build as that is most likely to be the next release unless there a big enough bug/security fix to justify another 1.3x build.