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