Itcore...

Yes I have done everything same as you pretty much with this difference... I am using LAG to trunk the WLC ports to the switch. (Though I don't feel that is the problem.) Also what code are you using on the 4400? I have a feeling this worked on 4.x revs and got broken in 5.x (though I haven't tried 4.x yet).

I'm convinced I am not having a routing problem because it actually does work fine until *AFTER* the webauth. Before auth I can resolve DNS queries (so it is reaching DNS server on another subnet). After auth I cannot resolve DNS or ping anything except the egress interface. And this is happening with no ACLs at all or even with an ACL that PERMITS ALL to ALL !!

Other thing is... how is this designed to work? I mean does the egress inf issue proxy arps on behalf of the wired guest client? When I look at the ARP table and MAC-addr table on the L3 switch connected to the WLC I see the wired guest client IP and its MAC in the egress VLAN... this doesn't make sense to me - how is the router going to find any of the wired clients behind the egress inf unless it issues a proxy arp ???

Wireless is working OK so it's just this that I don't think is right. Thanks for your help and advice...

Armonk-

Our WLC 4402 is running version 5.0.148.0.

I have LAG turned on, but I am not using it (only one port is connected). From what I understand LAG is similar to Etherchannel (port aggregation/redundancy). The trunking I setup was for VLANs. I think I remember reading somewhere (in the Cisco docs) that trunking (dot1q) was required for this setup. What commands did you input into your switch to enable VLAN trunking?

In my setup I was able to create a VLAN interface on my router (this is the egress gateway). Once your VLANs and trunking are setup you should be able to ping this interface from your WLC 4402. I do not think you should be able to do this before then (but I am not sure; it may depend on your setup.)

I am have configured a port on my switch to allow only traffic for my ingress interface which is plugged in the switch. If I understand you correctly, this works? You do get DHCP requests? Are you using the controller for DHCP?

As for how this works, I must admit I do not fully understand. What I do know is this:

• your ingress interface is L2

• your egress interface is L3

I think some kind of bridging is happening between ingress/egress, more than that I cannot say. It is somewhat confusing to me as well.

For your wireless, do you have “guest wireless” up and running? If so you can reuse that interface (as your egress).

-itcore

Itcore,

Yes LAG is link aggregation. It is easier to set up I think than manually setting VLANs to ports but with 1 port doesn't make a diff. My switch is IOS based so I used the switchport mode trunk and related commands. If I do a SHOW INT TRUNK everything looks good.

Hmmm... other difference is that I use the L3 capability in the switch that WLC is connected to for routing instead of separate router. I don't think this should matter though.

I can ping everything from the WLC including the wired guest client, the egress gateway, etc.... Its just that I cannot ping across the WLC from the wired guest client (or vice versa) For example I cannot ping the egress gateway but I can ping the egress interface from the client. Yes, the ingress interface seems to work as I do get DHCP from an external DHCP server.

Yes, I tried using the working wireless interface as well with no luck.

Its very frustrating and really the debugging tools that are in the WLC are not much help at all. I have tried to turn on packet trace debug but the information is pretty useless since you cannot follow the packet from ingress to cpu and to egress to know where the problem is.

Regards

Armonk-

I am using an L3 switch as well, you are correct it should make no difference.

Looking at my config, since I am using trunking (dot1q), both my wireless (egress) and wired (ingress) are available to the switchport connected to the controller. I think this is needed, if it is, then there are two VLANs on this link, not one.

Once you get your DHCP address, you can successfully login to the webpage (or are you using passthru)?

When you open the WLC and select clients (main page) do your wired clients show up as associated?

I would like to know if you could try something. Enable the DHCP server on the WLC. Change the egress interface to use this. Pick a range outside your normal DHCP scope. Do you get an address from the WLC?

If so, can your client ping the vlan gateway?

I had added an attachment with more info on my setup and my guess as to how this works.

Thanks very much Itcore... let's see....

Yes, the docs say to allow both ingress and egress VLANs on the trunk.

Yes, after I get DHCP I can successfully login to the web page.... but nothing else after that.

Yes, the wired clients show up as associated and authenticated (after login)

Yes, I can get an address from the internal DHCP server but I cannot ping the vlan gateway or the egress interface.

Just as a sanity check I think I'll use a different laptop for the wired client. Maybe there is something hosed on the client side that's causing the problem. I'll let you know what happens.... thanks again!

Armonk-

Sounds like you have it right.

I am curious. If you are using the same interface for wireless and wired egress, and they get DHCP from the same place, does wireless allow you to ping to vlan gateway but wired does not?

They way I understand it, the L2 guest LAN (ingress) is just to setup the connection so a wired client can get/use L3 info. If you are getting that info, I would have thought it has done its job, and is configured correctly.

If you are reusing the guest wireless interface (which must work, or wireless would not) then everything should be smooth.

Let me understand the interfaces you have setup. Something like this?

Interface VLAN IP Type

management N/A 10.1.1.5 Static

ap-manager untagged 10.1.1.6 Static

guest-egress 100 192.168.1.5 Dynam

wired-ingress 101 0.0.0.0 Dynam

service-port N/A 2.2.2.2 Static

virtual N/A 1.1.1.1 Static

Yup, no problem with wireless... I can ping everything. From what I think I saw from the debug trace the wired client packet hits the WLC and then gets dropped. For instance if I run 4 pings to the egress gateway vlan inf on the switch I see the 4 ping requests show in the controller debug but they never show in the switch debug. Either the switch is blocking it or doesn't know how to forward it.

Here are the VLAN on interfaces....

(Cisco Controller) >show interface summary

Interface Name Port Vlan Id IP Address Type Ap Mgr Guest

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

ap-manager LAG 352 172.20.192.130 Static Yes No

management LAG 351 69.74.38.45 Static No No

service-port N/A N/A 2.2.2.2 Static No No

virtual N/A N/A 1.1.1.1 Static No No

wired-guest LAG 33 0.0.0.0 Dynamic No Yes

wired-guest-egress LAG 353 192.168.100.2 Dynamic No No

wireless LAG 360 172.20.200.2 Dynamic No No

Thanks much

Your interfaces are interesting. I thought I remembered reading somewhere that the ap-manager and management interface

should be on the same subnet. Did you transpose the wireless interface IP address and management interface IP address?

Check out the this link from the WLC 4402 4.1 reference guide

http://www.cisco.com/en/US/docs/wireless/technology/guest_access/technical/reference/4.1/GAccess_41.html#wp1000602

My setup follows this example.

Now when I initially set it up this way I could get an IP address to my wireless clients, but could not get to the

internet, even though I was routing between VLANs. Turns out I needed a route back from my firewall to my wireless VLAN

gateway. I've done away with that, I NAT guests now.

Check out the Document ID: 99470, notice page5, #3. It shows the same thing, that the management and ap-manager interfaces

are on the same subnet. They are untagged (recommended for initial config), but I'm sure any VLAN will do as long as they

are the same.

Hmmm... I was going by the 5.0 configuration guide. Cisco seems to say that the subnets can be different for Management and AP-MAnager. (Excerpt shown below). Anywho, this would cause a problem with APs associating which I don't have - the APs communicate fine with the WLC.

(from config 5.0 guide)

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

Note Enter 0 for an untagged VLAN or a non-zero value for a tagged VLAN. Cisco recommends that only tagged VLANs be used on the controller.

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

•Fixed IP address, IP netmask, and default gateway

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

Note The AP-manager interface's IP address must be different from the management interface's IP address and may or may not be on the same subnet as the management interface. However, Cisco recommends that both interfaces be on the same subnet for optimum access point association.

this is a repost, sorry if it appears twice

What is the type and IOS version of the L3switch your WLC4402 is connected to?

I think you are onto something with your debug. The fact that your wired client can get an IP address, but cannot ping the egress interface. It's as if traffic isn't being passed from the ingress to the egress.

Are you running STP on the controller?

I can only think of 2 reasons (in this situation) packets would not be forwarded (or blocked).

1) VLAN/trunking config issue

2) ACL list on WLC

Since you have addressed both of these, I am not sure what else could be doing it. Do you know of another reason packets might be dropped from one interface to another?

what debugging options are you using on the WLC?

After much debugging I have found 2 issues that were causing my wired GUEST-LAN to fail.

1) For some reason AUTO-ANCHOR seems to get enabled on the GUEST-LAN which forces the traffic into an EOIP tunnel - this is definately not wanted on a single controller implementation as traffic goes into the tunnel and never exits. I can't begin to tell you how much hair I have lost trying to figure what was happening to the traffic.

2) When AAA-Override is enabled in the Advanced tab of the GUEST-LAN (as Cisco says to do when using the NGS radius) client access gets disabled presumably when the override attributes are applied. It looks that way because everything works correctly until right after radius authentication which is the point at which the Identity Networking function kicks in.

I've been a heavy user of Unified Networking for a year now and it seems every release is buggier than the last.