# ipsec_tools -> SonicWall: fails NO PROPOSAL CHOSEN  [SOLVED]

## sundialsvc4

Here's one for the gipper, because it used to work...

I'm using ipsec-tools to try to connect to a SonicWall router, over a NATted link, using exactly the same configuration parameters as before, and with sainfo (Phase-2) negotiation parameters that are supposed to match exactly what the SonicWall expects.  But I get "NO-PROPOSAL-CHOSEN" in phase-two negotiations.

The IPSEC Phase-1 (ISAKMP) negotiations complete promptly and successfully.  NAT-detection occurs as expected during Phase one.  During phase two, the message appears: 

```
 NAT detected -> UDP encapsulation (ENC_MODE 1->3).
```

 I see no indication that this is abnormal nor a problem.

The phase-two parameters that are supposed to be identical are:    Protocol: ESP  Encryption: 3DES  Authentication: SHA1  No perfect forward secrecy  And so we say: 

```
 sainfo anonymous {

# (no pfs_group specification -- specifying that we don't use PFS)

encryption_algorithm 3des;

authentication_algorithm hmac_sha1;

compression_algorithm deflate;

} 
```

As far as I know, this is correct.  But during phase-2 negotiations we get a notify message.  I took the liberty of patching racoon to add the second line to tell me exactly what the message was:

```
 unknown notify message, no phase2 handler found.

  msg = 'NO-PROPOSAL-CHOSEN'
```

I've also seen INVALID_ID_INFORMATION, and I'm wondering if somehow the underlying cause somehow has to do with the spdadd statements being issued to setkey, which are basically thus:

```
spdadd 192.168.30.0[24] ${LOCAL_ADDR}/32 any

  -p in ipsec esp/tunnel/${REMOTE_ADDR}-${LOCAL_ADDR}/require; 
```

 (and its reverse... for "out")

While I read the racoon source-code to get an idea of how racoon checks proposals (that is, if the situation had been reversed) ... any ideas?Last edited by sundialsvc4 on Mon Nov 06, 2006 8:58 pm; edited 1 time in total

----------

## sundialsvc4

My reading of Racoon source-code is not showing up much of any enlightenment.  Phase one failure is one thing, but phase two seems much less common.  I don't think that the person who is providing the information to me about the router's settings is wrong, and I honestly don't see how my sainfo parameters could be wrong.  I'm quite thoroughly stumped by this.

----------

## sundialsvc4

Solved.  Sort-of.

This is apparently what this device does when you haven't negotiated XAUTH security.

XAUTH has been specified, or so I thought, but apparently it is not working.  The "phase one-and-a-half" exchange that is expected by this device does not take place.

Unfortunately, XAUTH is not standardized.  It does vary by device/vendor, and I do not yet know if "ipsec-tools latest" even supports the flavor used by this device.   :Rolling Eyes: 

Time to do some voodoo, I guess.  (Anybody got a spare cup of bats-wings?)   :Wink: 

----------

