Question : DHCP and LWAPP across VPN tunnel

Background Info...

We have a Cisco NME-AIR-WLC12-K9, Wireless LAN Controller Module installed in our 2821 ISR. Connected to the Controller are 8 Cisco AIR-AP1242G-A-K9 Access Points that have been converted to Lightweight using the Upgrade tool provide by Cisco. 7 of the 8 LWAP's function properly with little effort or administration.

The Problem...

Two of our sites with Wireless capabilities are behind VPN tunnels managed by Time Warner Cable's Manages Security Group. Equipment at both sites is identical. 1 Station works, and the other does not.

The Facts...

Station 4 (192.168.103.0)
1 SonicWall Firewall - A - (Managed by Time Warner)
1 Cisco 3560 8PC PoE Switch
1 Workstation
1 Cisco AIR-AP1242G-A-K9 Access Point
All devices pull DHCP addresses function on the network across the VPN tunnel as if they were connected locally. No problems with Station 4. The interface on the SonicWall 192.168.103.1, is pingable from anywhere on the network.

Station 1 (192.168.115.0)
1 SonicWall Firewall - B - (Managed by Time Warner)
1 Cisco 3560 8PC PoE Switch
2 Workstations
1 Cisco AIR-AP1242G-A-K9 Access Point
All Workstation function properly across the VPN tunnel. The problem is with the Access point. It will not connect to the controller. I grabs a DHCP lease and drops it seconds later. I then continues this loop indefinately. The interface on the SonicWall 192.168.115.1, is only pingable from devices on the same side of the tunnel. The Wireless LAN Copntroller and the DHCP server CANNOT ping the SonicWall at 192.168.115.1.

SonicWall - C - (10.10.10.14)
Physically located at Time Warner's Fiber Head-end and tied into our Metro Ethernet.

Cisco 2821 - D - (10.10.10.1 - 192.168.101.5 - 192.168.119.10)
Contains the Cisco NME-AIR-WLC12-K9 Wireless LAN Controller Module. The 2821 ISR is directly connected to the Metro Ethernet on the 10.10.10.1 interface. The 192.168.101.5 interface is the Dafault Gateway for 90% of all network traffic.

Cisco 3560 - E
This represent a group of switch that provide network access to users, printers and servers.

DHCP Server - 192.168.101.215
Serves 12 different scopes. Is a domain controller, and name server.

The work already done...

-Swapped out WAP ate Station 1 with 3 know good WAP's. All WAP's fail ate Station 1 and work everywhere else
-Have tried various diferent power and connectivity scenerios, all wit hthe same failing result.
-Have gone rounds with Time Warner Support who swares it is our equipment that is the problem.

Code Snippet:

         
           
             1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:
50:
51:
52:
53:
54:
55:
56:
57:
58:
59:
60:
61:
62:
63:
64:
65:
66:
67:
68:
69:
70:
71:
72:
73:
74:
75:
76:
77:
78:
79:
80:
81:
82:
83:
84:
85:
86:
87:
88:
89:
90:
91:
92:
93:
94:
95:
96:
97:
98:
99:
100:
101:
102:
103:
104:
105:
106:
107:
108:
109:
110:
111:
112:
113:
114:
115:
116:
117:
118:
119:
120:
121:
122:
123:
124:
125:
126:
127:
128:
129:
130:
131:
132:
133:
134:
135:
136:
137:
138:
139:
140:
141:
142:
143:
144:
145:
146:
147:
148:
149:
150:
151:
152:
153:
154:
155:
156:
157:
158:
159:
160:
161:
162:
163:
164:
165:
166:
167:
168:
169:
170:
171:
172:
173:
174:

           
           
             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~>Ping from DHCP Server to both Stations
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ethernet adapter Local Area Connection:
 
   Connection-specific DNS Suffix  . :
   IP Address. . . . . . . . . . . . : 192.168.101.215
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 192.168.101.5
 
C:\>ping 192.168.103.1
 
Pinging 192.168.103.1 with 32 bytes of data:
 
Reply from 192.168.103.1: bytes=32 time=21ms TTL=63
Reply from 192.168.103.1: bytes=32 time=17ms TTL=63
Reply from 192.168.103.1: bytes=32 time=20ms TTL=63
Reply from 192.168.103.1: bytes=32 time=21ms TTL=63
 
Ping statistics for 192.168.103.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 17ms, Maximum = 21ms, Average = 19ms
 
C:\>ping 192.168.115.1
 
Pinging 192.168.115.1 with 32 bytes of data:
 
Request timed out.
Request timed out.
Request timed out.
Request timed out.
 
Ping statistics for 192.168.115.1:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~>Ping from Wireless LAN Controller to both Stations
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Cisco Controller) >ping 192.168.115.1
Send count=3, Receive count=0 from 192.168.115.1
 
(Cisco Controller) >ping 192.168.103.1
Send count=3, Receive count=3 from 192.168.103.1
 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~>Last message from Time Warner Support
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I have attached screen caps of Wireshark traffic.
 
The first Screen Caps titled DHCP_Offer_Difference.GIF and 
DHCP_ACK_Difference.GIF compare the Fire Station 4 and 
Fire Station 1 Packet caps while the DHCP process was occurring.
 
From what we can tell (it is highlighted in the screen caps) - 
the only difference in the capture is that the subnet mask 
given to the AP at Station 4 is 255.255.255.248, but at Station 1 it is 255.255.255.0.
 
We decided to extend our search criteria and ran a packet 
trace on the firewall for not only the DHCP servers IP, 
but the LWAPP Controllers AP as well. The last 
screen capture that is attached (titled HUBDHCPandLWAPP.GIF) 
contains pertinent information to these two processes.
 
Notice that the traffic between the working AP at Station 4 consists of 2 
CNTL PRIMARY_DISCOVERY_REQUEST packets from the AP 
to the Controller, followed by a CNTL PRIMARY_DISCOVERY_RES 
packet back from the Controller to the AP.
 
The traffic from Station one though is a bit different.
==Shown is the initial DHCP process==
From AP to DHCP server: DHCP Discover (AP proxied by Firewall)
From DHCP server to AP: DHCP Offer (AP proxied by Firewall)
From AP to DHCP server: DHCP Request (AP proxied by Firewall)
From DHCP server to AP: DHCP ACK (AP proxied by Firewall)
==The AP now has an IP and we see communication with the LWAPP Controller==
From AP to LWAPP Controller: CNTL DISCOVERY_REQUEST (traffic not proxied)
From AP to LWAPP Controller: CNTL DISCOVERY_REQUEST (traffic not proxied)
From LWAPp Controller to AP: CNTL DISCOVERY_REPLY (traffic not proxied)
==The AP now forces multiple DHCP RELEASES==
==The process repeats==
 
Note that the traffic from the Station 1 AP is CNTL DISCOVERY_ and not 
CNTL PRIMARY_DISCOVERY_ as it is at Station 4.
 
The initial packet capture we ran yesterday did not contain traffic
 to or from the LWAPP controller - we cannot confirm if the DISCOVERY 
packet is normal after an AP gets an IP. We could test this again if you 
would like - to see what 'good traffic' to the LWAPP controller 
should look like after a device requests an IP.
 
Based on the packet capture, appears that something between the 
controller and AP is not negotiating properly.
 
We have a few questions:
-Is it possible that the AP may have been damaged by the bad PoE switch?
-Is it possible that the netmask that the AP at Station 1 does not 
correspond to the same subnet on the Controller?
-Are the logs on the controller showing any errors?
 
If you would like - we would be more then happy to join a 
conference call with Cisco to further troubleshoot the issue.
 
Please let us know how you would like to proceed.
 
Thank you
 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~>Continuos Ping while WAP is trying to connect to controller
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Pinging 192.168.115.4 with 32 bytes of data:
 
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 192.168.115.4: bytes=32 time<1ms TTL=255
Reply from 192.168.115.4: bytes=32 time<1ms TTL=255
Reply from 192.168.115.4: bytes=32 time<1ms TTL=255
Reply from 192.168.115.4: bytes=32 time<1ms TTL=255
Reply from 192.168.115.4: bytes=32 time<1ms TTL=255
Reply from 192.168.115.4: bytes=32 time<1ms TTL=255
Reply from 192.168.115.4: bytes=32 time<1ms TTL=255
Reply from 192.168.115.4: bytes=32 time<1ms TTL=255
Reply from 192.168.115.4: bytes=32 time<1ms TTL=255
Reply from 192.168.115.4: bytes=32 time<1ms TTL=255
Reply from 192.168.115.4: bytes=32 time<1ms TTL=255
Reply from 192.168.115.4: bytes=32 time<1ms TTL=255
Reply from 192.168.115.4: bytes=32 time<1ms TTL=255
Reply from 192.168.115.4: bytes=32 time<1ms TTL=255
Reply from 192.168.115.4: bytes=32 time<1ms TTL=255
Reply from 192.168.115.4: bytes=32 time<1ms TTL=255
Reply from 192.168.115.4: bytes=32 time=16ms TTL=255
Reply from 192.168.115.4: bytes=32 time=8ms TTL=255
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 192.168.115.4: bytes=32 time<1ms TTL=255
Reply from 192.168.115.4: bytes=32 time<1ms TTL=255
Reply from 192.168.115.4: bytes=32 time<1ms TTL=255
Reply from 192.168.115.4: bytes=32 time<1ms TTL=255
Reply from 192.168.115.4: bytes=32 time<1ms TTL=255
Reply from 192.168.115.4: bytes=32 time<1ms TTL=255
Reply from 192.168.115.4: bytes=32 time<1ms TTL=255
Reply from 192.168.115.4: bytes=32 time<1ms TTL=255
Reply from 192.168.115.4: bytes=32 time<1ms TTL=255
Reply from 192.168.115.4: bytes=32 time<1ms TTL=255
Reply from 192.168.115.4: bytes=32 time=23ms TTL=255
Reply from 192.168.115.4: bytes=32 time=9ms TTL=255
Request timed out.
Request timed out.

           
         

Open in New Window

Select All

Question : DHCP and LWAPP across VPN tunnel

Answer : DHCP and LWAPP across VPN tunnel

Problem resolved with a fireware upgrade on Time Warner Equipment