Stiil a regression with jails/IPv6/pf?

Tim Bishop tim at
Mon Sep 2 19:33:55 UTC 2013


On Mon, Sep 02, 2013 at 12:22:11PM +0200, Ruben van Staveren wrote:
> On 31 Aug 2013, at 21:49, Tim Bishop <tim at> wrote:
> > This is regarding kern/170070 and these two threads from last year:
> > 
> >
> >
> > 
> > I'm running stable/9 r255017 and I'm seeing the same issue, even with
> > the fix Bjoern committed in r238876.
> This is still with "modulate state" in some rules that also hit ipv6
> traffic ?

No, I'm not using "modulate state". Only "keep state".

> It almost looks like doing this kind of traffic alteration is
> considered harmful for IPv6

So it doesn't look like that's the same problem. It's certainly similar
(IPv6 and pf), but doesn't involve the rdr rule or jails. IPv6 is
otherwise working fine through pf.


> If that is the case, then this should be applicable only to ipv4
> traffic, without requiring specific knowledge from the user
> > 
> > My setup is a dual stack one (IPv6 is done through an IPv4 tunnel) and
> > the problem is only with IPv6. I have jails with both IPv4 and IPv6
> > addresses, and I use pf to rdr certain ports to certain jails. With IPv6
> > I'm seeing failed checksums on the packets coming back out of my system,
> > both with UDP and TCP.
> > 
> > If I connect over IPv6 to the jail host it works fine. If I connect over
> > IPv6 to a jail directly (they have routable addresses, but I prefer them
> > to all be masked behind the single jail host normally), it works fine.
> > So the only failure case is when it goes through a rdr rule in pf.
> > 
> > This system replaces a previous one running stable/8 which worked fine
> > with the same pf config file.
> > 
> > Has anyone got any suggestions on what I can do to fix this or to debug
> > it further?
> > 
> > Thanks,
> > 
> > Tim.

Tim Bishop
PGP Key: 0x6C226B37FDF38D55

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <>

More information about the freebsd-stable mailing list