Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 5 replies
  • Subscribers 1 subscriber
  • Views 1684 views
  • Users 0 members are here
Options
Suggested
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

Managing Remote ASG with ACC Behind Local ASG

Lane
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.  

[SIZE="3"]Here is what I've done:[/SIZE]

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



    [SIZE="3"]Here is my problem[/SIZE]:

    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


    This thread was automatically locked due to age.
    • 0
      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. [;)]
    • 0 in reply to Lane
      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
    • 0 in reply to megaposer
      Thanks for the great blow by blow.  I have been banging my head for days and I ended up doing the same thing.
    • 0 in reply to skydiver
      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 ...
    • 0
      haha.. same issue here.. can't believe it was something this dumb.. thanks man
    Unfiltered HTML