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

AxG 7.403 Soft Release

Greetings,

We will now release the V7.403 Up2date using a new "Soft Release" process. The Up2Date will be mass-published to our Up2Date infrastructure on Monday, June 8th[/b]. At that time we'll officially put it on the http://up2date.astaro.com blog.

Astaros Up2Date packages are usually made available via an existing Up2Date infrastructure. This infrastructure serves all existing AxG (Security, Web & Mail Gateways) products with one identical package per version. Now, all the packages will get uploaded to Astaros main FTP server and transferred to various FTP mirrors around the world. Releasing via Up2Date infrastructure and FTP server has been done simultaneously in the past. We are releasing this on the UBB Forums so a small group of people who are awaiting the fixes or like to be first can install it immediately. 

Interested customers get the chance to get involved and provide direct feedback. In the unlikely event of an issue with an Up2Date package as a result of experiences or comments here, we'll adjust as needed. This Up2Date is considered final and not Beta, thus no issues are expected. 

Up2Date 7.403 Details

German FTP Site (Main)
ftp://ftp.astaro.de/pub/ASG/v7/up2date/u2d-sys-7.403.tgz.gpg
US FTP Site
ftp://ftp.astaro.com/pub/ASG/v7/up2date/u2d-sys-7.403.tgz.gpg

This is a progressive release designed to enhance the quality and stability of your Astaro installation. 
-Up2Date Size: 72.3 MB (75824146 bytes)
-Md5sum: 02c28e8558275d31347cf148a5ba4c50

Remarks:
Configuration will not be changed
System will be rebooted

News:
Added support for new Up2Date servers

Bugfixes:
Fix [10015]: Active content removal not working correctly 
Fix [10139]: Unable to download, clear, or delete log files 
Fix [10233]: Regenerating the Signing CA might cause problems 
Fix [10284]: Uplink interface not showing up sometimes 
Fix [10323]: High-Availability logfile filling up quickly 
Fix [10324]: Possible db sync problem on HA nodes 
Fix [10339]: Slave nodes keeps UP2DATE state after manual action 
Fix [10355]: Problem reinitializing tunnels after HA takeover 
Fix [10360]: Exception list can not be created for Share 
Fix [10361]: File Extensions missing from Filter Action page 
Fix [10391]: POP3 prefetch fails at long MIME-encoded subjects 
Fix [10409]: Web Security reports not visible for auditors 
Fix [10423]: Using proxy arp may cause loss of WebAdmin connectivity 
Fix [10426]: Importing license via wizard may not work correctly 
Fix [10441]: HTTP block action not working in all cases


Any comments or feedback is welcome here.
Regards,

Angelo


This thread was automatically locked due to age.
Parents
  • It's not mentioned in the list, but does anybody know if this below issue is fixed in 7.403? If not, is it already in 7.5 beta?

    https://community.sophos.com/products/unified-threat-management/astaroorg/f/95/t/67233
  • hi,

    after updating from 7.402 to 7.403 my astaro GUI sais, that our license has been expired. I tried to install the licenses again (e.g. astarolicense123456.txt), but always the same: Your license has expired.

    some ideas?

    thanks
    archie51
  • Check that the date is correct.  If you can't get into the WebAdmin, you might try restoring a configuration from yesterday.  If you have support, you might need to submit a support request.
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • archie51,

    I assume you're using a hardware appliance. If so, please check your /etc/asg file for the line ASG_SUBTYPE and in case it is set to "", please try changing to "none".

    Thanks,
    Marcel
  • BrucekConvergent & BarryG,

    just to make sure I understand it correctly: The 'VPN does not come up on boot' issue existed before 7.402 and was not fixed for you with 7.402? Do you have loglines like those in your log:

    2009:03:05-18:13:23 (none) pluto[4196]: "S_REF_fequDqurgs_0" 0000006: we don't have a cert
    2009:03:05-18:13:23 (none) pluto[4196]: "S_REF_fequDqurgs_0" 0000006: unable to locate my private key for RSA Signature

    Thanks,
    Marcel
  • I haven't had a chance to dig through any logs, but I can verify I have a couple of customers for whom IPSEC tunnels (astaro to astaro) do not always come up properly after a reboot... I have to manually disable the connection, then re-enable it.  All of my managed customers are running 7.402.

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

  • BrucekConvergent & BarryG,

    just to make sure I understand it correctly: The 'VPN does not come up on boot' issue existed before 7.402 and was not fixed for you with 7.402? Do you have loglines like those in your log:

    2009:03:05-18:13:23 (none) pluto[4196]: "S_REF_fequDqurgs_0" 0000006: we don't have a cert
    2009:03:05-18:13:23 (none) pluto[4196]: "S_REF_fequDqurgs_0" 0000006: unable to locate my private key for RSA Signature

    Thanks,
    Marcel


    Hi Marcel, sorry for the delayed reply.

    Yes, this has been going on for awhile in the 7.4 series, including the 7.395 beta... e.g.
    https://community.sophos.com/products/unified-threat-management/astaroorg/f/95/t/67381

    I posted logs to the URL above, and I believe I sent logs from awhile back to support under the aforementioned ticket. I can send current logs if that would help.

    On 7.402, I do NOT see the word 'unable' in any of my logs, nor "don't have".

    Thanks,
    Barry
  • ok, understood. I'd like to walk through a 7.402 ipsec logfile from a day a reboot happened. If BarryG or BrucekConvergent could either PM or email me one (mgehrlein at astaro dt com) would be great. Please add the rough time of the reboot as information if possible (otherwise just add the kernel log from that day, that will do the trick as well).

    Thanks a lot,
    Marcel
  • Email sent...

    I think the errors are in the form "we have no ipsecN interface for either end of this connection".

    Thanks,
    Barry
Reply Children
  • That sounds familiar...

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

  • 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
  • Thanks everyone for helping us with this new process. We just pushed 7.403 to the live servers (with a few tiny changes over the initial soft release that should prevent a few very rare issues), and as such we'll close and unstick this thread.

    Cheers,