Cannot access a single specific website
-
When I go to the following site and try to click on one of the states it switches to https and queries a database then it just times out and nothing is returned.
http://hudhomestore.com/HudHome/Index.aspx
The secure site it is trying to access is:
https://hudhomestore.secureportalk.net/HUD/PropertySearchResult.aspx?sState=AZ
If I plug directly into my ISP then it works fine. I can even tracert to hudhomestore.secureportalk.net no problem.
When I try to ping or tracert from the pfsense webgui to hudhomestore.secureportalk.net it resolves the correct IP 209.235.109.168 but I'm getting 100% packet loss.
Same ISP, IP, and computer when I connect directly then it works when I go thru pfsense it can't even ping.
I've checked firewall and nat rules but nothing seems to be blocking 209.235.109.168. If I'm pinging directly from the webgui I shouldn't even be using NAT correct?
I've tried adding a rule to specially allow traffic and it still doesn't work.
What's blocking it? What should I try next?
Thanks
-
http://doc.pfsense.org/index.php/Unable_to_Access_Some_Websites
-
or in addition try to clone your mac-address
-
In reference to the doc posted by Perry:
1. WAN gateway is reachable and set to the proper address
2. Subnet mask is correct everywhere
3. I left the MTU field blank to default to 1500 which didn't help. I also tried setting it at 576 no help.
4. Traceroute to any destination from the webgui shows the first hop timing out (my gateway doesn't respond) and then the second hop shows my ISP's router. When I tracert to that address though every hop times out. I would expect the first hop to time out like every other know good but the second and on also time out. I suspect it is dropping at the pfsense box to gateway hop. I've tried connecting straight into the gateway and that works so I think it is with pfsense.
5. I'm using 1.2.3-RELEASE
6. Tried disabling hardware checksums and that didn't help either.In reference to Metu69salemi:
I tried cloning the MAC of my desktop and laptop but neither helped.Thanks for all the help. What next?
-
Have you taken packet captures? what those say?
-
No packet captures. Is that a feature of pfsense? Or do I need a third party util? Has someone already written up how to do it?
thx
-
inbuild feature: Diagnostics: Packet capture
-
When I capture packets I get no traffic on the WAN.
On the LAN I get the following type of traffic repeated:
11:54:46.253055 00:1b:fc:e6:f4:72 > 00:16:76:6d:5a:10, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 128, id 30264, offset 0, flags [DF], proto TCP (6), length 52) 192.168.7.21.59651 > 209.235.109.168.443: S, cksum 0xbe7f (correct), 980313112:980313112(0) win 8192 <mss 1460,nop,wscale="" 2,nop,nop,sackok="">11:54:46.253151 00:bd:4a:4c:00:00 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 209.235.109.168 tell 192.168.1.1
11:54:46.253495 00:1b:fc:e6:f4:72 > 00:16:76:6d:5a:10, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 128, id 30265, offset 0, flags [DF], proto TCP (6), length 52) 192.168.7.21.59652 > 209.235.109.168.443: S, cksum 0x8686 (correct), 145346005:145346005(0) win 8192 <mss 1460,nop,wscale="" 2,nop,nop,sackok="">11:54:46.362824 00:1b:fc:e6:f4:72 > 00:16:76:6d:5a:10, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 128, id 30273, offset 0, flags [DF], proto TCP (6), length 52) 192.168.7.21.59653 > 209.235.109.168.443: S, cksum 0x82c3 (correct), 3976260927:3976260927(0) win 8192 <mss 1460,nop,wscale="" 2,nop,nop,sackok="">11:54:48.517232 00:1b:fc:e6:f4:72 > 00:16:76:6d:5a:10, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 128, id 30282, offset 0, flags [DF], proto TCP (6), length 52) 192.168.7.21.59654 > 209.235.109.168.443: S, cksum 0x28a8 (correct), 1912652378:1912652378(0) win 8192 <mss 1460,nop,wscale="" 2,nop,nop,sackok="">11:54:48.517318 00:bd:4a:4c:00:00 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 209.235.109.168 tell 192.168.1.1
11:54:48.517605 00:1b:fc:e6:f4:72 > 00:16:76:6d:5a:10, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 128, id 30283, offset 0, flags [DF], proto TCP (6), length 52) 192.168.7.21.59655 > 209.235.109.168.443: S, cksum 0x4356 (correct), 748219667:748219667(0) win 8192 <mss 1460,nop,wscale="" 2,nop,nop,sackok="">11:54:49.246700 00:1b:fc:e6:f4:72 > 00:16:76:6d:5a:10, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 128, id 30285, offset 0, flags [DF], proto TCP (6), length 52) 192.168.7.21.59652 > 209.235.109.168.443: S, cksum 0x8686 (correct), 145346005:145346005(0) win 8192 <mss 1460,nop,wscale="" 2,nop,nop,sackok="">11:54:49.246739 00:bd:4a:4c:00:00 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 209.235.109.168 tell 192.168.1.1
11:54:49.246751 00:1b:fc:e6:f4:72 > 00:16:76:6d:5a:10, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 128, id 30286, offset 0, flags [DF], proto TCP (6), length 52) 192.168.7.21.59651 > 209.235.109.168.443: S, cksum 0xbe7f (correct), 980313112:980313112(0) win 8192 <mss 1460,nop,wscale="" 2,nop,nop,sackok="">11:54:49.356709 00:1b:fc:e6:f4:72 > 00:16:76:6d:5a:10, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 128, id 30287, offset 0, flags [DF], proto TCP (6), length 52) 192.168.7.21.59653 > 209.235.109.168.443: S, cksum 0x82c3 (correct), 3976260927:3976260927(0) win 8192 <mss 1460,nop,wscale="" 2,nop,nop,sackok="">11:54:51.519880 00:1b:fc:e6:f4:72 > 00:16:76:6d:5a:10, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 128, id 30289, offset 0, flags [DF], proto TCP (6), length 52) 192.168.7.21.59654 > 209.235.109.168.443: S, cksum 0x28a8 (correct), 1912652378:1912652378(0) win 8192 <mss 1460,nop,wscale="" 2,nop,nop,sackok="">11:54:51.519928 00:bd:4a:4c:00:00 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 209.235.109.168 tell 192.168.1.1
11:54:51.519940 00:1b:fc:e6:f4:72 > 00:16:76:6d:5a:10, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 128, id 30290, offset 0, flags [DF], proto TCP (6), length 52) 192.168.7.21.59655 > 209.235.109.168.443: S, cksum 0x4356 (correct), 748219667:748219667(0) win 8192 <mss 1460,nop,wscale="" 2,nop,nop,sackok="">11:54:55.250153 00:1b:fc:e6:f4:72 > 00:16:76:6d:5a:10, ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 128, id 30293, offset 0, flags [DF], proto TCP (6), length 48) 192.168.7.21.59652 > 209.235.109.168.443: S, cksum 0x9a8f (correct), 145346005:145346005(0) win 8192 <mss 1460,nop,nop,sackok="">11:54:55.250209 00:bd:4a:4c:00:00 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 209.235.109.168 tell 192.168.1.1I think maybe the arp who-has 209.235.109.168 tell 192.168.1.1 is the problem because my pfsense is on 192.168.7.1, I'm not using 192.168.1.1 anywhere. I don't exactly understand what's happening or how to fix this though.
THX</mss></mss></mss></mss></mss></mss></mss></mss></mss></mss></mss>
-
Well there is a problem where i can't help any more. Hopefully someone smarter will aid
-
I think maybe the arp who-has 209.235.109.168 tell 192.168.1.1 is the problem because my pfsense is on 192.168.7.1, I'm not using 192.168.1.1 anywhere. I don't exactly understand what's happening or how to fix this though.
Packet capture through tcpdump (I presume packet capture through the web GUI is similar) sets the interface into promiscuous mode therefore it captures any traffic going by on the LAN segment.
Perhaps you can track down the system sending the unexpected ARP requests through its MAC address: 00:bd:4a:4c:00:00 The pfSense command # arp -a -n will give a list of the currently active (on pfSense) MAC address: IP address mappings.
What is the subnet mask on your LAN interface? (Are 192.168.7.1 and 192.168.1.1 on the same subnet?)
-
I used arp -a -n to list the currently active and 00:bd:4a:4c:00:00 is not on the list. I tried to look up the manufacturer for 00:bd:4a and I'm not finding it in the online databases. I see the requests in the capture still but I have no idea what machine that is coming from.
My LAN is 192.168.7.1 / 24
BTW…I created a static route for my LAN to send 209.235.109.168/32 traffic to my gateways ip and it seems to work.
This phantom traffic is weird though and I would like to track down the problem because I don't want to have to manage static routes for any sites that don't work (that's what DNS is for).
THX
-
I tried to look up the manufacturer for 00:bd:4a and I'm not finding it in the online databases.
Confirmed, this mf'rer is not registered in the IEEE database.
Can that be some kind of exploit/malware gone wrong on one of the hosts in your network?I see the requests in the capture still but I have no idea what machine that is coming from.
Disconnect hosts/segments from your network until there's no ARP answer anymore.
Really interested in the outcome of this!
-
The 00:bd:4a:4c:00:00 MAC is for TAP0. I guess pfSense assigned it TAP0 when I created an old OVPN configuration. The Status > Interfaces page does not show TAP interfaces however if you goto the Interfaces > assign page and look in a drop down box then you can see it. (You could also just run ifconfig from the diagnostics > command page and see it).
192.168.1.1 was in an old OVPN configuration. Removing that configuration fixed the problem.
I'm glad it's working as it should but…
How does an OVPN configuration mess up ARP such that a single website doesn't load but everything else apparently works fine? BTW - This is all from the LAN clients not using OVPN and no active OVPN connections.
The internal workings of pfSense are beyond me. Thanks too all those that helped get me here.
-
The 00:bd:4a:4c:00:00 MAC is for TAP0. I guess pfSense assigned it TAP0 when I created an old OVPN configuration.
Is there such a thing like a "private MAC range" similar to the privat IP subnets?
Where does pfSense pull the MAC from?