[Swan] tcpdump does not find AH packets

[Bryan Harris]

Hello,

Thanks Paul, that is what I was hoping to hear.

V/r,
Bryan

On Tue, Sep 20, 2016 at 1:48 PM, Paul Wouters <paul at nohats.ca> wrote:

> On Tue, 20 Sep 2016, Bryan Harris wrote:
>
> I'm just learning about ipsec and have been able to setup a host to host
>> tunnel using x509 certificates signed by a dummy CA.
>>
>> In some of the documentation I've read I can see an iptables rule to
>> allow AH protocol packets, and after some testing I've become a little
>> confused about AH packets.
>>
>> For example, when I allow these in iptables and search for them via
>> simple tcpdump command "tcpdump -n -i eth1 ah", I never seem to see them.
>> Am I missing any option in the command?  I
>> can see lots of esp packets, but ne'er any a drop of ah.
>>
>> Another example, if I do not allow ah packets in my iptables, the tunnel
>> still seems to work fine.  Of course, the iptables allows udp 500, 4500 and
>> protocol esp.  I put the iptables -L
>> output at the bottom of this email.
>>
>> Is ah really required in all scenarios or are there specific
>> circumstances that ah packets  really get used by ipsec?  I noticed in the
>> RHEL 6 Security Guide they say the AH requirement
>> is uncommon, so I wonder if I don't need that rule.
>>
>
> AH is protocol 51. ESP is protocol 50. So the arguments to tcpdump
> are different (-p esp versus -p ah). In libreswan you configure
> this with type=esp or type=ah
>
> ESP is what you think of traditionally as IPsec - packet encryption.
> AH is not doing encryption, but only doing integrity checks ("has the
> packet been modified in transit?") AH is similar to ESP-NULL (null
> encryption) There is NAT-Traversal support for ESP, but not for AH.
>
> From the ipsec.conf man page:
>
> phase2
>         Sets the type of SA that will be produced. Valid options are:
>         esp for encryption (the default), ah for authentication only.
>
>         The very first IPsec designs called for use of AH plus ESP to
>         offer authentication, integrity and confidentiality. That dual
>         protocol use was a significant burden, so ESP was extended to
>         offer all three services, and AH remained as an auth/integ. Only
>         broken configurations (often used with racoon) require the strange
>         double authentication using ah+esp. Additionally, AH does not play
>         well with NATs, so it is strongly recommended to use ESP with the
>         null cipher if you require unencrypted authenticated transport.
>
>
> Almost no one uses AH, yet the IETF is unable to kill it off. There is
> always someone who wants to keep it in favour of ESP-NULL.
>
> Paul
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20160921/3b87630d/attachment-0001.html>