ADNM Reporting Client IP As Local Gateway Address

[P3iSystems]

Hello everyone,

I've searched through the forums and knowledge base and have been unable to find an indication of what's causing my issue. The ADNM is reporting the client IP address' as the local network's gateway address when they are connected to the same network the AMS is on. For remote users who are accessing the AMS using it's public IP, their IP address is reported as their public IP which is expected by me. Before setting up the port forwards to allow remote users to access the AMS via it's public IP, this problem did not occur. Does anyone have a clue as to why this is happening?

[.: Mac :.]

It sounds like they are atempting to access teh AMS through the interent. Have you tried defining the AMS by its internal LAN IP address in the install package? If not, try doing so and installing on a test client to see if this helps.

[P3iSystems]

You're correct about the clients pointing to the AMS' public IP. However, by pointing them to the local IP, the clients that are on the local network with the AMS will be recognized properly (IP address of client) but our remote clients (field agents) will not be able to access the AMS since they will not be on the local network with the AMS.

Both remote and local clients can access the AMS properly since they can still receive policy updates, etc.. The issue with the clients IP addresses being displayed as the local gatway only exists with local clients. Remote clients report their public IP, which is fine and allows remote access to their virus chest.

I'm fine with local clients not reporting their correct IP address the AMS for display in the ADNM as long as both local and remote clients can still talk to the AMS properly. It would just be nice to be able to have the correct IP displayed in the ADNM for local clients so that I may access their virus chest remotely rather than having to visit the clients' machine to get that information. I hope this helps define what I'm trying to accomplish a bit more thoroughly. Thank you for your response

[.: Mac :.]

I would assume you can just create two deployment packages, one for internal clients and one for External clients and define the AMS address speperate in each. This is what our customers do when they have a second location and they wish to point to the external IP (or a Second level mirror)

[P3iSystems]

This brings another possible issue into the mix when doing it that way. Our remote clients often work from the local network and also work from remote locations. I believe that if I could get the client to first check for the local AMS IP, if failure, then check for public IP of AMS. If the local IP is detected as the AMS then it will display the clients local IP properly to the ADNM. If the local AMS IP is not found and has success on it's public IP, then the clients' public IP would be properly displayed in the ADNM. I get the feeling that this is completely possible. I'll check and see if this can be set through the client policy options in ADNM.

While I'm checking, do you have a different suggestion or would you agree with me on the aforementioned method?

[P3iSystems]

Under the computer policies menu in ADNM, Communications section, I do not see the option to specify "secondary" AMS IP address. There is the option to have the client search for other AMS servers if the one single specified one is not found. This would not work for our situation since if the AMS is set as the local IP remote clients won't be able to talk to the AMS nor find the public IP since there is no option to specify a secondary AMS if the primary isn't found.

[.: Mac :.]

Under the computer policies menu in ADNM, Communications section, I do not see the option to specify "secondary" AMS IP address. There is the option to have the client search for other AMS servers if the one single specified one is not found. This would not work for our situation since if the AMS is set as the local IP remote clients won't be able to talk to the AMS nor find the public IP since there is no option to specify a secondary AMS if the primary isn't found.

I dont think you can specify a secondary AMS? Seems that you could make those mobile clients just point to the external Address. It should still work internally, or if not they will still update from Avast's main update servers

[P3iSystems]

You're right. All clients are already pointed to the external IP. All users are communicating with the ADNM and receiving policy updates, etc.. However, the IP for the clients in ADNM is showing as their gateway IP and therefore preventing access from the ADNM to their virus chest remotely. I'm trying to prevent this from happening and get their correct IP (internal or external) to display in the ADNM. What I will do per your recommendation is to set non-mobile clients such as desktops to the internal AMS address and set mobile workstations to the external IP. That will give us better results but we will still be left with mobile clients showing their local gateway IP in ADNM if they are pointed to the external AMS IP and they are currently on the internal network same as the AMS.

How could we get the mobile clients to always show their correct IP if they are pointed to the external IP of the AMS (since they do travel to other networks) but still show their correct internal IP when they are on the same local network as the AMS?

You're correct about the clients pointing to the AMS' public IP. However, by pointing them to the local IP, the clients that are on the local network with the AMS will be recognized properly (IP address of client) but our remote clients (field agents) will not be able to access the AMS since they will not be on the local network with the AMS.

Both remote and local clients can access the AMS properly since they can still receive policy updates, etc.. The issue with the clients IP addresses being displayed as the local gatway only exists with local clients. Remote clients report their public IP, which is fine and allows remote access to their virus chest.

I'm fine with local clients not reporting their correct IP address the AMS for display in the ADNM as long as both local and remote clients can still talk to the AMS properly. It would just be nice to be able to have the correct IP displayed in the ADNM for local clients so that I may access their virus chest remotely rather than having to visit the clients' machine to get that information. I hope this helps define what I'm trying to accomplish a bit more thoroughly. Thank you for your response

[scythe944]

Technically, the only reason you need the clients to talk to the AMS is to download settings that you apply to the computer groups, attach to their virus chest and to have reporting on them.

Sometimes, that's not that important.  The main thing is that they can get definition updates, which in any case, they will revert to Avast's internet servers if they can't reach the AMS.

I'd point everything to the local IP for computers that actually come back to the local LAN from time to time, and for those that don't, I'd set it up for External IP only.

[P3iSystems]

I updated my previous post a little bit right after you had posted so please read the extra bit of my post when you can. Connecting to their virus chest is important to me since I like to see what files are most typically being infected, what files are likely still infected, etc. When our mobile clients who are sometimes on the same local network as the AMS but are pointed to the external AMS IP, I'm unable to connect to their virus chest since the ADNM is not seeing their correct internal IP address.

I'm thinking all I can do is set non-mobile workstations to the internal AMS address and just live with not being able to access the virus chest of the notebooks that are mostly mobile. Notebooks that are always at the office will be set to local AMS IP too. Seems like I'll have to settle. That's an alright workaround.

Thanks for the help and if you have any better suggestions then please advise.

[scythe944]

Well, do your remote clients use VPN to the corporate office at all?

If not, I don't think there's any way around not being able to connect to their virus chests at this point, because there's no way that the ADNM console would know what IP address the client is on, and you'd have to open up the Remove Virus chest port on all client PC's first anyway (can't remember the actual port, but it's in the manual).

If they use VPN, I would assume that you'd be able to connect to them, if only for the duration of time that they were connected.  It would be a hit or miss affair, but it might work enough.