Hello all, I'm hoping someone can help me with this.
I have a local network, let's say 192.168.0.0/24 with an ASG v7.306 at 192.168.0.1 and a public IP of zzz.zzz.zzz.zzz. I've set up ACC at 192.168.0.2. I successfully have the ACC v2.0 monitoring the local ASG at 192.168.0.1. I would like to monitor an ASG v7.306 at a remote location with a local network of 192.168.50.0/24 and a public IP of yyy.yyy.yyy.yyy. I do not have a VPN connection between the two networks.

Here is what I've done:

On the ACC (192.168.0.2):

• Set The Allowed Networks for Access Control and Device Security to "Any"

On the local ASG (192.168.0.1, public zzz.zzz.zzz.zzz):

• Created a DNAT rule:
  • Any -> dstport 4433 -> zzz.zzz.zzz.zzz
  • Destination: 192.168.0.2
  • Do not auto packet filter
• Created a Packet Filter rule:
  • Any -> dstport 4433 -> 192.168.0.2
  • Allow, Log

Note: I initially had the DNAT rule auto packet filter enabled, but had the same issues... so I turned off auto packet filtering and created the rule manually.

On the Remote ASG (192.168.50.1, public yyy.yyy.yyy.yyy):

• Under Central Management:
  • Set to ACC v1.9 (no option for v2.0)
  • Set the ACC host to zzz.zzz.zzz.zzz

Here is my problem:

On the Remote ASG the ACC health connection is not connected. My Live Log keeps spitting out:

2009:05:14-13:22:46 (none) device-agent[3098]: ACC connection failure, retrying (ip=zzz.zzz.zzz.zzz, port=4433). SSL-connect: 'IO::Socket::INET configuration failederror:00000000:lib(0):func(0):reason(0)'

In the packet filter log on my local ASG (192.168.0.1, zzz.zzz.zzz.zzz) I can see packets being allowed on port 4433 from yyy.yyy.yyy.yyy to 192.168.0.2. Yet the connection is never made. Have I missed something?

Thanks,
Lane

I believe I've found the problem. When logging into the ACC (192.168.0.2) and looking at the Packet Filter log I see several entries for:

2009:05:14-19:13:19 HOSTNAME ulogd[3146]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" seq="0" initf="eth0" outitf="eth0" dstmac="xx:xx:xx:xx:xx:xx" srcmac="00:00:00:00:00:00" srcip="yyy.yyy.yyy.yyy" dstip="192.168.0.2" proto="6" length="60" tos="0x00" prec="0x00" ttl="63" srcport="40092" dstport="4433" tcpflags="SYN"

I double checked and I have the settings under gateway management to allow "Any" for the networks both for access control and device security. The ACC WebAdmin doesn't have anywhere where I can set up a rule to accept these packets. Do I have to SSH and add the entry manually?

***UPDATE***

I've switched the "Allowed Networks" in the Device Security tab of the ACC to the individual hosts instead of "Any". I am not getting any blocked packets in the packet filter on the ACC. I believe the entries in the packet filter mentioned above were from when I was changing the Allowed Hosts. So I still do not know what the problem is. Help?


***UPDATE AGAIN***

Problem Solved

After some troubleshooting with WireShark I could see that the ACC was receiving the SYN packets from the remote ASG but no ACK packets were being sent back. Tried to ping the remote ASG from the ACC, no response.

Here's what I did wrong:

On my ACC I had configured the internal interface with the IP address 192.168.0.2, subnet 255.255.255.0, and a gateway of 192.168.0.1. The problem was I didn't have a check in the box for Default Gateway. Once that was checked everything worked fine. That's embarassing.

Wow,

that was a very nice and impressive report and you managed all the debugging by yourself in a short time - basically leaving nobody a change to help you out ;-)

Glad that everything is working now.

BTW: Regarding the ACC V1.9 and missing ACC V2 option in the AxG WebAdmin Central Management Settings. It is perfectly alright, the ACC 1.9 setting is also valid for ACC V2. We will introduce a cosmetic adjustment in a future release, so this becomes more clear.

Thanks and regards,
Henning

__________________
"Molest me not with this pocket calculator stuff."

Thanks for the great blow by blow. I have been banging my head for days and I ended up doing the same thing.

Actually, the whole procedure of setting up an ACC behind a local AxG and making it accessible to other remote AxG is depicted in the manuals delivered with ACC ...

__________________
"Molest me not with this pocket calculator stuff."