Hi Erich,

That's interesting; thanks for doing these tests.

Please see my comments inline.


On Sun, Aug 11, 2013 at 7:17 PM, Erich Schubert <er...@debian.org> wrote:

> Hello,
> Thank your for your patch.
> It looks good (and I've already committed it to SVN), however I do get
> a warning message when using it:
>
> Warning: never matched protocol: ah. use extension match instead.
>
> As far as I can tell, this happens in ip6tables only, i.e. IPv6.
>
> From a relevant mailing list post:
> > "-p" uses the first non-extension header (which can never
> > be AH), while "-m ah" matches on AH extension headers.
>
> So at least for IPv6 it seems as if "-p ah" apparently will not have an
> effect?
>

I stumbled upon the post you mentioned, and you're right. So, perhaps we
should always use "-p ah -m ah". Would you mind testing that against
ip6tables?

In the firewall I'm using pyroman-generated rules, I'm only using IPv4 and
ESP in tunnel model (not using AH) even though I've got the "-p ah" rule
installed.



> From what I've figured out so far, AH will never occur alone. It will
> always be ah+esp, and then the protocol match will be for esp?
>
>
As far as I understand, the contrary is true, i.e. in practice ESP and AH
are rarely used together. When used together, I believe the outer packet is
AH (protocol 51) and it chains to an ESP packet.



> Could you try if "-p esp" actually is sufficient to make IPSec work?
>
>
"-p esp" alone does work in IPv4. I have running firewalls that have these
rules actually triggered.



> Do you know if default ISAKMP will be UDP and source port 500, too?
> Right now, I've committed it as dport="isakmp/udp", but if the source
> port will also be 500/udp, I would prefer to make the rule tighter by
> default.
>
>
Actually I don't know, but in my production traffic the source port is 500
too. However, I suspect that in the NAT scenario where there could be
multiple clients connecting to the same server it will have to work with a
non-500 source port.

.wil

Reply via email to