Can't reach specific website only from wireless (wireless not on pfsense box)
-
I have just installed pfsense ver 1.2.3. I have it set up with 2 interfaces - WAN using dhcp and LAN with no DHCP. I have a windows server handing out dhcp and use opendns for my dns servers.
On my lan I have 2 access points. When attached to these I can not reach a few specific sites such as mozilla.com, snort.org and netflix.com. The pages get stuck loading (page loading message at the bottom of the page). Of coarse I thought it was my laptop or wireless.
- I could reach these site from other pcs.
- I could also reach these sites from my laptop if I plug in an ethernet cable.
- I did not see any logs on the pfsense box pertaining to this.
- I have the same results when attached to ether of my access point (one a linksys with dd-wrt and a d-link)
- I tried with no encryption
- I was running ubuntu, tried a fedora boot disk - same issue
- another laptop and my roku experience the same issues when on the wireless
- wireless is on the same vlan and subnet as my wired machines
- I just set up my linksys as my router again and these sites work fine now.
- I reset the pfsense box to remove my custom settings and extra packages - still no goodSome how these sites are getting blocked only when I am on my wireless devices
Thanks for the help
-
Your wireless clients are correctly resolving the IP addresses of the names mozilla.com, snort.org and netflix.com?
A traceroute (tracert on a windows system) shows the expected chain of intermediate systems to your ISP's router on attempting to access one of these "blocked sites"? (Compare with a site you can access. I presume you can access some sites!)
wireless is on the same vlan and subnet as my wired machines
I presume this means your wireless access points are behaving as LAN bridges rather than routers! Correct?
- I just set up my linksys as my router again and these sites work fine now.
- I reset the pfsense box to remove my custom settings and extra packages - still no good
You replaced the pfSense box by your previously used Linksys router, then replaced the Linksys by pfSense? Did you need to adjust your Windows server to tell its DHCP clients that they should use a different gateway? Did the clients perform any necessary steps to get the correct view of the gateway? (For example, if the pfSense box had the same LAN IP address as the Linksys its MAC address would certainly be different so, for a time, wireless clients would be unable to access the gateway because they would be using the stale MAC address.)
- I just set up my linksys as my router again and these sites work fine now.
-
Your wireless clients are correctly resolving the IP addresses of the names mozilla.com, snort.org and netflix.com?
Yes they are - I compared with both routers (linksys and pfsense). I can ping with both routers.
I presume this means your wireless access points are behaving as LAN bridges rather than routers! Correct?
Yes they are lan bridges. The I normally connect to does not change - it is only an access point.
Did you need to adjust your Windows server to tell its DHCP clients that they should use a different gateway? Did the clients perform any necessary steps to get the correct view of the gateway?
I did not change dhcp. I gave pfsense the same gateway address as the linksys and gave the linksys and new address and turned off it's wan connection. The mac address should only be stored a couple minutes and is not affecting the results as I am resolving the correct ip's and the traceroutes are giving the correct results.
Thanks for the reply.
-
Tried the beta with the same results.
-
Sounds like its a HTTP or TCP specific problem particular to the path through the wireless AP.
You mentioned VLANs - they require some additional header bytes reducing the space available for data. Maybe you are losing a packet in the HTTP response because its too long. It might help to do a tcpdump on a few nterface to verify that large packets are getting to your client or to the wireless AP. On this, the last time I looked, it wasn't clear from the documentation whether or not tcpdump showed packets that were discarded by the NIC driver. That is, a packet that is discarded by the NIC driver might still appear in the trace on the sending side even though it doesn't make it to the wire.