[strongSwan-dev] [PATCH] Suppress next payload indicator for non-NAT peers

[Thomas Egerer]

If a peer does not send any vendor IDs indicating support for
NAT-traversal a responding system that had NAT-traversal configured and
has sent the appropriate vendor IDs generates a MAIN_R2 datagram with a
next payload type set to ISAKMP_NEXT_NATD_DRAFTS but with the actual
payload missing.
This is due to the fact, that nat_traversal_natd_lookup alters the
nat_traversal member of the state contained in an msg_digest. If this
member is then used to either set the np (next payload value) to either
NATD_RFC or NATD_DRAFTS while the actual generation of this payload is
based on the setting of the nat_traversal member in a state this will
ultimately create a crippled packet for responders with a peer not
supporting NAT-traversal at all.
The patch adresses this problem by setting the np value to none if the
nat_traversal member of the state has been set to 0. In any other cases
the original behaviour is retained.
---
 src/pluto/ipsec_doi.c |   13 ++++++++++---
 1 files changed, 10 insertions(+), 3 deletions(-)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Suppress-next-payload-indicator-for-non-NAT-peers.patch
Type: text/x-patch
Size: 673 bytes
Desc: not available
URL: <http://lists.strongswan.org/pipermail/dev/attachments/20100930/3e2dcbc7/attachment.bin>