CLEANACCESS Archives

August 2006

CLEANACCESS@LISTSERV.MIAMIOH.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"King, Michael" <[log in to unmask]>
Reply To:
Perfigo SecureSmart and CleanMachines Discussion List <[log in to unmask]>
Date:
Thu, 10 Aug 2006 23:32:34 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (218 lines)
Sounds like you've gotten the answer.

Pete has (successfully) diagnosed a random left-field for me, and I'm
sure other installations.

(We had a corrupted database, which caused our CAM to lose it's license
once a month.  Just long enough for us to take a while to recognize the
pattern.  Pete's suggestion of rebuilding our database from scratch was
the one that fixed the problem for us) 

-----Original Message-----
From: Perfigo SecureSmart and CleanMachines Discussion List
[mailto:[log in to unmask]] On Behalf Of Kelley, Tim
Sent: Thursday, August 10, 2006 10:10 PM
To: [log in to unmask]
Subject: Re: No filter but still no web login

I want to thank you all for your help in resolving this (to me)
mindblowing problem.  I would especially like to than Rajesh for
allowing me to take this off-list to give him some information I would
rather not share publicly. (I am not paranoid.)

It appears I overlooked my server logs when this was going on:  Our CAS
pair were failing-over to each-other about once a minute for the past
few days.  As a result the client ARP tables were periodically pointing
to the wrong CAS MAC.  As soon as I ran arp -d <vlan gw ip>, pinged any
ip to repopulate my ARP table, and ran arp -a on a non-authenticating
client I was able to see the correct authentication page (and resolving
to the active CAS's MAC).  

Obviously this is not a long-term solution for our students.  Pete Elke,
a CCA consultant I expect many of you know (and value), recommended we
upgrade our CAS v. 3.6.2.1 to 3.6.4.1 to address the random failover.

Long live the list.

-Tim

Tim Kelley
ResNet Coordinator
California State University, Chico
m. 530.230.7400
o. 530.898.5148



-----Original Message-----
From: Perfigo SecureSmart and CleanMachines Discussion List
[mailto:[log in to unmask]] On Behalf Of Rajesh Nair (rajnair)
Sent: Thursday, August 10, 2006 11:50 AM
To: [log in to unmask]
Subject: Re: No filter but still no web login

Tim,

Can you check the ARP cache on the client machine to make sure that the
MAC address that you see for the client's gateway is really the CAS eth1
MAC?

-Rajesh. 

-----Original Message-----
From: Perfigo SecureSmart and CleanMachines Discussion List
[mailto:[log in to unmask]] On Behalf Of Kelley, Tim
Sent: Thursday, August 10, 2006 11:39 AM
To: [log in to unmask]
Subject: Re: No filter but still no web login

Rajesh,

I was waiting for this one since I forgot to include it in my original
email.  I have a *,*,* (vlan, subnet, os) userpage that catches the
overflow from the other OS specific userpages.

-Tim

Tim Kelley
ResNet Coordinator
California State University, Chico
m. 530.230.7400
o. 530.898.5148



-----Original Message-----
From: Perfigo SecureSmart and CleanMachines Discussion List
[mailto:[log in to unmask]] On Behalf Of Rajesh Nair (rajnair)
Sent: Thursday, August 10, 2006 10:57 AM
To: [log in to unmask]
Subject: Re: No filter but still no web login

Also, is the login page for all VLANs/subnets or only for the test VLAN?
 
-Rajesh.

________________________________

From: Perfigo SecureSmart and CleanMachines Discussion List
[mailto:[log in to unmask]] On Behalf Of Dennis Xu
Sent: Thursday, August 10, 2006 10:39 AM
To: [log in to unmask]
Subject: Re: No filter but still no web login



Can other users get IP correctly? 

 

Once I have seen one specific user could not being directed to web login
page because he got the same IP as CAS IP in management subnet. Make
sure to exclude CAS IP in management subnet from central DHCP range. 

 

------------

Dennis Xu

Network Analyst (CCS)

University of Guelph

519-824-4120 x 56217

[log in to unmask]

________________________________

From: Perfigo SecureSmart and CleanMachines Discussion List
[mailto:[log in to unmask]] On Behalf Of Kelley, Tim
Sent: Thursday, August 10, 2006 1:22 PM
To: [log in to unmask]
Subject: No filter but still no web login

 

Hi All,

I have been banging my head against the wall for the past three days
with this problem so I thought I would submit it to the group.  

The Setup:

        IB, Real IP, Failover CAS & CAM bundles

Briefly, here are the symptoms:

No users except on one VLAN (the test VLAN in my office) are being
redirected to the login page on requesting a url.  It works as expected
on my test VLAN.

Here is what I have done to test it:

1)      Verified that there are no subnet filters on both the CAS and
CAM

2)      Verified that there are no device filters on the CAS or CAM

3)      Checked the 'Unauthenticated' role filter and see that there is
allow access to the following (untrusted -> trusted):

a.      UDP & TCP untrusted = *:* trusted = 132.241.66.8
/255.255.255.255 :* (our  vpn server)

b.      TCP untrusted = *:*  trusted = 132.241.82.62 /255.255.255.255
:80 (our resnet web server)

c.      UDP DNS

d.      Otherwise, block all

4)      Allowed hosts are the stock setup

5)      Bandwidth management not enabled.

6)      My test devices are not on the 'Certified Devices' list.

7)      I added a 'deny' filter for my test device's MAC and I verified
that I was not able to access the Internet (to test to see if there was
a layer 3 bypass to the CAS).

And then I started "poking it with a stick" because I was out of ideas:

8)      I verified that I was being issued an IP in a range appropriate
to the managed subnet.

9)      I deleted the managed subnet from the CAS and verified that I
could not access the internet. 

10)     I checked /proc/click/intern_validation_table on the CAS for 00
MACs as per Kyle Evans on the ListServ:

"We are running IB VGW, and we had a similar problem one time.  I don't
know what caused it exactly, but I suspect it had to do with managed
subnets not being created properly.  Anyway, cd to
/proc/click/intern_validation_table on the CAS.  Then do "cat table".
We found that if any IP addresses in that table had mac addresses of all
0s, then whomever had that IP address could use the network unfettered."

        No 00:00... macs

I am out of ideas.  I would love some help.

-Tim

Tim Kelley

ResNet Coordinator

California State University, Chico

m. 530.230.7400

o. 530.898.5148

 

ATOM RSS1 RSS2