[2.830][BUG] Device lost connection to ACC

Hi,
I have one out of 48 devices which lost the connection to my ACC. In the ACC it's shown as offline.

In the device agent logfile I get the following lines repeated:

2011:06:17-08:47:43 firewall-1 device-agent[7891]: 1 is not connected. Trying to connect
2011:06:17-08:47:43 firewall-1 device-agent[7891]: [1] Connecting to ACC socket (ip=212.*.*.*, port=4433).
2011:06:17-08:47:48 firewall-1 device-agent[7891]: [1] ACC connection failure, retrying (ip=212.*.*.*, port=4433). SSL-connect: 'IO::Socket::INET configuration failederror:00000000:lib(0):func(0):reason(0)'
2011:06:17-08:47:54 firewall-1 device-agent[7891]: [1] ACC connection failure, retrying (ip=212.*.*.*, port=4433). SSL-connect: 'IO::Socket::INET configuration failederror:00000000:lib(0):func(0):reason(0)'
2011:06:17-08:47:55 firewall-1 device-agent[7891]: [1] Connection failed (ip=212.*.*.*, port=4433).
2011:06:17-08:47:55 firewall-1 device-agent[7891]: Not reporting inotify: no role
2011:06:17-08:47:55 firewall-1 device-agent[7891]: Not reporting inotify: no role
2011:06:17-08:47:55 firewall-1 device-agent[7891]: Not reporting inotify: no role
2011:06:17-08:47:55 firewall-1 device-agent[7891]: Not reporting inotify: no role
2011:06:17-08:47:55 firewall-1 device-agent[7891]: Not reporting inotify: no role
2011:06:17-08:47:55 firewall-1 device-agent[7891]: Not reporting inotify: no role
2011:06:17-08:47:55 firewall-1 device-agent[7891]: timer2 -> module 1 not executing: denied by role
2011:06:17-08:47:55 firewall-1 device-agent[7891]: timer2 -> module 2 not executing: denied by role
2011:06:17-08:47:55 firewall-1 device-agent[7891]: timer2 -> module 3 not executing: denied by role
2011:06:17-08:47:55 firewall-1 device-agent[7891]: timer2 -> module 4 not executing: denied by role
2011:06:17-08:47:55 firewall-1 device-agent[7891]: timer2 -> module 5 not executing: denied by role
2011:06:17-08:47:55 firewall-1 device-agent[7891]: timer2 -> module 6 not executing: denied by role
2011:06:17-08:47:55 firewall-1 device-agent[7891]: timer2 -> module 7 not executing: denied by role 


The ASG runs firmware 8.103.

Mario
  • In my Beta 3 Gateway manager I have 31 devices registered.  Of these there is a mixture of 7.5 and 8.1 gateways.  I did not import my previous setup but created a new ACC environment.
    Since commencing 19 of these devices now show that they do not connect (majority are v8 devices).  These 19 machines are contactable via normal web admin.   It appears that when a connection fails, the ACC or the device has trouble reestablishing the connection.  I had hoped that this issue which was prevalent with 2.2 would have been addressed in this 3 beta release.
    If a login or provision of logs would help, I am happy to provide.
  • Hi Mario, hi Bob,

    do you have an ASG in front of your ACC? If so it is possible that this ASG blocks the packets from the remote ASGs.

    See here.

    Regards, Hakan
  • Hi Hakan,

    Yes, we do have an Astaro in front of our ACC.  I will go through checking the logs, however I notice that the primary problem is for 8.1 gateways, not for 7.5

    Of the 21 8.1 gateways, 17 have connection problems (of the balance, 2 are internal and two I've reconnected today).  Of the 10 7.5 gateways, 9 are up and one is actually down.  

    Unless there are different strings in the connections being made between the 8.1 and 7.5 gateways to the ACC, I would have expected that all would suffer equally if an IPS problem?
  • Hi Bob,


    Unless there are different strings in the connections being made between the 8.1 and 7.5 gateways to the ACC, I would have expected that all would suffer equally if an IPS problem?


    IMHO not necessarily.

    You could also check whether you had that problem by searching for the string "SSL handshake timeout, closing connection" in your accd log files, i.e. /var/log/accd.log or the archived logs under /var/log/accd.

    If you find it then it is a strong indicator that you had the blocking problem.

    Regards, Hakan
  • Hi Hakan,

    Sorry for the travel caused delay in responding.

    We've checked our logs and cannot find the string "SSL handshake timeout" in our accd.log. 
    The size of accd.log in remote ASG is 0 since May. All files in archive are 0. 
    I also cannot find the blocking in packetfilter.log for our ip 192.168.200.48 in our ASG 

    It strikes me a strange as when I restart the accd through web admin of the remote gateway, it will connect, and then stay up for sometimes up to a day before failing, and then at that point it is unsuccessful at reconnecting.

    Also as previously mentioned, the problems are with 8.1 gateways, not 7.5
    regards

    Robert
  • Hi Robert,

    it seems that you have encountered another problem. I think it would be the most helpful if you could provide us with ssh access to the ACC when the issue happens again. I'm going to send you a pm.

    Regards, Hakan
  • We have encountered the same problem as  topicstartrer.
    Have you solved it and how?
  • Hi Undel,

    did you put your ASGs networks to the allowed networks under
    Management -> Gateway Manager -> Device Security in the webadmin
    of your ACC?

    If so, could you please login per ssh to your ACC and grep for WARN and ERROR
    entries in /var/log/accd.log.

    Please also check whether there are tcp connections to your ASGs:
    lsof -p `pidof accd` | grep TCP


    Please also check this with tcpdump:
    tcpdump -i eth0 port 4433


    Regards, Hakan
  • tcpdump on affected ASGs shows that no packets are actually sent to ACC from these ASGs.
    So, ACC logs are clear as there are no packets being transmitted.
  • have you also ensured what I asked you first:

    did you put your ASGs networks to the allowed networks under
    Management -> Gateway Manager -> Device Security in the webadmin
    of your ACC?