ACC 2.0 decalres all ASGs as offline

Hi Markus,

thanks for your report.

It seems very unlikely that this has something to do with the 7.402 Up2Date.

Have you checked that basic connectivity from/to the ACC is working correctly - if all devices are marked as offline it seems that they might be loosing their connection or are suddenly blocked.

Do the machines stay offline but you can still operate/navigate within the Gateway Manager GUI?

Maybe you could post some logfile excerpts from the ACC or send them to acc-support@astaro.com - we can then have a look at it. These are the files we would require:

/var/log/accd.log
/var/log/selfmon.log

Regards,
Henning

[QUOTE=megaposer;109626]Maybe you could post some logfile excerpts from the ACC or send them to acc-support@astaro.com - we can then have a look at it. These are the files we would require:

/var/log/accd.log

/var/log/selfmon.log

Hi Henning,
I attached the "ACC Daemon" and "SelfMon" logs of the entire last week. Connectivity in principle seems to be OK as it is fine after an ACC reboot.
I also found a packet filter log in the ACC, but no packet filter where I could allow or block anything.
I can browse the gateway manager, but when a machine is declared offline I can of course not connect to the web admin through tis console ("Device is not ONLINE.")

Hi Markus,

we are under the impression that there is some kind of connection problem.

Maybe you could try out the following on one of the "pseudo-offline" ASGs, as soon as it is marked offline in the ACC:

# ssl_fetch_certificate.plx --server $YOUR_ACC_IP$ --port 4433

This should return the ACC host certificate via an SSL connection. If that does not work, we need to check the following logfile on the ASG:

/var/log/device-agent.log

Maybe you could also have a look into the System Logfile on the ACC and check whether it shows any errors/problems with NICs in the system:

/var/log/system.log

Ultimately, you can provide us with access to the ACC and one of the offline ASGs.

Regards,
Henning

Hi Markus,

we are under the impression that there is some kind of connection problem.

Maybe you could try out the following on one of the "pseudo-offline" ASGs, as soon as it is marked offline in the ACC:

# ssl_fetch_certificate.plx --server $YOUR_ACC_IP$ --port 4433

This should return the ACC host certificate via an SSL connection. If that does not work, we need to check the following logfile on the ASG:

/var/log/device-agent.log

Maybe you could also have a look into the System Logfile on the ACC and check whether it shows any errors/problems with NICs in the system:

/var/log/system.log

Ultimately, you can provide us with access to the ACC and one of the offline ASGs.

Regards,
Henning

Thanks again Henning,
but I solved the problem in a different way. The ACC now does no longer sit behind one ASG which the others have to go through. Although all rules were OK and ping worked fine between the machines some still didn't want to connect again. However. 
Now the ACC machine sits "beside" a ASG on the WAN side and everything is looking fine.

Hi Markus,

good to hear - did you have DNAT/Port-Forwarding setup correctly on the shielding ASG in your previous setup? AFAIK, ping forwarding might have been enabled, but you did you have a DNAT rule from your external ASG interface IP to your internal ACC IP address?

Cheers,
Henning