[Swan] tcpdump does not find AH packets
bryanlharris at gmail.com
Wed Sep 21 10:49:59 UTC 2016
Thanks Paul, that is what I was hoping to hear.
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:
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Swan