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

Cannot get remote sites connected to Command Center

Hello

We have numerous security gateways SSL vpn'd into a main security gateway.  On the same network as the main security gateway we have a command center running.  The remote devices are located behind third party firewalls, but we do have a full SSL tunnel connection to the devices.

Here is the issue we're having.  The following message appears on all of the remote devices in the log when you try to enable centralized management.  The main security gateway connects fine to the command center.


2009:04:19-22:56:13 r1004 device-agent[18380]: ACC connection failure, retrying (ip=10.30.100.170, port=4433). SSL-connect: 'IO::Socket::INET configuration failederror:00000000:lib(0):func(0):reason(0)' 
2009:04:19-22:56:23 r1004 device-agent[18380]: ACC connection failure, retrying (ip=10.30.100.170, port=4433). SSL-connect: 'IO::Socket::INET configuration failederror:00000000:lib(0):func(0):reason(0)' 


From a device on a remote network I can access without any issue and vice versa

https://10.30.100.170:4433
https://10.30.100.170:4422
https://10.30.100.170:4444

I have checked the packet filter logs, and just about everything else I can think of.  

Does the command center work only when it is the gateway connected to a the wan on the remote network?  Or will it work through an SSL tunnel?

Thank you in advance


This thread was automatically locked due to age.
  • I solved this by specifying an external IP instead of trying to manage devices over VPN.
  • Hi,

    basically, tunneling should be possible regardless of whether you are using an SSL or IPSec VPN. The issue is probably that the packets from the device-agent on your remote devices are not routed into the SSL-VPN tunnel because the source IP will be out of the tunnel scope.

    You can alternatively hide the ACC behind your central firewall and make it accessible to the outside world via DNAT/port-forwarding.

    Regards,
    Henning