[Swan] tcpdump does not find AH packets

Paul Wouters paul at nohats.ca
Tue Sep 20 17:48:22 UTC 2016

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.


More information about the Swan mailing list