Can't connect to ACC

ok i solved the problem with DNAT

Hi,

with the upcoming ASG V7.1 and current beta you can easily have a DNAT with a fitting packet-filter. Reaching your ACC from your outside devices has never been so easy ;-)

Cheers

I installed ACC on the Internal LAN side of my 425(hub) after having issues with my 120/220 units(spokes) receiving up2dates. I have multiple remote 120/220 units configured to use this ACC. I can't receive updates. 

What may be unique in my configuration is I have my remote sites sending 'any' traffic over the VPN's to the 425. When on v7.101, static routes to the up2date servers did the trick. We upgraded to v7.104, which for some reason, can't get up2dates over the static routes anymore.

I've tried confirming all open ports to and from the ACC over the VPN. I've also confirmed the ACC isn't being packet filtered out the 425's internet connection. I've tried using SNAT/DNAT without luck. Up2date logs on the 120/220 units show authentication successful to the up2date servers. All units report into the ACC. Any tips and tricks here other than confirming routing, packet filter rules, SNAT/DNAT?

No One can seem to figure this one out. Astaro support basically dropped the challenge on making this work with our configuration. Our configuration is 20 or so Astaro's connecting to an Astaro 425 in a Hub and Spoke config. All traffic via IPSEC VPN is sent over the tunnel to the 425(Hub). You'd think SNAT rules on the remote sites attempting to contact the ACC or even the update servers would do the trick. I can't find entries in the packet filter logs indicating dropped packets. Yet I have 20+ Astaro's that haven't received updates since the update from 7.101 to 7.104. Our originial solution provided by Astaro support, which was static routes to the DG for the update servers were working fine until the 7.104 update. Are we the only site sending all traffic over IPSEC VPN's to a traffic cop Astaro, and having this issue?

Hi,

this is not an ACC related issue but a more general network infrastructure question. I am not sure that the traffic from the ASG device-agent(s) really goes through the VPN tunnels. Can you verify this first?

If the traffic really passes through the tunnel than you would have to include the ACC network definition into the Hub VPN network scope.

Cheers,
Henning

Thanks for the reply MP. I believe you are right in that it's either a routing or packet filter issue. The problem is I'm having trouble finding the dropped packets or routes in the logs to determine the point of failure. 

The ACC is on our Internal on eth0 behind our Hub, a 425. We are using transparent mode for http proxy, but the ACC is set in web security/http/advanced/Skip transparent mode hosts/nets.

Our other 20 Astaros have 1 IPsec tunnel to this 425. Remote gateway, remote networks from the remotes to the 425 are set to Any. This sends all traffic from the remotes to the 425. The 425 remote gateway/remote networks is set to each LAN subnet for the remote Astaros.

We have a SNAT setup for traffic to the 425 LAN, from External IP, NAT to Internal IP. We've set auto packet filter for the IPSEC tunnels, assuming that allows all traffic over the tunnel.

What I'm seeing in the packet filter log on the 425, which is the gateway for all traffic, is a SYN packet sent from our ACC server to the update servers on 443, and no SYNACK return, or at least I can't find one in the logs. Shows a few SYN attempts, then a ACKFIN. 

What would be hugely helpful is the steps taken by the ACC during the communication process. What is the communication steps from beginning to end on a successful communication from a remote astaro using ACC as an update cache server including the ports used?

Thanks again for the help. [:)]

Hi,

here are the steps to the best of my knowledge:

1. Speedtest

The remote ASG will try to deduce the fastest Up2Date Server by doing a netselect lookup first. It uses the same UDP port range as for tracerouting. This will be skipped when using the Up2Date Cache on the ACC. In this case a random Up2Date Server should be picked.

2. Authentication

The remote ASG sends an HTTPS (port 443) authentication request to the Up2Date Server. In case of the ACC being used as an Up2Date Cache the HTTPS request will be send to the ACC instead. The ACC Up2Date Cache will then try to connect to the Up2Date Server via HTTPS (port 443).

3. Bulk Retrieval

If authentication was successful the remote ASG will try to retrieve actual packages. It sends one or more HTTP (port 80) bulk transfer requests. In case of ACC being used as an Up2Date Cache the request will be directed to the ACC instead. The ACC will check if it already has cached the item in question, otherwise it tries to retrieve it from the Up2Date Server.

I guess the HTTPS requests from inside of your network (from the ACC) to the Up2Date Servers do not make it back (NAT issue?). Have you tried configuring the ASG 425 as an Parent/Upstream Proxy for the ACC to use and disable the skip list entry? Although the ASG HTTP Proxy runs transparently you should still be able to use it directly - maybe via another profile.

Cheers

Thanks Megaposer. I will look into trying your suggestions. That is some great info there.