Re: [Swan] tcpdump does not find AH packets
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 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
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan
Re: [Swan] tcpdump does not find AH packets
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
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan
[Swan] tcpdump does not find AH packets
Hi all, 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. Thanks in advance for any guidance or explanation. V/r, Bryan Chain INPUT (policy DROP) target prot opt source destination ACCEPT all -- anywhere anywherestate RELATED,ESTABLISHED ACCEPT icmp -- anywhere anywhere ACCEPT esp -- anywhere anywhere ACCEPT all -- anywhere anywhere ACCEPT tcp -- anywhere anywherestate NEW tcp dpt:ssh ACCEPT udp -- anywhere anywhereudp spt:isakmp dpt:isakmp ACCEPT udp -- anywhere anywhereudp spt:ipsec-nat-t dpt:ipsec-nat-t Chain FORWARD (policy DROP) target prot opt source destination ACCEPT all -- anywhere anywherestate RELATED,ESTABLISHED Chain OUTPUT (policy DROP) target prot opt source destination ACCEPT all -- anywhere anywherestate RELATED,ESTABLISHED ACCEPT icmp -- anywhere anywhere ACCEPT esp -- anywhere anywhere ACCEPT tcp -- anywhere anywherestate NEW tcp dpt:ssh ACCEPT udp -- anywhere anywhereudp spt:isakmp dpt:isakmp ACCEPT udp -- anywhere anywhereudp spt:ipsec-nat-t dpt:ipsec-nat-t ___ Swan mailing list Swan@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan
