Disregard my issue is related to a new CAP2702I-B-k9 joining a WLC running 8.0.121.0 which won't work. ... View more

Noticed this exact same thing occurring on some new AP I have as well. Was there any specific fix or bug ID? ( skimming the release notes now) ... View more

Only traffic that is contained within the encryption domain will get encrypted.   The GRE tunnel will be from the Tunnel Source to the Tunnel Destination. Just keep that out of the encryption domain.   You could always try an use sub-interface to keep the traffic separate. Or start creating loopbacks and sourcing the traffic from the loopback. ... View more

Just be careful with your encryption domain for the P2P Tunnel. Remember P2P IPSec tunnels don't allow dynamic routing, so your scalability is limited.   Also there is an order of operations with packets moving through interfaces. http://www.cisco.com/c/en/us/support/docs/ip/network-address-translation-nat/6209-5.html   ... View more

The response back to the wireless client will following normal L2 / L3 switching. The subnet the WLAN client is one should be connected to the same IP Subnet that the associated WLC Interface is configured, this way traffic is sent back to the WLC and the encapsulated in CAPWAP back to the appropriate AP where is transmitted over the RF/Wireless. ... View more

With Central Switching all traffic is tunneled back to the WLC via the CAPWAP tunnel, so the CAPWAP tunnels acts like an Overlay or GRE tunnel in this case. The wired network is completely obviously of the what the WLAN traffic because all the wired traffic sees is CAPWAP data.  The real client data is encapsulated within CAPWAP. Once the WLC receives the data encapsulated within the CAPWAP tunnel the WLC with the decapsulate the traffic. Once the data decapsulated at the WLC it is then routed/switched like normal traffic. Due to this your WLAN will use one subnet, so the IP Subnet will span across all the locations, this is doing with a single WLAN if that is desired design.   Something also to keep in mind the CAPWAP encapsulation adds an additional 8 bytes of header information. Just something to keep in mind if this traffic will be traversing IPSec/GRE/DMVPN tunnels. ... View more

Well the below options come to mind first.   Configure the single WLAN for Central Switching so everything get tunneled back to the WLC. Or Configure your the DMZ WLC as a mobility anchor and anchor your WLAN to the WLC in the DMZ.   You may also want to have a DHCP & possible a DNS server in the DMZ to handle that traffic, if it desired to have the keep that traffic off the internal network to. ... View more

Also just to make sure, you want the traffic to traverse this iPrism web filtering appliance first right?   When the clients browse the web is their traffic destined for the iPrism appliance and 'proxied' through or are the clients sending thier request to the internet and the iPrism is operating in a layer 2 bridge type mode? ... View more

Mark this is actually a typical requirement for many companies.   There are few creative ways to solve this, in my opinion the easiest way would be to spin a GRE tunnel at the remote site and terminate other end the GRE to another router behind the ASA firewall (since an ASA firewall can not terminate GRE tunnels), once the tunnel is build route the subnet over the GRE tunnel using normal OSPF/EIGRP routing, from that point traffic from the remote site will get routed through your network accordingly. ... View more

The it reported to port scans? 1 From the WLC 1 From an LAP - If the LAP was not associated to the WLC how do you know it was a LAP? How often do these alerts trigger?      -- CCNP, CCIP, CCDP, CCNA: Security/Wireless Blog: http://ccie-or-null.net/ ... View more

Assuming Symantec is reporting the source of the scan, I would investigate and hunt down the source. Once you find the source it should be able to tell is the port scan malicious or port of some type of management tool. -- CCNP, CCIP, CCDP, CCNA: Security/Wireless Blog: http://ccie-or-null.net/ ... View more