Thanks for your extensive explanation. I think I'm getting the hang
of reading pluto debug. Althought the asterisks are intended for
emacs users (I'm not an emacs user, I'm too scared to try it, from
what hear it's quite addictive ;-) they are pretty handy for keeping
track of where you are.
I tried your suggestions, neither one worked :-(
The sonicwall allows you to specify different DH Groups for Phase 1
and Phase 2, after some experimentation and sniffing through the
pluto debug I concluded that
MODP1024 = Diffie Helmann Group 2
MODP1536 = Diffie Helmann Group 5
So I decided to adopt a systematic approach to trying all sensible
combinations of DH groups, pfs, encyption.
I excluded dh group 1 as I remember reading somewhere that freeswan
doesn't support it (I believe it's a 768 bit key)
The end result....
If the sonicwall's config meets the basic criteria of 3DES, better
than Group 1 (ie 2 or 5), and both ends agree whether to use pfs or
not the connection will open flawlessly if initiated by the
sonicwall, but the sonicwall does not find any proposal made by
freeswan acceptable.
Where to go from here ?
I'm not ready to give up yet but the lack of any info from sonicwall
may be a showstopper
maybe the answer is to poke an appropriate hole in the sonicwall and
stck a box running freeswan behind it, but that's what I was trying
to avoid, having yet another box on the network to manage.
At 3:20 PM -0500 3/15/02, D. Hugh Redelmeier wrote:
>| From: Dariush Mossadeghi <dariush_at_coins.net>
>
>| >If you post the debug log for both negotiations, I might have the time to
>| >explicate it. Be sure to clearly explain the context -- guessing wastes a
>| >lot of time
>|
>| to save cluttering the list with reams of debug I've put the detailed info
>| and more explanation here
>|
>| http://www.gravitas.co.uk/vpndebug/
>|
>| I look forward to hearing from you
>
>Nice description! (Quibble: a barf is often useful. Not in this
>case, but you didn't know that.)
>
>The SonicWALL log certainly gives no hints about what it finds
>unacceptable. This is true of Pluto too, without debugging enabled :-(
>
>First, lets look at the failing pluto log to see what it proposed
>
>Note that it is going to use PFS:
>Mar 15 12:53:57 outsider Pluto[2987]: "testvpn" #2: initiating Quick
>Mode PSK+ENCRYPT+TUNNEL+PFS+DISABLEARRIVALCHECK
>
>I point this out because it is a non-negotiated feature. Your notes
>say that SonicWALL is configured for PFS.
>
>The SA Payload gives lays out the choices for the Responder
>(SonicWALL). I've included the important part of the log at end the
>end of this message. I stripped the boring prefix to make the log
>narrower.
>
>The asterisks are meant to help with EMACS outlining mode (I've not
>tried to use it), so they show a nesting structure. There is
>
> one SA Payload, containing
> one Proposal Payload (ESP), containing
> two Transform Payloads.
>
>The first Transform Payload:
>ESP_3DES OAKLEY_GROUP_MODP1536 ENCAPSULATION_MODE_TUNNEL
>SA_LIFE_TYPE_SECONDS 28800 AUTH_ALGORITHM_HMAC_MD5
>
>The second:
>ESP_3DES OAKLEY_GROUP_MODP1536 ENCAPSULATION_MODE_TUNNEL
>SA_LIFE_TYPE_SECONDS 28800 AUTH_ALGORITHM_HMAC_SHA1
>
>The only difference is the hash (MD5 vs SHA1).
>
>The OAKLEY_GROUP_MODP1536 is used for PFS. It cannot be negotiated,
>but this is the same group that was negotiated in Phase 1, so we
>presume that SonicWALL can accept it.
>
>
>Now let's look at the succeeding negotiation. I included it at the
>end too.
>
>ESP_3DES SA_LIFE_TYPE_SECONDS 3600 OAKLEY_GROUP_MODP1024
>ENCAPSULATION_MODE_TUNNEL AUTH_ALGORITHM_HMAC_MD5
>
>So, what's the difference between this and the two that failed?
>
>- the MODP group used for PFS (Pluto proposed OAKLEY_GROUP_MODP1536,
> SonicWALL proposed OAKLEY_GROUP_MODP1024)
>
>- the SA's lifetime (Pluto proposed 28800 seconds, SonicWALL proposed
> 3600)
>
>I would guess one of these is the problem.
>
>Can you tell SonicWALL what to accept in these attributes?
>
>Pluto can be told what to propose for lifetime.
>
>Pluto cannot be told what to propose for MODP group for PFS in Phase
>2. It seems unlikely that the group that worked in Phase 1 would not
>work in Phase 2. You can tell Pluto to turn off PFS.
>
>My suggestion is to try changing the lifetime first. If that doesn't
>work, try turning off PFS.
>
>Please tell us how you make out.
>
>Hugh Redelmeier
>hugh_at_mimosa.com voice: +1 416 482-8253
>
>
>extract from
><http://www.gravitas.co.uk/vpndebug/plutodebug-openfromoutsider.html>
>"Pluto debug for vpn connection to sonicwall when connection is
>initiated by freeswan (unsuccessful)":
>
>***emit ISAKMP Security Association Payload:
> next payload type: ISAKMP_NEXT_NONCE
> DOI: ISAKMP_DOI_IPSEC
>****emit IPsec DOI SIT:
> IPsec DOI SIT: SIT_IDENTITY_ONLY
>****emit ISAKMP Proposal Payload:
> next payload type: ISAKMP_NEXT_NONE
> proposal number: 0
> protocol ID: PROTO_IPSEC_ESP
> SPI size: 4
> number of transforms: 2
>generate SPI: 1e e8 2b 63
>emitting 4 raw bytes of SPI into ISAKMP Proposal Payload
>SPI 1e e8 2b 63
>*****emit ISAKMP Transform Payload (ESP):
> next payload type: ISAKMP_NEXT_T
> transform number: 0
> transform ID: ESP_3DES
>******emit ISAKMP IPsec DOI attribute:
> af+type: GROUP_DESCRIPTION
> length/value: 5
> [5 is OAKLEY_GROUP_MODP1536 (extension)]
>******emit ISAKMP IPsec DOI attribute:
> af+type: ENCAPSULATION_MODE
> length/value: 1
> [1 is ENCAPSULATION_MODE_TUNNEL]
>******emit ISAKMP IPsec DOI attribute:
> af+type: SA_LIFE_TYPE
> length/value: 1
> [1 is SA_LIFE_TYPE_SECONDS]
>******emit ISAKMP IPsec DOI attribute:
> af+type: SA_LIFE_DURATION
> length/value: 28800
>******emit ISAKMP IPsec DOI attribute:
> af+type: AUTH_ALGORITHM
> length/value: 1
> [1 is AUTH_ALGORITHM_HMAC_MD5]
>emitting length of ISAKMP Transform Payload (ESP): 28
>
>*****emit ISAKMP Transform Payload (ESP):
> next payload type: ISAKMP_NEXT_NONE
> transform number: 1
> transform ID: ESP_3DES
>******emit ISAKMP IPsec DOI attribute:
> af+type: GROUP_DESCRIPTION
> length/value: 5
> [5 is OAKLEY_GROUP_MODP1536 (extension)]
>******emit ISAKMP IPsec DOI attribute:
> af+type: ENCAPSULATION_MODE
> length/value: 1
> [1 is ENCAPSULATION_MODE_TUNNEL]
>******emit ISAKMP IPsec DOI attribute:
> af+type: SA_LIFE_TYPE
> length/value: 1
> [1 is SA_LIFE_TYPE_SECONDS]
>******emit ISAKMP IPsec DOI attribute:
> af+type: SA_LIFE_DURATION
> length/value: 28800
>******emit ISAKMP IPsec DOI attribute:
> af+type: AUTH_ALGORITHM
> length/value: 2
> [2 is AUTH_ALGORITHM_HMAC_SHA1]
>emitting length of ISAKMP Transform Payload (ESP): 28
>emitting length of ISAKMP Proposal Payload: 68
>emitting length of ISAKMP Security Association Payload: 80
>
>extract from
><http://www.gravitas.co.uk/vpndebug/plutodebug-openfromlan.html>
>"Pluto debug for vpn connection to sonicwall when connection is
>initiated by sonicwall (successful)"
>
>****parse ISAKMP Proposal Payload:
> next payload type: ISAKMP_NEXT_NONE
> length: 40
> proposal number: 1
> protocol ID: PROTO_IPSEC_ESP
> SPI size: 4
> number of transforms: 1
>parsing 4 raw bytes of ISAKMP Proposal Payload into SPI
>SPI 2d d4 33 2c
>*****parse ISAKMP Transform Payload (ESP):
> next payload type: ISAKMP_NEXT_NONE
> length: 28
> transform number: 1
> transform ID: ESP_3DES
>******parse ISAKMP IPsec DOI attribute:
> af+type: SA_LIFE_TYPE
> length/value: 1
> [1 is SA_LIFE_TYPE_SECONDS]
>******parse ISAKMP IPsec DOI attribute:
> af+type: SA_LIFE_DURATION
> length/value: 3600
>******parse ISAKMP IPsec DOI attribute:
> af+type: GROUP_DESCRIPTION
> length/value: 2
> [2 is OAKLEY_GROUP_MODP1024]
>******parse ISAKMP IPsec DOI attribute:
> af+type: ENCAPSULATION_MODE
> length/value: 1
> [1 is ENCAPSULATION_MODE_TUNNEL]
>******parse ISAKMP IPsec DOI attribute:
> af+type: AUTH_ALGORITHM
> length/value: 1
> [1 is AUTH_ALGORITHM_HMAC_MD5]
>****emit IPsec DOI SIT:
> IPsec DOI SIT: SIT_IDENTITY_ONLY
>****emit ISAKMP Proposal Payload:
> next payload type: ISAKMP_NEXT_NONE
> proposal number: 1
> protocol ID: PROTO_IPSEC_ESP
> SPI size: 4
> number of transforms: 1
>generate SPI: 5c be 4a 91
>emitting 4 raw bytes of SPI into ISAKMP Proposal Payload
>SPI 5c be 4a 91
>*****emit ISAKMP Transform Payload (ESP):
> next payload type: ISAKMP_NEXT_NONE
> transform number: 1
> transform ID: ESP_3DES
>emitting 20 raw bytes of attributes into ISAKMP Transform Payload (ESP)
>attributes 80 01 00 01 80 02 0e 10 80 03 00 02 80 04 00 01
> 80 05 00 01
>emitting length of ISAKMP Transform Payload (ESP): 28
>emitting length of ISAKMP Proposal Payload: 40
>emitting length of ISAKMP Security Association Payload: 52
_______________________________________________
Users mailing list
Users_at_lists.freeswan.org
http://lists.freeswan.org/mailman/listinfo/users
This archive was generated by hypermail 2.1.3 : Mon Jul 29 2002 - 05:19:45 CEST