Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 1 subscriber
  • Views 1027 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

IPSec connection to Sonicwall w/ virtual IP

DCoulson
I am trying to configure my Astaro to connect to a Sonicwall device - I am able to connect via the Sonicwall app, so I know my credentials are good, as well as my IKE/IPSec policy configs. I have to provide both a PSK and XAUTH info, which is setup in the Astaro.

When it tries to connect I get the following:

2010:10:11-12:00:39 dcoulson pluto[31942]: forgetting secrets
2010:10:11-12:00:39 dcoulson pluto[31942]: loading secrets from "/etc/ipsec.secrets"
2010:10:11-12:00:39 dcoulson pluto[31942]:   loaded private key file '/etc/ipsec.d/private/REF_WhHfGTCcgZ.pem' (1679 bytes)
2010:10:11-12:00:39 dcoulson pluto[31942]:   loaded private key file '/etc/ipsec.d/private/REF_WhHfGTCcgZ.pem' (1679 bytes)
2010:10:11-12:00:39 dcoulson pluto[31942]:   loaded private key file '/etc/ipsec.d/private/REF_WhHfGTCcgZ.pem' (1679 bytes)
2010:10:11-12:00:39 dcoulson pluto[31942]:   loaded XAUTH key for dcoulson
2010:10:11-12:00:39 dcoulson pluto[31942]:   loaded shared key for x.x.x.4 y.y.y.y.124 
2010:10:11-12:00:39 dcoulson pluto[31942]: Changing to directory '/etc/ipsec.d/cacerts'
2010:10:11-12:00:39 dcoulson pluto[31942]:   loaded CA cert file 'REF_XwrYboqZLB.pem' (3073 bytes)
2010:10:11-12:00:39 dcoulson pluto[31942]: Changing to directory '/etc/ipsec.d/aacerts'
2010:10:11-12:00:39 dcoulson pluto[31942]: Changing to directory '/etc/ipsec.d/ocspcerts'
2010:10:11-12:00:39 dcoulson pluto[31942]: Changing to directory '/etc/ipsec.d/crls'
2010:10:11-12:00:39 dcoulson pluto[31942]: "S_REF_lwGTyqvKzW_0" #2: ignoring Vendor ID payload [5b362bc820f60007]
2010:10:11-12:00:39 dcoulson pluto[31942]: "S_REF_lwGTyqvKzW_0" #2: received Vendor ID payload [RFC 3947]
2010:10:11-12:00:39 dcoulson pluto[31942]: "S_REF_lwGTyqvKzW_0" #2: enabling possible NAT-traversal with method 3
2010:10:11-12:00:39 dcoulson pluto[31942]: "S_REF_lwGTyqvKzW_0" #2: ignoring Vendor ID payload [404bf439522ca3f6]
2010:10:11-12:00:39 dcoulson pluto[31942]: "S_REF_lwGTyqvKzW_0" #2: received Vendor ID payload [XAUTH]
2010:10:11-12:00:39 dcoulson pluto[31942]: "S_REF_lwGTyqvKzW_0" #2: received Vendor ID payload [Dead Peer Detection]
2010:10:11-12:00:39 dcoulson pluto[31942]: "S_REF_lwGTyqvKzW_0" #2: NAT-Traversal: Result using RFC 3947: no NAT detected
2010:10:11-12:00:39 dcoulson pluto[31942]: "S_REF_lwGTyqvKzW_0" #2: ModeCfg message is unacceptable because it is for an incomplete ISAKMP SA (state=STATE_MAIN_I3)
2010:10:11-12:00:49 dcoulson pluto[31942]: packet from x.x.x.4:500: size (64) differs from size specified in ISAKMP HDR (28)
2010:10:11-12:00:50 dcoulson pluto[31942]: packet from x.x.x.4:500: ModeCfg message is for a non-existent (expired?) ISAKMP SA

A quick look on google indicates that the ModeCfg error is because the Astaro is not expecting an assigned IP from the other side. Is there a way to configure the Astaro to do this?


This thread was automatically locked due to age.
  • 0
    ModeCfg normally starts after after the ISAKMP SA is established. According to the log snippet you posted, this is not the case here. The Sonicwall should send its 3rd Main Mode packet and then the ModeCfg stuff. Packet reordering can of course happen, but that should be dealt with by retransmissions. Also 
    size (64) differs from size specified in ISAKMP HDR (28)
     looks really broken.
  • 0 in reply to d12fk
    ModeCfg normally starts after after the ISAKMP SA is established. According to the log snippet you posted, this is not the case here. The Sonicwall should send its 3rd Main Mode packet and then the ModeCfg stuff. 


    Okay, so the short answer is that this is not going to work? Unfortunately, I do not control the Sonicwall at the other end, so I am limited in what I can do. Any config changes in the Astaro that may make a difference, or am I stuck with it?
  • 0 in reply to DCoulson
    Well, not if the log looks like this for each connection attempt. You could also attach a complete IPsec log from the Astaro with "Control" and "Parsing" debug level enabled, so I can 100% confirm that it's the Sonicwall causing this. You could also ask them to disable XAUTH, maybe it works then.
  • 0 in reply to d12fk
    I am seeing exactly the same symptoms also with a Sonicwall counterpart.
    The full log can be found here.

    Is there anything else I can provide to find a solution?

    Thanks a lot for your help!