On Fri, Dec 05, 2008 at 01:56:04PM -0600, Todd T. Fries wrote:
> It was not stated, but I've setup firewalls in the past, I presume you
> have a firewall that is doing 'block in' as a catchall (which catches
> the fragments) ..
>
> Set your return policy on that rule if you wish it to return.
ok
It was not stated, but I've setup firewalls in the past, I presume you
have a firewall that is doing 'block in' as a catchall (which catches
the fragments) ..
Set your return policy on that rule if you wish it to return.
--
Todd Fries .. [EMAIL PROTECTED]
___
Todd T. Fries <[EMAIL PROTECTED]> wrote:
> but .. the bottom line is, 'pf' only has support for reassembling
> IPv4 fragments, not IPv6. And yes, this renderes a stateful filtering
> firewall mostly moot until this is fixed for IPv6, to be clear.
If you can get by with TCP...
> Theory suggests
On Fri, Dec 05, 2008 at 12:43:33PM -0600, Todd T. Fries wrote:
>
> Theory suggests that PMTUD should handle things such that fragments do not
> appear, but encapsulation and tunneling via IPSec tend to generate them
> anyway..
Are we not breaking PMUTD by silently dropping these? Shouldn't there
You've stumbled on a missing feature for v6 support in pf.
Nothing is available at present to solve this correctly.
You could do something that defies reason like 'block in inet' instead of
'block in' but .. the bottom line is, 'pf' only has support for reassembling
IPv4 fragments, not IPv6. An
After wondering why my email was seeing MTU-like issues once I enabled
an record, I see that pf is dropping IPv6 packets that are
fragmented.
pf.conf(5):
1546: Currently, only IPv4 fragments are supported and IPv6 fragments are
blocked unconditionally.
in pf.c, under #ifdef INET6:
4402
6 matches
Mail list logo
