ASG connection to ACC = frustration

Yup, under Gateway Manager, have set all settings I can think of, including on the Device Security tab added Any and VPN Pool (SSL) to Allowed Networks.  I have also checked the Required Authentication option and added the Shared Secret password that I have set on all the ASGx units.

Yup, under Gateway Manager, have set all settings I can think of, including on the Device Security tab added Any and VPN Pool (SSL) to Allowed Networks.  I have also checked the Required Authentication option and added the Shared Secret password that I have set on all the ASGx units.

Should work... probably missing something simple.  Set logging to enabled on your NAT / Firewall rules on the ASG 1 box, and watch the live log when a remote ASG (that is failing to connect) tries to connect -- do you see the 4433 packets?  if not, check your firewall rules.  If so... check the ACC Device Agent log on the remote ASG, it will indicate what is going on.

Also, what platform are you running ACC V3 on?  If it's VMware, make sure you don't have any vShield stuff set to block the needed traffic (I've seen it done).

Also, what platform are you running ACC V3 on?  If it's VMware, make sure you don't have any vShield stuff set to block the needed traffic (I've seen it done).

My ACC is running on its own individual hardware; mini-itx Atom-D525 system.

Should work... probably missing something simple.  Set logging to enabled on your NAT / Firewall rules on the ASG 1 box, and watch the live log when a remote ASG (that is failing to connect) tries to connect -- do you see the 4433 packets?  if not, check your firewall rules.  If so... check the ACC Device Agent log on the remote ASG, it will indicate what is going on.

This is why I feel like such a noob, it is likely something very simple that I am just not seeing.

With the rule Any-Any-Any turned on on both ASG1 and ASGx units, and looking at the ASG1 Firewall, IPS, and Web Filtering logs, there are no entries with port 4433, hmmmm, I am not liking that.  I also  changed the ACC Host setting on ASGx with the actual IP address of ASG1, so that should eliminate any DynDNS issues.

When I check the remote ASGx Central Management log I get this;


2012:08:17-17:03:43 ***XX device-agent[17861]:Updating ACC IP address for path: acc/server1/server
2012:08:17-17:03:43 ***XX device-agent[17861]: [1] Connecting to ACC socket (ip=***.***.***.***, port=4433).
2012:08:17-17:03:43 ***XX device-agent[17861]: [1] Using ACC SSL connection.
2012:08:17-17:03:48 ***XX device-agent[17861]: [1] ACC connection failure, retrying (ip=***.***.***.***, port=4433). SSL-connect: 'IO::Socket::INET configuration failederror:00000000:lib(0):func(0):reason(0)'
2012:08:17-17:03:54 ***XX device-agent[17861]: [1] ACC connection failure, retrying (ip=***.***.***.***, port=4433). SSL-connect: 'IO::Socket::INET configuration failederror:00000000:lib(0):func(0):reason(0)'
2012:08:17-17:03:55 ***XX device-agent[17861]: [1] Connection failed (ip=***.***.***.***, port=4433).
2012:08:17-17:03:55 ***XX device-agent[17861]: Not reporting inotify: no role
2012:08:17-17:03:55 ***XX device-agent[17861]: timer2 -> module 1 not executing: denied by role
2012:08:17-17:03:55 ***XX device-agent[17861]: timer2 -> module 2 not executing: denied by role
2012:08:17-17:03:55 ***XX device-agent[17861]: timer2 -> module 3 not executing: denied by role
2012:08:17-17:03:55 ***XX device-agent[17861]: timer2 -> module 4 not executing: denied by role
2012:08:17-17:03:55 ***XX device-agent[17861]: timer2 -> module 5 not executing: denied by role
2012:08:17-17:03:55 ***XX device-agent[17861]: timer2 -> module 6 not executing: denied by role
2012:08:17-17:03:55 ***XX device-agent[17861]: timer2 -> module 7 not executing: denied by role
2012:08:17-17:04:00 ***XX device-agent[17861]:*


I see the SSL failures, not sure what to do about that as I mentioned I did enable SSL VPN on ASG1 and added ACC-SSO_Admin user.

??Not sure what the other errors; module 7 not executing denied by role??

I noted some of your other postings -- time to look upstream from ASG1 ... possibly your ISP, or an upstream firewall, is to blame.  I have had ISPs block certain ports before without warning.

I noted some of your other postings -- time to look upstream from ASG1 ... possibly your ISP, or an upstream firewall, is to blame.  I have had ISPs block certain ports before without warning.

Hit the nail on the head there Bruce!!!  I thought about that too. So I looked through the logs and noted that there was alot of unusual dropped packets in front of the WAN port on ASG1 [:S].  Then all of a sudden I noticed that eth0 interface had a 192.* address [:S]

Long story short, I am an ATT UVerse customer and well, it seems that sometime in the last year ATT must have pushed a firmware update to the modem and caused my bridge mode to switch back to firewall/nat mode.  That explains alot of unusual networking issues...[:O]

So this was an easy fix, log into the ATT modem, goto the settings page and check mark the bridge mode. whew. ALL IS BETTER NOW! [:D]

Don't you just love when you ISP changes things on you without notification.

Glad it was simple.

FWIW, AT&T did push out a firmware update recently that probably caused that... the update, among other things, prevents those who depend on the RG for NAT from using the 10.x.x.x network range... rumors vary as to what they will be doing with the 10.x.x.x range, some think RNAT may be the purpose.  It won't affect you, necessarily, other than the update is probably what wiped out your old settings.

Anyhow, I have access to a Uverse 3600 RG that has a static public IP assigned to it, so if you need any further help getting Uverse and UTM (ASG) to cooperate, let me know.  It is a bit of a pain to figure out otherwise [:)]