EndPoint client unable to contact SOA over Microsoft DirectAccess

[REDACTED]

We are in the 1st phase of deploying Microsoft's DirectAccess VPN technology. 

Issue:
An Endpoint Protection Point Plus client cannot communicate with the SOA service over DirectAccess.
New installs continue to report "In Trial Mode".  The SOA does not register the client as having ever connected.

Validation Steps Taken:
1) The Avast client can communicate if the workstation is on the internal network (By passing DirectAccess)
2) The Avast client can communicate over regular VPN (Sonicwall VPN in this case)
3) We are able to access the SOA website over DirectAccess from a workstation with no issues
4) The SOA server has the following TCP ports open (with edge traversal):  8731, 8732, 25322
5) All settings in the Avast client Administration console are correct and are using the fully qualified name (no IP)

Logging:
AvastNet.log contains the following entries:

10/03/2014, 14:32:31    avast! NetService identified as srvm-9
10/03/2014, 14:33:01    Server didn't respond in time! Trying to wait a little longer.
10/03/2014, 14:33:31    Server didn't respond in time! Will Restart NetPump.
10/03/2014, 14:35:33    Server didn't respond in time! Will Restart NetPump.
10/03/2014, 14:37:35    Server didn't respond in time! Will Restart NetPump.
10/03/2014, 14:37:35    Server didn't respond in time! Increasing the timeout. (3 minutes)
10/03/2014, 14:41:38    Server didn't respond in time! Will Restart NetPump.
10/03/2014, 14:41:38    Server didn't respond in time! Increasing the timeout. (3 minutes)
10/03/2014, 14:45:44    Server didn't respond in time! Will Restart NetPump.
10/03/2014, 14:45:44    Server didn't respond in time! Increasing the timeout. (3 minutes)
10/03/2014, 14:49:50    Server didn't respond in time! Will Restart NetPump.
10/03/2014, 14:49:50    Server didn't respond in time! Increasing the timeout to max! (10 minutes)

Any thoughts?

[REDACTED]

Additional research has uncovered that Avast end-point clients seem to require push data from the SOA server.

If we are reading our packet analysis correctly, this is what appears to happen:

1) Client generates a connection to the SOA server via DirectAccess (Successful)
2) the SOA server then attempts to create an outbound connection to the client on port 25322 (Fails)

Because DirectAccess does not allow "Manage Out" connections by default, the outbound connection from the SOA server is unable to route to the client correctly.

Can anyone confirm this behavior?

If this is the actual behavior of Avast End Point Protection and SOA, Avast may not be an option for companies utilizing a remote work force via DirectAccess. 

Really hoping this is not the case!

[Avosec-UK]

You could always try avast! Enterprise Administration with Communication settings for the clients set to POP only, instead of the default PUSH and POP communication method.