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 <[email protected]> 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 >
_______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
