Anyone get Wired Guest access working using the latest code 5.148 (or any code for that matter). In particular has anyone been sucessful using 1 WLC with ingress and egress on same controller. I have been trying for a week and does not work no matter what.
Thanks for all responses....
See next post with attached .doc
This post was trimmed.
Create a new interface <. myguests-ingress> assign it a VLAN ID <44>
Check the box that says Guest LAN
This interface has no IP, it is Layer2 only!
If there is an IP associated with this VLAN (anywhere), create another VLAN.
-Egress int (if you are already using one for wireless guest access, you can skip this step and reuse that one, I did!) It will not be called âEgressâ on the wireless, just interface. If you don't have one already, you need to create it
Create a new interface
Assign IP, netmask, and gateway info < 192.168.100.10, 255.255.255.0, 192.168.100.1 > (see Router section below)
I used addresses that were NOT on my business network, so guest IPs are easily distinguished from employees
Also since this traffic is within a VLAN, I need to route this traffic at some point to access my gateway
If you want to give guests DHCP addresses, assign a Primary DHCP Server to this interface (see DHCP section below)
Since I was using the WLC for DHCP, I put the IP of my management interface (or another of your choice)
-Internal DHCP (if you are using your WLC for DHCP this needs to be configured)
Start <192.168.100.100 > (same subnet as "egress")
Default router <192.168.100.1> (same as your gateway above)
This is really just an IP to route between VLANs, it may not exist yet
Don't worry if this is on another subnet as your real gateway (it should be), this is just a gateway IP for this subnet
You can route between VLANs (that's what I did) on your router
DNS server <10.10.10.50> (this a local DNS, but you could use anything I guess, even your ISPs DNS server)
Status = Enabled
Create a new WLAN, select Guest LAN as the type
Ingress is a L2 VLAN
Egress is a L3 VLAN
Security Tab, select Web Auth/Pass
Advanced Tab, specify your DHCP
Check override (required for external DHCP)
Was not able to check DHCP Addr. Assignment = Required (bug?)
General Tab, check status = Enabled
Ignore the error; this is a bug!
Core Switch configuration (these commands are in CatOS)
Since wired guest access uses the same interface (in my config,) I did not have to do this step as it was done previously.
You need to configure your core switch to allow VLAN traffic from your WLC interfaces
VTP and VTP domain were previously configured; you may need to do this if you have never done VLANs on this switch
# set vlan 44 name MYGUESTS-INBOUND - - - IOS will be different
# set vlan 55 name MYGUESTS-OUTBOUND - - - IOS will be different
If you already have a vlan for wireless guests this step is already done
Setup trunking on the port coming from the WLC to your switch (I chose mod/port =3/5, yours will be different)
# set trunk 3/5 on dot1q - - - IOS will be different
This allows VLANs to traverse from the WLC to the switch, (you could specify which VLANs only)
I have created VLAN ACLs that restrict the access of guests, but that can be done after this is up and working
Now this next step was required for my environment, but I am not sure that all setups can be done like this. I have another DHCP server on my network, so I wanted to make sure that there was not a conflict. To do this I specified a port on my core switch to accept VLAN traffic for my ingress interface
Configure a port on my core switch to accept wired guest traffic (I chose mod/port =3/6, yours will be different)
# set vlan 44 3/6 - - - IOS will be different
It's possible you may also need to allow your egress VLAN depending on your setup
Plug switch into the port specified
Got this up and running today. I have attached detailed instructions (with some explanations) for how to set this up. It is somewhat confusing compared to how the wireless guest access works. If you already have wireless guest access up and running, you may be able to reuse those interfaces and save yourself some work.
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...
Our WLC 4402 is running version 126.96.36.199.
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).
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.
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!
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 188.8.131.52 Static
virtual N/A 184.108.40.206 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 220.127.116.11 Static No No
service-port N/A N/A 18.104.22.168 Static No No
virtual N/A N/A 22.214.171.124 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
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
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.