Cannot access pfsense from certain pcs
-
Yeah assuming what people do normally means what ass u me :)
If using pfsense as dns, makes sense to use IP since what if pfsense is not working correctly.. I'm thinking they are trying https and some of there boxes are not likely the cert or not seeing crl, etc.
Really helpful to know what error they are getting vs vague "cannot access the web interface"
As to no proxy – Did he actually verify in the browser settings? Doubt it to be honest.
Quite possible machines are all infected running their web traffic through some proxy on the net ;) We really have NOTHING to work with here.
see my post below for the error I am getting.
and with regards to the proxy.
Yes I am sure as I set the PCs up. Thanks for your concern and condescending tone however it really helps. 8) -
And are you using HTTPS?
I have the same error - because I am not running on https
But use http and works fine
-
yes I only use HTTPS
-
Well for some reason your browser doesn't like the cert, but I would think that would be a different error. Or can not get there for some reason.. Have you tried http, its quite possible your not actually using https ;) Which would seem like a logical thing to verify.
Have you sniffed at pfsense to see if request gets there? You have any odd lan firewall rules?
You get the same type of error in different browser?
-
Well for some reason your browser doesn't like the cert, but I would think that would be a different error. Or can not get there for some reason.. Have you tried http, its quite possible your not actually using https ;) Which would seem like a logical thing to verify.
Have you sniffed at pfsense to see if request gets there? You have any odd lan firewall rules?
You get the same type of error in different browser?
It is using https 100% sure.
http has the same effect - no gui access.
and just to test I even put in a LAN rule to allow all traffic everywhere while testing this out. no change -
Well for some reason your browser doesn't like the cert, but I would think that would be a different error. Or can not get there for some reason.. Have you tried http, its quite possible your not actually using https ;) Which would seem like a logical thing to verify.
Have you sniffed at pfsense to see if request gets there? You have any odd lan firewall rules?
You get the same type of error in different browser?
It is using https 100% sure.
http has the same effect - no gui access.
and just to test I even put in a LAN rule to allow all traffic everywhere while testing this out. no changeAnd yes tested it on IE…same thing
-
and just to test I even put in a LAN rule to allow all traffic everywhere while testing this out. no change
Errr… and the rules in place before would be?! Diagnostics - States - Reset states or reboot.
-
and just to test I even put in a LAN rule to allow all traffic everywhere while testing this out. no change
Errr… and the rules in place before would be?! Diagnostics - States - Reset states or reboot.
well by default I don't allow all kinds of traffic out - no point.
rebooted the firewall already…did it again and still no access apart from the same 3 PCs!
-
Well, I'd suggest to post the rules and producing some basic diagnostics, such as ping/traceroute to the pfS IP, since we obviously are getting nowhere and there's apparently a lot of information hidden behind the scenes. Also there are these logs available on the firewall for a good reason. :-*
-
Did you sniff at pfsense? diag packet capture, or simple tcpdump from ssh or console.
This is what I would do to verify traffic actually gets there.
Again - maybe I missed it.. You can route your internet traffic through pfsense - just not load the web gui?
As dok mentions – lets see pings, traceroute and the sniff at pfsense showing the connection from your browser.. Until we verify that pfsense saw the request and answered.. Its a browser/pc issue where the traffic never even gets to pfsense.
-
Did you sniff at pfsense? diag packet capture, or simple tcpdump from ssh or console.
This is what I would do to verify traffic actually gets there.
Again - maybe I missed it.. You can route your internet traffic through pfsense - just not load the web gui?
As dok mentions – lets see pings, traceroute and the sniff at pfsense showing the connection from your browser.. Until we verify that pfsense saw the request and answered.. Its a browser/pc issue where the traffic never even gets to pfsense.
Right I don't understand what it's doing here… TCP dump:
14:17:18.703735 ARP, Request who-has 192.168.0.254 tell 192.168.0.22, length 46 14:17:22.061901 IP 192.168.0.180 > 192.168.0.254: ICMP echo request, id 16488, seq 1, length 64 14:17:23.061233 IP 192.168.0.180 > 192.168.0.254: ICMP echo request, id 16488, seq 2, length 64 14:17:24.060639 IP 192.168.0.180 > 192.168.0.254: ICMP echo request, id 16488, seq 3, length 64 14:17:25.060269 IP 192.168.0.180 > 192.168.0.254: ICMP echo request, id 16488, seq 4, length 64 14:17:26.059758 IP 192.168.0.180 > 192.168.0.254: ICMP echo request, id 16488, seq 5, length 64 14:17:37.275390 IP 192.168.0.198.59671 > 192.168.0.254.80: Flags [SEW], seq 3141690413, win 8192, options [mss 8960,nop,wscale 8,nop,nop,sackOK], length 0 14:17:37.275799 IP 192.168.0.198.59671 > 192.168.0.254.80: Flags [.], ack 1145112448, win 525, length 0 14:17:37.318563 IP 192.168.0.198.59672 > 192.168.0.254.443: Flags [SEW], seq 775419729, win 8192, options [mss 8960,nop,wscale 8,nop,nop,sackOK], length 0 14:17:37.318819 IP 192.168.0.198.59673 > 192.168.0.254.443: Flags [SEW], seq 4237069878, win 8192, options [mss 8960,nop,wscale 8,nop,nop,sackOK], length 0 14:17:37.318948 IP 192.168.0.198.59672 > 192.168.0.254.443: Flags [.], ack 3506288764, win 525, length 0 14:17:37.319084 IP 192.168.0.198.59673 > 192.168.0.254.443: Flags [.], ack 2176993790, win 525, length 0 14:17:37.319222 IP 192.168.0.198.59672 > 192.168.0.254.443: Flags [P.], ack 1, win 525, length 156 14:17:37.319560 IP 192.168.0.198.59673 > 192.168.0.254.443: Flags [P.], ack 1, win 525, length 156 14:17:44.080156 ARP, Request who-has 192.168.0.254 (00:0c:29:e0:65:b7) tell 192.168.0.2, length 46 14:17:52.552522 IP 192.168.0.198.59671 > 192.168.0.254.80: Flags [F.], seq 0, ack 1, win 525, length 0 14:17:52.552778 IP 192.168.0.198.59671 > 192.168.0.254.80: Flags [.], ack 2, win 525, length 0 14:17:53.265557 ARP, Request who-has 192.168.0.254 (00:0c:29:e0:65:b7) tell 192.168.0.30, length 46 14:18:07.304040 IP 192.168.0.198.59672 > 192.168.0.254.443: Flags [F.], seq 156, ack 1, win 525, length 0 14:18:07.306002 IP 192.168.0.198.59673 > 192.168.0.254.443: Flags [F.], seq 156, ack 1, win 525, length 0 14:18:07.604903 IP 192.168.0.198.59672 > 192.168.0.254.443: Flags [F.], seq 156, ack 1, win 525, length 0 14:18:07.607890 IP 192.168.0.198.59673 > 192.168.0.254.443: Flags [F.], seq 156, ack 1, win 525, length 0 14:18:08.203665 IP 192.168.0.198.59673 > 192.168.0.254.443: Flags [F.], seq 156, ack 1, win 525, length 0 14:18:08.204678 IP 192.168.0.198.59672 > 192.168.0.254.443: Flags [F.], seq 156, ack 1, win 525, length 0 14:18:09.403167 IP 192.168.0.198.59673 > 192.168.0.254.443: Flags [F.], seq 156, ack 1, win 525, length 0 14:18:09.404194 IP 192.168.0.198.59672 > 192.168.0.254.443: Flags [F.], seq 156, ack 1, win 525, length 0 14:18:11.803351 IP 192.168.0.198.59672 > 192.168.0.254.443: Flags [F.], seq 156, ack 1, win 525, length 0 14:18:11.809324 IP 192.168.0.198.59673 > 192.168.0.254.443: Flags [F.], seq 156, ack 1, win 525, length 0 14:18:14.367613 ARP, Request who-has 192.168.0.254 (00:0c:29:e0:65:b7) tell 192.168.0.141, length 46 14:18:16.598579 IP 192.168.0.198.59673 > 192.168.0.254.443: Flags [F.], seq 156, ack 1, win 525, length 0 14:18:16.606623 IP 192.168.0.198.59672 > 192.168.0.254.443: Flags [F.], seq 156, ack 1, win 525, length 0 14:18:21.253366 ARP, Request who-has 192.168.0.254 (00:0c:29:e0:65:b7) tell 192.168.0.30, length 46 14:18:22.295438 IP 192.168.0.198.59672 > 192.168.0.254.443: Flags [.], ack 1, win 525, length 1 14:18:22.304426 IP 192.168.0.198.59673 > 192.168.0.254.443: Flags [.], ack 1, win 525, length 1 14:18:26.200000 IP 192.168.0.198.59672 > 192.168.0.254.443: Flags [R.], seq 157, ack 1, win 0, length 0 14:18:26.201967 IP 192.168.0.198.59673 > 192.168.0.254.443: Flags [R.], seq 157, ack 1, win 0, length 0 14:18:29.997006 ARP, Request who-has 192.168.0.254 (00:0c:29:e0:65:b7) tell 192.168.0.200, length 46 -
I only see one way traffic there.. I assume 192.168.0.198 is your client that is not working.. Who is .180 sending the pings?
From that trace pfsense at 192.168.0.254 is not answering anybody i only see traffic going to it - no answers.
If you notice when I ping it.. or hit it via http there is an answer
08:27:24.849369 IP 192.168.1.100 > 192.168.1.253: ICMP echo request, id 1, seq 824, length 40
08:27:24.849445 IP 192.168.1.253 > 192.168.1.100: ICMP echo reply, id 1, seq 824, length 4008:27:15.925462 IP 192.168.1.100.55443 > 192.168.1.253.80: tcp 0
08:27:15.925704 IP 192.168.1.253.80 > 192.168.1.100.55443: tcp 0I don't even see it answering arps for its IP?
4:18:14.367613 ARP, Request who-has 192.168.0.254 (00:0c:29:e0:65:b7) tell 192.168.0.141, length 46
14:18:21.253366 ARP, Request who-has 192.168.0.254 (00:0c:29:e0:65:b7) tell 192.168.0.30, length 46
14:18:29.997006 ARP, Request who-has 192.168.0.254 (00:0c:29:e0:65:b7) tell 192.168.0.200, length 46Where are the answers?
like this
08:27:20.418236 ARP, Request who-has 192.168.1.253 tell 192.168.1.8, length 46
08:27:20.418238 ARP, Reply 192.168.1.253 is-at 00:50:56:00:00:02, length 28So 00:0c:29, what virtual machines are involved here - is pfsense running on VM? 00:0c:29 is vmware.
-
I have seen mine hang like that before - but only when the WAN wasn't getting an internet connection. Are you connected to the internet?
I also would not put it beyond the realm of possibility that all of your non-working machines are infected. Think about it. If they were infected and all your traffic was getting proxied, they would have no way to proxy back to your web gui. -
The capture was only capturing traffic in 1 direction - my mistake.
And I fix the issue.
it was to do with my esxi host and the FW LAN interface having an incorrect MTU.
I use jumbo frames throughout (apart from those 3 machines as 2 are on wireless and 1 is on a switch which does not allow jumbo frames) so they always sent small / fragmented packets to the Firewall.
But the others were probably sending oversized frames which the interface on the ESXI host wasn't configured for.
-
Probably your first line of this post should have been "My pfsense is in esxi".
Is it working now?
-
Probably your first line of this post should have been "My pfsense is in esxi".
Is it working now?
yep fixed.
-
Thanks for the help all :)
-
Well - Thats an interesting problem you had there.
-
Probably your first line of this post should have been "My pfsense is in esxi".
Is it working now?
yep fixed.
Good. Enjoy pfSense. :D
-
Yup interesting issue.. Made so because of the original lack of information about network and setup. ;)
Some basics of the setup, what flavor of pfsense being run, hardware its on. Running nonstandard frame size is a biggy if you ask me. They have yet to be adopted by IEEE have they?
I personally don't see the point with jumbo on most local networks, more overhead and issues with setting it up than performance gains in your typical lan. And if your running good nics with LSO doesn't that kind of remove the whole benefit of less cpu work, etc.
They might be useful on a segment designed to move data, like a storage or backup segment.. But normal everyday user traffic - IMHO they are just more hassle than they are worth.
But glad we finally got your issues sorted.
