<div dir="ltr"><div><div><div>Hello,<br><br></div>Thanks Paul, that is what I was hoping to hear.<br><br></div>V/r,<br></div>Bryan<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 20, 2016 at 1:48 PM, Paul Wouters <span dir="ltr"><<a href="mailto:paul@nohats.ca" target="_blank">paul@nohats.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, 20 Sep 2016, Bryan Harris wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br>
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.<br>
<br>
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<br>
can see lots of esp packets, but ne'er any a drop of ah.<br>
<br>
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<br>
output at the bottom of this email.<br>
<br>
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<br>
is uncommon, so I wonder if I don't need that rule.<br>
</blockquote>
<br></span>
AH is protocol 51. ESP is protocol 50. So the arguments to tcpdump<br>
are different (-p esp versus -p ah). In libreswan you configure<br>
this with type=esp or type=ah<br>
<br>
ESP is what you think of traditionally as IPsec - packet encryption.<br>
AH is not doing encryption, but only doing integrity checks ("has the<br>
packet been modified in transit?") AH is similar to ESP-NULL (null<br>
encryption) There is NAT-Traversal support for ESP, but not for AH.<br>
<br>
>From the ipsec.conf man page:<br>
<br>
phase2<br>
        Sets the type of SA that will be produced. Valid options are:<br>
        esp for encryption (the default), ah for authentication only.<br>
<br>
        The very first IPsec designs called for use of AH plus ESP to<br>
        offer authentication, integrity and confidentiality. That dual<br>
        protocol use was a significant burden, so ESP was extended to<br>
        offer all three services, and AH remained as an auth/integ. Only<br>
        broken configurations (often used with racoon) require the strange<br>
        double authentication using ah+esp. Additionally, AH does not play<br>
        well with NATs, so it is strongly recommended to use ESP with the<br>
        null cipher if you require unencrypted authenticated transport.<br>
<br>
<br>
Almost no one uses AH, yet the IETF is unable to kill it off. There is<br>
always someone who wants to keep it in favour of ESP-NULL.<span class="HOEnZb"><font color="#888888"><br>
<br>
Paul<br>
</font></span></blockquote></div><br></div>