Forum

Hi,

I am facing a strange issue where only a couple of intranet sites does not open when on wireless but on wired it works fine ,I am even able to ping these websites with success , there is no specific error the page just remains blank . Already updated the WLAN drivers but still no luck, the only possible resolution I could find out it is by reducing the mtu size to 1400 on the user laptop,but looking for a global resolution . its a flat network so wired and wireless users get an ip from the same subnet. Os is Windows XP SP3 nic cards are intel 4965 and Broadcom 802.11 a/b/g .On the packet captures this is what is observed :

Host (10.162.228.29) makes an HTTP request to server (10.176.3.103) with the URL of /go/ess.

The server (10.176.3.103) responds with a HTML redirect <META HTTP-EQUIV="Refresh" CONTENT="0;URL=https://hrsolutions.mot-solutions.com/irj/portal"> and closes the connection.

The host (10.162.228.29) doesn't appear to act on the HTML redirect but instead repeats the first request and receives the same response from the server.

Any suggestions would be very much appreciated .

I've had quite a similar problem in the past but not within the intranet. I resolved it by adjusting the MTU size.

No router ACL's for the AP's connection?

I actually haven't actually tried adjusting the MTU size, I 'll have to file that one way away in the bag of tricks. I did encounter issues with connectivity when on wired vs wireless and what it came down to for me was DNS servers. I had DNS servers entries for my wired that didn't match my wireless. So assuming that destination is not on the same network and your wired controller isn't doing any filtering, I would assume the issue with be at level four our higher of the OSI model.

I experienced a similar issue with this. It had to do with the PMTU calculation. I found some devices will not copy . When a TCP session is established it uses a SYN and SYN ACK to establish the MSS (Maximum Segment Size = MTU - 40). If the frame traverses a network segment that has a lower MTU than the MTU (MSS+40) that was established in the SYN / SYN-ACK then it should fragment the frame unless the DF bit is set. FYI, if you are using a controller with tunnelling and the DF bit is set, your controller will need to fragment or support PMTU calculation to ensure that your client get the proper MSS value in the SYN packet. You client can also enable PMTU Blackhole detection. I believe this is a registry entry in windows XP. Not an easy problem to solve. The best bandaid is reducing the MTU otherwise you need to take a lot of packet captures from each point along the path. PMTU Blackhole detection will turn off the DF bit.

Hi Anees,

Throwing out a few ideas...

I encountered the same problem when adding a new enterprise WLAN to our existing infrastructure awhile back and found it to be a firewall issue. Certain unique applications required random high or unusual ports to be opened, and while we had these ports opened on the firewall going out, we'd failed to open them btwn WLAN and infrastructure or when sourcing from WLAN ip space.

We also had some problems with "HBSS", a security suite in use, because it is an "intelligent" security system. (We had to turn HBSS back into "learn" mode for a week or two while we had test accounts working from the WLAN, then after it "learned" our WLAN network we could turn HBSS back on.)

Another thought is certificates, depending on how your network(s) are configured. (Any CA or issues, are all necessary certificates loaded for the new wireless network?) MTU issues are a potential problem as others have pointed out, but I have not personally encountered that unless I am using crypto in the network, or some other limiting device.

Please let us know what the problem ends up being! =)
Cheers,
Tracy

Still thinking about your issue. This is probably way out there, but also noticing the redirect is from an HTTP to HTTPS site. SSL/443? Can your wifi users hit other secure sites?

any updates on this post?