[strongSwan] Number of NAT-OA payloads sent on IKEv1 transport mode NAT traversal

[Andreas Steffen]

Actually we kind of reluctantly support IPsec transport mode in
the presence of NAT. This is why you must explicitly enable this
mode with --enable-nat-transport.

You are free to contribute full NAT support for IPsec transport mode
to the strongSwan project. Our interests are clearly elsewhere.

Kind regards

Andreas

On 10/13/2010 06:45 PM, IPSec Interest Group wrote:
> Hi,
>       I am trying to establish an IKEv1 transport mode tunnel that
> traverses a NAT, but the quick mode negotiation is failing because
> StrongSwan is not sending the expected number of NAT-OA payloads.   My
> understanding of RFC 3947 is that two NAT-OA payloads should be sent in
> each direction of the quick mode exchange in transport mode:
>
>     In the case of transport mode, both ends MUST send both original
>     Initiator and Responder addresses to the other end.  For tunnel mode,
>     both ends SHOULD NOT send original addresses to the other end.
>
>
>       StrongSwan includes a vendor ID payload for RFC 3947, but it only
> sends one NAT-OA payload, so the tunnel negotiation is failing with an
> indication that the responder received a malformed payload.   Am I
> misunderstanding something here?   It appears StrongSwan isn't
> conforming to RFC3947 for IKEv1 transport mode.
>
>       Thank you for your help!
>       FYI: Here are the trace excerpts for the vendor id and the sending
> of the NAT-OA payloads.
>
> Oct 13 12:28:31 linux125 pluto[7549]: | emitting length of ISAKMP Vendor
> ID Payload: 20
> Oct 13 12:28:31 linux125 pluto[7549]: | out_vendorid(): sending [RFC 3947]
> Oct 13 12:28:31 linux125 pluto[7549]: | ***emit ISAKMP Vendor ID Payload:
> Oct 13 12:28:31 linux125 pluto[7549]: |    next payload type:
> ISAKMP_NEXT_VID
>
>
> Oct 13 12:30:51 linux125 pluto[7549]: | emitting 4 raw bytes of client network into ISAKMP Identification Payload (IPsec DOI)
>
> Oct 13 12:30:51 linux125 pluto[7549]: | client network  c0 a8 32 08
> Oct 13 12:30:51 linux125 pluto[7549]: | emitting length of ISAKMP Identification Payload (IPsec DOI): 12
>
> Oct 13 12:30:51 linux125 pluto[7549]: | ***emit ISAKMP Identification Payload (IPsec DOI):
>
> Oct 13 12:30:51 linux125 pluto[7549]: |    next payload type: ISAKMP_NEXT_NAT-OA
>
> Oct 13 12:30:51 linux125 pluto[7549]: |    ID type: ID_IPV4_ADDR
> Oct 13 12:30:51 linux125 pluto[7549]: |    Protocol ID: 0
>
> Oct 13 12:30:51 linux125 pluto[7549]: |    port: 0
> Oct 13 12:30:51 linux125 pluto[7549]: | emitting 4 raw bytes of client network into ISAKMP Identification Payload (IPsec DOI)
>
> Oct 13 12:30:51 linux125 pluto[7549]: | client network  c0 a8 31 04
> Oct 13 12:30:51 linux125 pluto[7549]: | emitting length of ISAKMP Identification Payload (IPsec DOI): 12
>
> Oct 13 12:30:51 linux125 pluto[7549]: | ***emit ISAKMP NAT-OA Payload:
> Oct 13 12:30:51 linux125 pluto[7549]: |    next payload type: ISAKMP_NEXT_NONE
>
> Oct 13 12:30:51 linux125 pluto[7549]: |    ID type: ID_IPV4_ADDR
> Oct 13 12:30:51 linux125 pluto[7549]: | emitting 4 raw bytes of NAT-OA into ISAKMP NAT-OA Payload
>
> Oct 13 12:30:51 linux125 pluto[7549]: | NAT-OA  c0 a8 32 08
> Oct 13 12:30:51 linux125 pluto[7549]: | NAT-OA (S):  c0 a8 32 08
>
> Oct 13 12:30:51 linux125 pluto[7549]: | emitting length of ISAKMP NAT-OA Payload: 12
>
> Oct 13 12:30:51 linux125 pluto[7549]: | HASH(1) computed:
> Oct 13 12:30:51 linux125 pluto[7549]: |   22 e0 e0 27  ea 47 04 cf  43 8b f9 12  16 1e d1 98
>
> Oct 13 12:30:51 linux125 pluto[7549]: | last Phase 1 IV:  44 7b 00 db  a9 aa ba 2a
>
> Oct 13 12:30:51 linux125 pluto[7549]: | computed Phase 2 IV:
> Oct 13 12:30:51 linux125 pluto[7549]: |   c9 6a 22 8d  5e 2b e6 95  f6 5f 8d 17  cd dc 37 a8
>
> Oct 13 12:30:51 linux125 pluto[7549]: | encrypting:
> Oct 13 12:30:51 linux125 pluto[7549]: |   01 00 00 14  22 e0 e0 27  ea 47 04 cf  43 8b f9 12
>
> Oct 13 12:30:51 linux125 pluto[7549]: |   16 1e d1 98  0a 00 00 30  00 00 00 01  00 00 00 01
>
> Oct 13 12:30:51 linux125 pluto[7549]: |   00 00 00 24  00 03 04 01  0b d6 c6 cb  00 00 00 18
>
> Oct 13 12:30:51 linux125 pluto[7549]: |   00 03 00 00  80 04 00 04  80 01 00 01  80 02 0e 10
>
> Oct 13 12:30:51 linux125 pluto[7549]: |   80 05 00 01  05 00 00 14  c1 59 f6 83  e9 2e 00 08
>
> Oct 13 12:30:51 linux125 pluto[7549]: |   4a fe be 06  80 3e f8 0a  05 00 00 0c  01 00 00 00
>
> Oct 13 12:30:51 linux125 pluto[7549]: |   c0 a8 32 08  15 00 00 0c  01 00 00 00  c0 a8 31 04
>
> Oct 13 12:30:51 linux125 pluto[7549]: |   00 00 00 0c  01 00 00 00  c0 a8 32 08
>
> Oct 13 12:30:51 linux125 pluto[7549]: | emitting 4 zero bytes of encryption padding into ISAKMP Message
>
> Oct 13 12:30:51 linux125 pluto[7549]: | encrypting using 3DES_CBC
> Oct 13 12:30:51 linux125 pluto[7549]: | next IV:  ac 0e f4 48  75 9f 06 42
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users


-- 
======================================================================
Andreas Steffen                         andreas.steffen at strongswan.org
strongSwan - the Linux VPN Solution!                www.strongswan.org
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[ITA-HSR]==