Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 12 replies
  • Subscribers 1 subscriber
  • Views 13444 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 site to site dropping

Ross86
I have an iPsec VPN that's connected to Rackspace, it randomly disconnects every hour/5min/4 hours could be anything.  When I ping one if the internal addresses over the VPN one packet will drop it then reconnects itself and receives replies.

Here is what I'm seeing in the logs when it's disconnected:

"S_REF_IpsSitRackspace_0"[1] 89.234.57.186 #159: max number of retransmissions (20) reached STATE_MAIN_I1.  No response (or no acceptable response) to our first IKE message
2014:08:29-07:26:48 UTM-1 pluto[19469]: "S_REF_IpsSitRackspace_0"[1] 'IP ADDRESS' #159: starting keying attempt 42 of an unlimited number
2014:08:29-07:26:48 UTM-1 pluto[19469]: "S_REF_IpsSitRackspace_0"[1] IP ADDRESS#162: initiating Main Mode to replace #159
2014:08:29-07:26:48 UTM-1 pluto[19469]: packet from IP ADDRESS:500: ignoring informational payload, type NO_PROPOSAL_CHOSEN

I have DPD on and NAT tried turning them off doesn't make a difference maybe seemed to stay connected longer but that's all.  I turned on probe PSK because I read a Sophos kb about it as well.

VPN is respond only with PSK.

Any clues as to why this is happening?  This was  originally migrated from a Juniper SRX by a Sophos.  Now I can't confirm if this happened  on the SRX as we didn't receive alerts, or even if it's chasing a problem other than getting lots of alerts to say it's up and down.

Thanks
Ross


This thread was automatically locked due to age.
  • 0
    DPD must match on both sides.  NAT-T is probably what you want.  If PSK probing had been required, you wouldn't have been able to connect in the first place.  The first thing to check is that the IKE and IPsec SA lifetimes match on both sides as well as the other parameters while you're there.  What is the reason for the "Respond only" setting?

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0
    Ok thanks Bob I'll check those details, I may speak to Rackspace to confirm the DPD setting.

    It's in respond only as that's how the approved Sophos supplier configured it, on the juniper it was set to main mode I cannot see anything regarding respond.
  • 0
    The UTM only does Main Mode, not Aggressive, so it's the same as the Juniper in that.

    "Respond only" is used when the other endpoint is behind a NATting router and the endpoint doesn't have a mechanism to communicate its local IP in establishing the IPsec tunnel.

    If there isn't a difference in the Policies, I suspect that "Initiate connection" would solve this problem.  It's important to know whether the IPsec endpoint at the other end has a local IP or the public one configured in your system as the 'Remote gateway'.  If it is a private IP, then the question is what VPN package is in use and whether it can send its "leftid" (in StrongSWAN parlance).

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0
    Ok great thanks Bob, I'll check over the config and probably drop Rackspace a message to confirm this. I'll report back when it's hopefully resolved!
  • 0
    Here is some old config I found from Rackspace in the meantime, I'm no VPN expert but can you determine what settings I would need from this?

    isakmp enable outside
    isakmp key ******** address 'UTM external IP' netmask 255.255.255.255 no-xauth no-config-mode
    isakmp identity address



    Phase 1
    isakmp policy 10 authentication pre-share
    isakmp policy 10 encryption 3des
    isakmp policy 10 hash sha
    isakmp policy 10 group 2
    isakmp policy 10 lifetime 28800


    phase 2
    crypto ipsec transform-set rackset esp-3des esp-sha-hmac
    crypto map rackmap 200 ipsec-isakmp

    crypto map rackmap 200 set peer 'UTM external IP'
    crypto map rackmap 200 set transform-set rackset
    crypto map rackmap 200 set security-association lifetime seconds 3600 kilobytes 4608000


    access-list 200; 1 elements
    access-list 200 line 1 permit ip 192.168.1.0 255.255.255.0 10.0.0.0 255.255.0.0 (hitcnt=15801480)
  • 0
    I just checked the above config against what's configured on the UTM, the phase 1 lifetime was 7800 so I changed it to 28800 as above and it connected within a minute, turned off probe PSK and it disconnected but a min later connected again.  

    Good signs... Would the phase 1 lifetime not matching have caused this?
  • 0
    Yes.  Everything must match on both sides.  Any mismatch in settings will cause issues.
    __________________
    ACE v8/SCA v9.3

    ...still have a v5 install disk in a box somewhere.

    http://xkcd.com
    http://www.tedgoff.com/mb
    http://www.projectcartoon.com/cartoon/1
  • 0
    I spoke too soon, it stayed connected for 5 hours and disconnected.
  • 0
    Ross, I'm starting to think this is either a problem with a PPPoE/A reconnect on your end or something on their end.

    I still think that you can solve the problem by replacing the "Respond only" Remote Gateway definition in the UTM with one that is "Initiate connection."  If that doesn't connect at all, you'll need to learn the internal IP of the Rackspace endpoint - enter that into the 'VPN ID (optional)' field of this definition.

    Cheers - Bob
    PS I don't remember if I've mentioned it on one of your threads, but it's not a best practice to use PSKs for site-to-site connections unless you have complex keys and change them at least once a quarter.  If this is your only site-to-site connection, RSA keys are probably all that you need as they have a public/private key structure.  If you have more than one, or just want to play with them, X509-based authentication is preferred.
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0
    Ok thanks Bob, I'll investigate.. We use a leased line via a managed router so It wouldn't be a PPPoE problem.  I didn't set this up so have no clue how it was setup I'll probably raise a ticket with rackspace to find out and see about changing it.
Unfiltered HTML