Hi Justin Have you tried sniffing the network to see what's happening at layer 2? For example, are name lookups working on the client? If no, does the DNS server see them and respond? If yes, does the CAS see the HTTP requests and what happens to its responses? Regards Max Caines IT Services, University of Wolverhampton Wolverhampton, West Midlands WV1 1SB Tel: 01902 322245 Fax: 01902 322777
_____ From: Cisco Clean Access Users and Administrators [mailto:[EMAIL PROTECTED] On Behalf Of Justin Howell Sent: 01 April 2008 16:50 To: [email protected] Subject: [CLEANACCESS] Weird Dead IP Problem OK, here's a strange one, maybe someone's seen this. Our original CAS setup was one managed subnet, class C, 172.16.6.0/24 to be exact. Real IP Gateway, In-Band deployment. The untrusted interface of the CAS and default route for the managed subnet was 172.16.6.1. Over the past two yeara, we would suddenly come up with a computer that would pull a particular IP, and with that IP, could not communicate with the CAS or any part of the network; it was like the IP was blacklisted or in conflict. DNS would not resolve; if I put in the IP of the CAS, I could get to the login portal, but when I tried to download the agent, it would timeout. No other network resources could be accessed, even those allowed by the unauthenticated role. Cisco of course blamed our network, that it was an IP problem on our network. Their solution was to break the managed subnet into two chunks, and exclude the offending IP. The computer would finally pull a different IP, and all would be well. The problem is, this problem keeps happening. It's currently broken into three different subnet chunks. And now this morning, we've got another IP that is not communicating with the CAS. The problem is, with every new chunk made, it requires its own default gateway; the CAS DHCP pages do not allow me to reuse the existing gateway. So each 'bad' IP we've got to exclude results in losing it and another IP for a gateway from our pool. We've got enough IPs for the moment, but this is getting annoying. We have another DHCP server for clients not on Clean Access, but it does not have a pool for the 172.16.6.0 subnet, so theoretically the only way this problem could be caused by an IP conflict would be a user on that subnet hard-coding an address. But they would still be on the clean access subnet, still have to authenticate/remediate, so I should see them on Users page or the event logs. Any one seen this? Or have suggestions? Cisco was not very helpful last time I called ("Just make two subnets - that IP problem is your problem not Clean Access's") so I'm hesitant to open another TAC and spend my week on the phone. Justin Howell Telecommunications Network Technician Solano Community College (707) 864-7205
smime.p7s
Description: S/MIME cryptographic signature
