Can't connect to remote ASG WebAdmin

You are right, the documentation is not describing the fact that a Webadmin session initiated via the ACCs "Open Webadmin sessioN" feature is requiring the exactly same settings like you would have to make when opening the Webadmin session directly from the admin PC where you connected to the ACC.

With other words: the fact that an ASG is conencted to the ACC (and you can see the status and other information of the ASG in the ACC, and even can trigger maintenance functions like install a firmware up2date  or so) does NOT have any influence on the ability to connect via WebAdmin to the ASG.
When you press the "Webadmin" button inside ACC to make an "SSO Webadmin connection" to the selected ASG, a new browser windows comes up which connect to the remotre ASG´s externa address - exactly like if you would have opened a windows manually on your own.

Yes, configuring "Allowed Networks" for the ASG WebAdmin is not something you do every day and therefore it gets 'forgotten'.... as a matter of fact, I believe "Internal [LAN] (Network)" is the default setting therefore it really isn't ever modified except when someone attempts to install and run ACC!

This is my first attempt at using ACC.
Astaro ROCKS and so does the ACC.... I dumped Untangle almost 2 years ago for Astaro!!

I guess that was a dig????  Not sure.

Sorry I am not an English native speaker - don´t understand what you mean with "that was a dig" ?
 

 Yes I realize it was a 'stupid' mistake, ...

Not at all stupid!
What I wanted to say is that it it REALLY not described very good in the manual what happens if you press the "Webadmin" button in ACC. Many people (me too in the beginning) thought that the ACC would make a connection to the ASG. It is not clear for many people that in deed, it is the administrators PCs (not the ACC machine!) which makes the connection to the destination ASG.
This behaviour leads to several problems in the real life, so many people have had the problematic behaviour you have experienced, too!

I apologize for my remarks.... I misunderstood what you were saying.
A 'Dig' is generally making fun of someone for making a stupid mistake.  (Me in this case)

As soon as BAlfson asked about the "Allowed networks" on the Remote ASG, it hit me that that was the problem.  I do have to admit that I did think it was ACC establishing the connection... you explained what was actually happening very well!

Thanks for your input

Ok... I'm at a loss now!
I had the Remote ASG reconfigured and added my Public IP in allowed networks for WebAdmin but still cannot connect.

Do I need to create a packet filter rule, on the remote ASG, to allow Port 4444 Traffic from my public IP to the Inetrnal (LAN) Address as well?

Hi,

first of all I would like to thank you all for initiating this discussion and for pointing out that the WebAdmin SSO feature needs some additional explanation in the manuals and online-help.

You have described it well - the ACC does NOT(!) act as a reverse proxy or tunnel to the remote AxG WebAdmin. Hence, if you are able to reach the remote AxG WebAdmin manually via your administrative machine, chances are, that SSO with auto-login will work as well.

@jcargile: 

Regarding your last question. You do not need to create any incoming packet-filter rules for WebAdmin traffic on the remote AxG itself if you add your public/incoming IP address or range to the allowed networks. This will implicitly create all necessary packet-filter rules in the AUTO_INPUT chain, taking precedence over any user-defined DROP rules. 

What you need to manually adjust are any potential intermediary AxG or other firewalls which might block traffic to the remote's AxG WebAdmin port. For instance, your local AxG must forward the traffic from your local network to the remote AxG correctly. Can you check the packet-filter logfile of your local AxG for that purpose? Probably you need to reflect the configuration change of your remote AxG in the local AxG.

Regards,
Henning

Hi,

first of all I would like to thank you all for initiating this discussion and for pointing out that the WebAdmin SSO feature needs some additional explanation in the manuals and online-help.

You have described it well - the ACC does NOT(!) act as a reverse proxy or tunnel to the remote AxG WebAdmin. Hence, if you are able to reach the remote AxG WebAdmin manually via your administrative machine, chances are, that SSO with auto-login will work as well.

@jcargile: 

Regarding your last question. You do not need to create any incoming packet-filter rules for WebAdmin traffic on the remote AxG itself if you add your public/incoming IP address or range to the allowed networks. This will implicitly create all necessary packet-filter rules in the AUTO_INPUT chain, taking precedence over any user-defined DROP rules. 

What you need to manually adjust are any potential intermediary AxG or other firewalls which might block traffic to the remote's AxG WebAdmin port. For instance, your local AxG must forward the traffic from your local network to the remote AxG correctly. Can you check the packet-filter logfile of your local AxG for that purpose? Probably you need to reflect the configuration change of your remote AxG in the local AxG.

Regards,
Henning

Ok.... starting to make a little more sense now but still no success!

I noticed that traffic from my internal IP address to the public IP of the remote ASG was being dropped locally.  I created a local packet filter to allow WebAdmin traffic from my PC (192.168.16.x) through the WebAdmin Service (Port 4444) to the remote ASG's Public IP (96.8.21.x).

This let my WebAdmin traffic out but I still cannot connect to the Remote ASG.

Here are some specifics about the systems:
1.  Both Local and Remote ASG's are Firewall/Router/DHCP servers connected directly to modem/fiber.
2.  Local ASG private IP range is NOT the same subnet as the remote AGS's range.
3.  Local and Remote ASG's Public IP's are dynamic.

By the way....
I was stationed at Coleman Army Airfield in Mannheim back in the early 80's and we had a detachment in Karlsruhe.  I really loved it there!

Hi,

your local traffic originating with an RFC1918 address (192.168.16.x) from your admin box is masqueraded by your local ASG's public address, otherwise your traffic could not be routed through the Internet. In order to allow you to access the WebAdmin on the remote ASG, you need to do two things:

1) allow your local traffic to the remote ASG's WebAdmin to pass through your local ASG (you are more or less done with that one)
2) add the public IP of your local ASG to the allowed networks for WebAdmin of the remote ASG (maybe you have forgotten to do this?)

Remote ASG configuration

As the public IP of your local ASG is dynamic, you should add a DNS host object to the allowed networks in your remote ASG to automatically reflect any changes. This of course requires, that you have some kind of (dynamic) DNS configured.

Local ASG configuration "improvement"

Also, to alleviate you from the burden to adjust the forward rule on your local ASG, you should use a DNS host object within the packet-filter rule for the remote ASG, instead of using the IP address directly.

Using DNS

So, what you need in order for this to work is having two (dynamic) DNS entries for your ASG boxes.

About Mannheim

I am not originally from Baden-Wuerttemberg but I know the 80s and was chasing M1A2 tanks for MREs as a kid. Opinions are diverse regarding Mannheim, none of which I am at the liberty to discuss here [:D] 

Hope you get the stuff working - please don't hesitate to post again.

Regards from R&D,
Henning