Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 16 replies
  • Subscribers 1 subscriber
  • Views 11298 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 Not Loading

claymen
Hey all,

I've recently done a fresh UTM 9 install into my VMWare environment and run into an issue with the IPSec VPN for a site to site link.

I'm using certificate based IPSec due to a dynamic IP on one end, the VPN tunnel came up ok last night and was working this morning till some the service's IP changed. I fixed up the dyndns on the remote end and the tunnel came up ok but then dropped after a few minutes. Looking in the Astaro logs it simply said that pluto had shut down.

I turned that tunnel off and on via both the Astaro and the remote end (note that the remote end is servicing other IPSec tunnels without issue) and recreated the configuration on the Astaro end and it just doesn't do anything. Nothing comes up in the IPSec logs.

Tried a restart of the unit and again nothing started up. My final solution was to roll back to an earlier config and reboot which brought it online. However the same issue has happened again which doesn't make any sense. Nothing appears in the logs and it just doesn't start the tunnel.

It doesn't even list it as trying within the interface (Site to Site VPN main heading). It simply lists "There is no Site-to-site VPN status information available". When it was down this morning at least it showed that there was a tunnel there but down.

Has anyone come across this? I really don't want to have to keep restoring the config and rebooting to fix it but I am a little confused as to why it is failing in this way.


This thread was automatically locked due to age.
  • 0
    Here is the log just before it fails.

    You can see it connect then just stop and that's it no more IPSec.

    2012:07:28-12:47:34 beer pluto[8141]: "S_company" #1: initiating Main Mode
    2012:07:28-12:47:34 beer pluto[8141]: "S_company" #1: ignoring Vendor ID payload [5b362bc820f60007]
    2012:07:28-12:47:34 beer pluto[8141]: "S_company" #1: received Vendor ID payload [RFC 3947]
    2012:07:28-12:47:34 beer pluto[8141]: "S_company" #1: enabling possible NAT-traversal with method 3
    2012:07:28-12:47:34 beer pluto[8141]: "S_company" #1: ignoring Vendor ID payload [404bf439522ca3f6]
    2012:07:28-12:47:34 beer pluto[8141]: "S_company" #1: received Vendor ID payload [Dead Peer Detection]
    2012:07:28-12:47:34 beer pluto[8141]: "S_company" #1: NAT-Traversal: Result using RFC 3947: no NAT detected
    2012:07:28-12:47:34 beer pluto[8141]: "S_company" #1: we have a cert and are sending it
    2012:07:28-12:47:34 beer pluto[8141]: "S_company" #1: ignoring informational payload, type IPSEC_INITIAL_CONTACT
    2012:07:28-12:47:34 beer pluto[8141]: "S_company" #1: Peer ID is ID_USER_FQDN: 'support@company.com.au'
    2012:07:28-12:47:34 beer pluto[8141]: "S_company" #1: crl not found
    2012:07:28-12:47:34 beer pluto[8141]: "S_company" #1: certificate status unknown
    2012:07:28-12:47:34 beer pluto[8141]: "S_company" #1: Dead Peer Detection (RFC 3706) enabled
    2012:07:28-12:47:34 beer pluto[8141]: "S_company" #1: ISAKMP SA established
    2012:07:28-12:47:34 beer pluto[8141]: "S_company" #2: initiating Quick Mode PUBKEY+ENCRYPT+TUNNEL+UP {using isakmp#1}
    2012:07:28-12:47:34 beer pluto[8141]: "S_company" #2: sent QI2, IPsec SA established {ESP=>0xd0d9dd9c 
  • 0
    Hi, Clay, and welcome to the User BB!

    The first thing to do when anything strange occcurs is to check the Intrusion Prevention log to see if anything triggered IPS or Anti-DoS Flooding.

    I'm a little confused by "keep restoring the config and rebooting to fix it" - does that mean the problem does not re-occur after a restore/reboot?  What change do you then make that results in "shutting down" the tunnel after "IPsec SA established?"

    Is either endpoint behind a NATting router of some sort?  Are NAT-T and Dead-Peer-Detection enabled on both ends?

    Cheers - Bob
  • 0
    IPS is turned off at this stage and nothing in there at all.

    Basically I can restore my config to the automatic backup at 1am before it went strange and it works for a short period then stops. When I was initially testing I thought it was a change I had made as I was working on some firewall rules and adjusting dyndns hence rolling it back initially. However when it happened again I started to get a little concerned.

    In that log excerpt I posted there was no change made between starting the IPSec tunnel and it closing. I restored the config to the known working backup, started the tunnel and then watched it connect then drop and no longer able to start again.

    Neither endpoint are NAT'd although NAT is in use. E.g. clients behind the firewalls at each end are NAT'd but the firewalls them selves where the IPSec tunnel is have direct access to the net given they have the WAN IP on an interface.

    Dead-peer detection is enabled on both ends. But have tested with it off.

    In it's broken state I can go into Site-to-Site VPN -> IPSec and turn on the tunnel and nothing will happen in the IPSec live log.
  • 0
    This morning I did a backup of my current config and restored to a new instance of the VMWare appliance and it resulted in the same issue, tunnel just doesn't start and nothing loads in the IPSec live log at all.
  • 0
    In that log excerpt I posted there was no change made between starting the IPSec tunnel and it closing. I restored the config to the known working backup, started the tunnel and then watched it connect then drop and no longer able to start again.

    I'm still confused by that.  After restoring the "known working backup," are any changes made?

    Cheers - Bob
  • 0
    No.

    Here's step by step
    * Restore from backup
    * Reboot the Astaro
    * Enable the IPsec tunnel
    * Watch the tunnel come up in the live log then stop shortly after

    From here I have proceeded to test starting and stopping it to try and restart it, rebooting etc and nothing seems to bring it back to life. The live log does not show any updates and it does not appear to start the pluto/ipsec starter processes at all.
  • 0
    I originally had been making changes hence I had thought it was a change in the firewall or one of the numerous settings I was working on at the time which could have caused it. Rolling back to the backup was to eliminate those changes as being the cause however it still fails.

    I am suspecting something in the config is corrupt/broken which leads to the problem however to redo the entire config from scratch would be a pain.
  • 0
    If this was working correctly before and you haven't made any changes, then that leaves hardware problems on the two devices or anything in between, and configuration changes outside the Astaro.

    Can you get confirmation that there were no configuration changes on the other device and that IPs are unchanged?  If so, then you might try creating a new V9 VM, or even going back to a V8.3 VM.

    Did either of those work?  Maybe you'll want to have your reseller submit a support request before even trying the new VMs.

    Cheers - Bob
  • 0
    Tried two VM's already [;)]

    First one was an iso install into the VM, second was loading the vm appliance itself.

    I've not as yet tested restoring the original backup which was confirmed working to see if it fails again. However I have tested the current backup which shows the same issues. This is what leads me to believe its a corrupt config.
  • 0
    It's recommended to NOT use the VM appliance ISO.  Also, what virtual NIC do you have configured for the External interface? VMXNET3 and e1000 are what folks have found to work.

    Cheers - Bob