Mike,
AS long as the client machine can route to that IP address when its on
the network, it is fine. Does not need to be a real IP address.
Like I mentioned in my last email, you will need to push a newer agent
for this changed "discovery host " information to be propagated to
The end clients.
In other words, the registry value for Discovery Host gets hard set
during agent install/upgrade. You have to figure out a way you can
change them all
Manually (through some script etc) OR..push a newer agent
HTH
Prem
-----Original Message-----
From: Cisco Clean Access Users and Administrators
[mailto:[log in to unmask]] On Behalf Of Mike Diggins
Sent: Monday, October 23, 2006 12:23 PM
To: [log in to unmask]
Subject: Re: CCA and unwanted L3 Agent queries
On Mon, 23 Oct 2006, Prem Ananthakrishnan (prananth) wrote:
> Hi Mike,
>
> Welcome to the list!! :) Glad to have you here.
>
> 1) It is recommended that the discovery Host not be the CAS IP
address.
> In fact, it should be the IP address of a device on the trusted side
> (beyond the CAS) - Preferably the CAM.
>
> 2) So, that brings us to the next question:- What is your CAM's IP
> address? Is that public as well?
>
> What is happening is that agent tried to discover CAM (or whatever IP
> you configured) via L2 and then when CAS is not available in the PATH,
> it tries to use L3 (on port 8906) to discover the CAM. Now, of course,
> when they go home, L2 wont work and they will use L3.
>
> This traffic is being routed to your FW by your ISP as the discovery
> is done for CAS IP address.
>
> If your CAMs IP address is NOT public, then you can use that and that
> will work. However, you will need push a new agent with the discovery
> host. The discovery host is hardset during install (as a registry
> value).
>
> What version of agent are you running now?
Thanks for your help. I'm running Agent 3.6.4.0. My CAM is a public
address too, sigh. However, I could create a "dummy" Discovery Host that
resolves to a inside private address (to a real network). Would that do
it? What happens if I leave the Discovery Host blank (since I don't need
L3 discovery)?
I understand that existing Agent users will not be upgraded
automatically, but that's okay, since I'll have to force an agent
upgrade sooner or later (upgrading to 4.x or 3.6.4.1 perhaps).
-Mike
>
> -Prem
>
>
> -----Original Message-----
> From: Cisco Clean Access Users and Administrators
> [mailto:[log in to unmask]] On Behalf Of Mike Diggins
> Sent: Monday, October 23, 2006 10:35 AM
> To: [log in to unmask]
> Subject: CCA and unwanted L3 Agent queries
>
> Hi folks, happy I found this list. Great information!
>
> We're a University using CCA for our wireless network. I just deployed
> CCA
> 3.6.4 this past August so I'm still learning. Our CCA CAM/CAS is
> 3.6.4.1, in-band, virtual gateway mode.
>
> I made the mistake of configuring our CAS with a public IP address not
> considering the ramifications. When my wireless clients return home, I
> can see lots of hits against port 8906/udp to our CAS on our campus
> firewall.
> They don't make it of course. I now realize I should have used a
> private address so this wouldn't happen.
>
> However, after reading through this list, I now understand that the
> udp/8906 packets are L3 discoveries from the Agent. I don't need L3 as
> we run Virtual Gateway mode and our wireless clients are all local to
> the CAS. Under Device Management I do NOT have either the "Enable L3
> Support"
> or "Enable L2 strict mode for Clean Access Agent" checked but I did
> specify my CAS as the Discovery Host.
>
> So, can this be fixed without changing my CAS IP address (which I
> really don't want to do mid term)? Should I remove the Discovery Host
> altogether?
> Should I change the Discovery host to a local host with a private
> address (one that won't resolve in DNS from home)? If I change this,
> what will happen to existing Agent users? Will they be prompted to
> download
> (upgrade) the agent again?
>
> If I can't fix this for existing users, I'd like to at least make it
> right for new users of the system. Any help would be appreciated.
>
> Thanks,
>
> -Mike
>
_________________________________________
Mike Diggins Voice: 905.525.9140 Ext. 27471
Network Analyst, Enterprise Networks FAX: 905.528.3773
University Technology Services E-Mail: [log in to unmask]
McMaster University, Hamilton, Ontario
|
