It does not.
0.010267 openbsd.4500 > asa.4500: [bad udp cksum 6d4c!] udpencap: isakmp
v1.0 exchange QUICK_MODE
cookie: 1dc820688b0e577c->9abdf94cdd39ebb0 msgid: 0b77fb8d len: 292
payload: HASH len: 24
payload: SA len: 56 DOI: 1(IPSEC) situation: IDENTITY_ONLY
payload: PROPOSAL len: 44 proposal: 1 proto: IPSEC_ESP spisz: 4
xforms: 1 SPI: 0x30a85144
payload: TRANSFORM len: 32
transform: 1 ID: AES
attribute LIFE_TYPE = SECONDS
attribute LIFE_DURATION = 28800
attribute ENCAPSULATION_MODE = TUNNEL
attribute AUTHENTICATION_ALGORITHM = HMAC_SHA
attribute GROUP_DESCRIPTION = 2
attribute KEY_LENGTH = 256
On Sat, Feb 1, 2014 at 5:39 PM, Stuart Henderson <[email protected]>wrote:
> isakmpd already sends the values from the RFC doesn't it?
>
> On 2 February 2014 00:23:19 GMT+00:00, Joel Knight <[email protected]>
> wrote:
> >Hi.
> >
> >I found an old post of sthen's to tech@ about NAT-T interop between
> >isakmpd(8) and Cisco ASA. In summary, when isakmpd negotiates NAT-T
> >with
> >ASA, it doesn't send the proper encapsulation mode (as per RFC 3947).
> >Original post is here:
> >
> http://openbsd.7691.n7.nabble.com/isakmpd-NAT-T-interoperability-td173004.html
> >
> >The original patch had isakmpd send the encap mode values as specified
> >in
> >the NAT-T draft (modes 61443/61444) which I found ASA 9.x code rejected
> >(rightly or wrongly). Having isakmpd send the RFC values of 3/4 allows
> >the
> >tunnel to come up.
> >
> >I don't know enough to say what the correct behavior should be here,
> >but as
> >sthen points out, the current behavior is definitely wrong.
> >
> >
> http://packetmischief.ca/files/openbsd/patches/isakmpd-nat-t-encap-mode.diff
> >
> >
> >
> >
> >.joel
>
>
