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

[BUG 7.40x] IPSec Site-to-Site VPNs don't reconnect on reboot

BarryG
Continuing the thread here, previously at 
https://community.sophos.com/products/unified-threat-management/astaroorg/f/52/t/26962
and
https://community.sophos.com/products/unified-threat-management/astaroorg/f/95/t/67381
and with support: Ticket #2009042810000389 / CaseID 00096160


 BarryG,

thanks for the logfiles and sorry for the delay. The problem you're referring to is not connected to the fix we already shipped in 7.402 and not connected to any patch included in 7.403, though. I'll need to do some guessing what could cause your problem and what could help here:

If IpsecN interface is reported as missing, there is usually a part of the configuration missing. If a part of the configuration is missing, usually one (or more) of the parameters are not present. This could i.e. mean you use a DNS definition in your IPsec connection and at the point of starting IPsec the DNS name is not resolved yet. As an alternative, the (dynamic?) interface might not be up and running at that point. Usually this should 'fix itself' once the missing part is resolved or up - but in your case this seems not to happen.

Finding the problem:
- Please make a copy of the file /var/chroot-ipsec/etc/ipsec.conf when the system is up and running.

In case this happens again, please try the following:
- check /var/chroot-ipsec/etc/ipsec.conf against the version which was ok
- check in WebAdmin if some definitions used there (e.g. interfaces, DNS hosts, ..) are unresolved
- check if pluto is running or currently being restarted i.e. by selfmon
- check if a confd restart on the shell solves your problem

I apologize for obviously not matching your problem with our fix in 7.402/7.403 and look forward to resolving that one as soon as possible.

Regards,
Marcel



I'll reboot in a few minutes and compare the files.

My remote connections are to static IP definitions, however.
The only thing that is dynamic is my internet connection at home (DHCP Fiber), but my IP doesn't change frequently, even across quick reboots.

Thanks,
Barry


This thread was automatically locked due to age.
  • 0
    Also should mention that my home firewall is set to initiate, and the remote is respond only.

    Just rebooted home... VPN is down...
    diff'ing the old ipsec.conf vs the new one shows no difference and they both have the same md5sum

    as mentioned, not using any dynamic definitions for the connection, other than the DHCP external interface, which is UP


    # ps auxw |grep pluto
    root      3559  0.0  0.3   4464  1692 ?        Ss   15:29   0:00 /usr/libexec/ipsec/pluto --nofork --debug-none --nocrsend --nat_traversal --keep_alive 60
    root      3567  0.0  0.0   1460   300 ?        S    15:29   0:00 _pluto_adns


    /etc/init.d/confdaemon restart
    killed my internet connection for a minute, but the VPNs are still down.

    Thanks,
    Barry
  • 0 in reply to BarryG
    BarryG,

    after reading the whole thread again, I must admit that it seems I was wrong with my initial diagnosis. 'IpsecN interface missing' is not a message which shows up in case one parameter is missing/unresolved. (in that case middleware would simply skip that connection when writing the ipsec.conf)

    After rebooting your machine your Internet connection is (usually) directly up and running, correct? Can you check if the underlying eth interface is completetly up when the IPsecN message appears?

    Regards,
    Marcel
  • 0 in reply to Marcel_01
    BarryG,

    as I understand you're using DHCP/Cable modem for Internet access you can also upgrade your system to (soft-released) 7.404 and check results again.

    Best regards,
    Marcel
  • 0 in reply to Marcel_01
    Yes, try 7.404 ... that appears to address the issue.