Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 4 subscribers
  • Views 9265 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 VPN from UTM 9 to a Cradlepoint

Justin Bise

Hello,

I've setup a few IPSEC VPN's with customers and vendors in the past without issue.  For a proof of concept I'm attempting to create a VPN with a Cradlepoint device.  Nothing special being done in regard to the config but I cannot get the tunnel connected.  Below are the messages I'm seeing over and over in the log.

 

 
"S_Cradlepoint" #25: initiating Main Mode to replace #24
"S_Cradlepoint" #25: received Vendor ID payload [XAUTH]
"S_Cradlepoint" #25: received Vendor ID payload [Dead Peer Detection]
"S_Cradlepoint" #25: received Vendor ID payload [RFC 3947]
"S_Cradlepoint" #25: enabling possible NAT-traversal with method 3
"S_Cradlepoint" #25: NAT-Traversal: Result using RFC 3947: peer is NATed
"S_Cradlepoint" #25: next payload type of ISAKMP Hash Payload has an unknown value: 213
"S_Cradlepoint" #25: malformed payload in packet
"S_Cradlepoint" #25: byte 2 of ISAKMP Hash Payload must be zero, but is not
"S_Cradlepoint" #25: malformed payload in packet
"S_Cradlepoint" #25: max number of retransmissions (2) reached STATE_MAIN_I3. Possible authentication failure: no acceptable response to our first encrypted message
"S_Cradlepoint" #25: starting keying attempt 3 of an unlimited number
 
This goes on and on with the number incrementing.  Anyone have any ideas of what could be wrong?  I've been through phase one and two verifying they're the same.  Any input is greatly appreciated.  Thanks.
 
Justin Bise


This thread was automatically locked due to age.
Parents
  • 0

    Hi, Justin, and welcome to the UTM Community!

    We need to see the first time this happens:

    1. Confirm that Debug is not enabled.
    2. Disable the IPsec Connection.
    3. Start the IPsec Live Log and wait for it to begin to populate.
    4. Enable the IPsec Connection.
    5. Show us about 60 lines from enabling through the error.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    Thanks for your response Bob.  Debug is not enabled and there's a few more lines than 60 below.

    For what it's worth I am able to get the VPN working when setting it to Respond Only but I'm not keen on that design as the remote GW is taken out of the config.  Any input is appreciated!

     

    2017:10:19-11:32:00 rrafw1-1 pluto[19299]: "S_Cradlepoint" #187: initiating Main Mode
    2017:10:19-11:32:01 rrafw1-2 pluto[17418]: forgetting secrets
    2017:10:19-11:32:01 rrafw1-2 pluto[17418]: loading secrets from "/etc/ipsec.secrets"
    2017:10:19-11:32:01 rrafw1-2 pluto[17418]: loaded PSK secret for 64.128.x.x 174.232.x.x
    2017:10:19-11:32:01 rrafw1-2 pluto[17418]: loaded PSK secret for 64.128.x.x 216.8.x.x
    2017:10:19-11:32:01 rrafw1-2 pluto[17418]: loaded PSK secret for 64.128.x.x 140.254.x.x
    2017:10:19-11:32:01 rrafw1-2 pluto[17418]: loaded PSK secret for 64.128.x.x %any
    2017:10:19-11:32:01 rrafw1-2 pluto[17418]: loaded PSK secret for 64.128.x.x 52.4.x.x
    2017:10:19-11:32:01 rrafw1-2 pluto[17418]: loaded PSK secret for 64.128.x.x 52.207.x.x
    2017:10:19-11:32:01 rrafw1-2 pluto[17418]: HA System: not master, won't listen for IKE messages
    2017:10:19-11:32:01 rrafw1-2 pluto[17418]: forgetting secrets
    2017:10:19-11:32:01 rrafw1-2 pluto[17418]: loading secrets from "/etc/ipsec.secrets"
    2017:10:19-11:32:01 rrafw1-2 pluto[17418]: loaded PSK secret for 64.128.x.x 174.232.x.x
    2017:10:19-11:32:01 rrafw1-2 pluto[17418]: loaded PSK secret for 64.128.x.x 216.8.x.x
    2017:10:19-11:32:01 rrafw1-2 pluto[17418]: loaded PSK secret for 64.128.x.x 140.254.x.x
    2017:10:19-11:32:01 rrafw1-2 pluto[17418]: loaded PSK secret for 64.128.x.x %any
    2017:10:19-11:32:01 rrafw1-2 pluto[17418]: loaded PSK secret for 64.128.x.x 52.4.x.x
    2017:10:19-11:32:01 rrafw1-2 pluto[17418]: loaded PSK secret for 64.128.x.x 52.207.x.x
    2017:10:19-11:32:01 rrafw1-2 pluto[17418]: loading ca certificates from '/etc/ipsec.d/cacerts'
    2017:10:19-11:32:01 rrafw1-2 pluto[17418]: loaded ca certificate from '/etc/ipsec.d/cacerts/RRARAS01 Verification CA 2.pem'
    2017:10:19-11:32:01 rrafw1-2 pluto[17418]: loaded ca certificate from '/etc/ipsec.d/cacerts/RRARAS01 Verification CA 1.pem'
    2017:10:19-11:32:01 rrafw1-2 pluto[17418]: loaded ca certificate from '/etc/ipsec.d/cacerts/RRAFileVista_Cert Verification CA 3.pem'
    2017:10:19-11:32:01 rrafw1-2 pluto[17418]: loaded ca certificate from '/etc/ipsec.d/cacerts/VPN Signing CA.pem'
    2017:10:19-11:32:01 rrafw1-2 pluto[17418]: loaded ca certificate from '/etc/ipsec.d/cacerts/RRAFileVista_Cert Verification CA 1.pem'
    2017:10:19-11:32:01 rrafw1-2 pluto[17418]: loaded ca certificate from '/etc/ipsec.d/cacerts/RRAFileVista_Cert Verification CA 2.pem'
    2017:10:19-11:32:01 rrafw1-2 pluto[17418]: loading aa certificates from '/etc/ipsec.d/aacerts'
    2017:10:19-11:32:01 rrafw1-2 pluto[17418]: loading ocsp certificates from '/etc/ipsec.d/ocspcerts'
    2017:10:19-11:32:01 rrafw1-2 pluto[17418]: loading attribute certificates from '/etc/ipsec.d/acerts'
    2017:10:19-11:32:01 rrafw1-2 pluto[17418]: Changing to directory '/etc/ipsec.d/crls'
    2017:10:19-11:32:01 rrafw1-2 pluto[17418]: added connection description "S_Cradlepoint"
    2017:10:19-11:32:16 rrafw1-1 pluto[19299]: packet from 174.232.x.x:1947: received Vendor ID payload [XAUTH]
    2017:10:19-11:32:16 rrafw1-1 pluto[19299]: packet from 174.232.x.x:1947: received Vendor ID payload [Dead Peer Detection]
    2017:10:19-11:32:16 rrafw1-1 pluto[19299]: packet from 174.232.x.x:1947: ignoring Vendor ID payload [FRAGMENTATION 80000000]
    2017:10:19-11:32:16 rrafw1-1 pluto[19299]: packet from 174.232.x.x:1947: received Vendor ID payload [RFC 3947]
    2017:10:19-11:32:16 rrafw1-1 pluto[19299]: packet from 174.232.x.x:1947: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
    2017:10:19-11:32:16 rrafw1-1 pluto[19299]: "S_Azure"[38] 174.232.x.x:1947 #188: responding to Main Mode from unknown peer 174.232.x.x:1947
    2017:10:19-11:32:16 rrafw1-1 pluto[19299]: "S_Azure"[38] 174.232.x.x:1947 #188: Oakley Transform [AES_CBC (128), HMAC_SHA1, MODP_1024] refused due to strict flag
    2017:10:19-11:32:16 rrafw1-1 pluto[19299]: "S_Azure"[38] 174.232.x.x:1947 #188: no acceptable Oakley Transform
    2017:10:19-11:32:16 rrafw1-1 pluto[19299]: "S_Azure"[38] 174.232.x.x:1947 #188: sending notification NO_PROPOSAL_CHOSEN to 174.232.x.x:1947
    2017:10:19-11:32:16 rrafw1-1 pluto[19299]: "S_Azure"[38] 174.232.x.x:1947: deleting connection "S_Azure"[38] instance with peer 174.232.x.x {isakmp=#0/ipsec=#0}
    2017:10:19-11:32:46 rrafw1-1 pluto[19299]: packet from 174.232.x.x:1947: received Vendor ID payload [XAUTH]
    2017:10:19-11:32:46 rrafw1-1 pluto[19299]: packet from 174.232.x.x:1947: received Vendor ID payload [Dead Peer Detection]
    2017:10:19-11:32:46 rrafw1-1 pluto[19299]: packet from 174.232.x.x:1947: ignoring Vendor ID payload [FRAGMENTATION 80000000]
    2017:10:19-11:32:46 rrafw1-1 pluto[19299]: packet from 174.232.x.x:1947: received Vendor ID payload [RFC 3947]
    2017:10:19-11:32:46 rrafw1-1 pluto[19299]: packet from 174.232.x.x:1947: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
    2017:10:19-11:32:46 rrafw1-1 pluto[19299]: "S_Azure"[39] 174.232.x.x:1947 #189: responding to Main Mode from unknown peer 174.232.x.x:1947
    2017:10:19-11:32:46 rrafw1-1 pluto[19299]: "S_Azure"[39] 174.232.x.x:1947 #189: Oakley Transform [AES_CBC (128), HMAC_SHA1, MODP_1024] refused due to strict flag
    2017:10:19-11:32:46 rrafw1-1 pluto[19299]: "S_Azure"[39] 174.232.x.x:1947 #189: no acceptable Oakley Transform
    2017:10:19-11:32:46 rrafw1-1 pluto[19299]: "S_Azure"[39] 174.232.x.x:1947 #189: sending notification NO_PROPOSAL_CHOSEN to 174.232.x.x:1947
    2017:10:19-11:32:46 rrafw1-1 pluto[19299]: "S_Azure"[39] 174.232.x.x:1947: deleting connection "S_Azure"[39] instance with peer 174.232.x.x {isakmp=#0/ipsec=#0}
     
    Let me know if there's anything else you'd like to see!
     
     
  • 0 in reply to Justin Bise

    Jason, what happens when you don't select 'Strict policy' in your IPsec Policy?

    If that doesn't resolve the issue, show pictures of the Cradlepoint and UTM IPsec Policies.

    I would have expected the IPsec log to begin with:

    pluto[5924]: forgetting secrets
    pluto[5924]: loading secrets from "/etc/ipsec.secrets"

    But with the Main Mode message immediately before it, I wonder if the IPsec Connection had been stopped before starting the log.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    Bob, you are correct those two lines were there but I didn't think you needed all that.  My mistake.

    I did speak with someone at Cradlepoint and they stated Respond Only is the only way to configure the other end.  Cradlepoint is designed to run a VPN over the internet where the endpoint IP will be changing.  So, that is by design.

    Thank you for taking the time to help me figure this out but Cradlepoint was my issue the whole time!

Reply
  • 0 in reply to BAlfson

    Bob, you are correct those two lines were there but I didn't think you needed all that.  My mistake.

    I did speak with someone at Cradlepoint and they stated Respond Only is the only way to configure the other end.  Cradlepoint is designed to run a VPN over the internet where the endpoint IP will be changing.  So, that is by design.

    Thank you for taking the time to help me figure this out but Cradlepoint was my issue the whole time!

Children
No Data
Unfiltered HTML