Windows can't connect to the internet
-
Hmmm I like your IPv6 idea – yup that could be some weird stuff going on there for sure.
But he states he can not ping his pfsense when the problem happens. "the box did not answer to ping either. " I would have to assume he is pinging the ipv4 address. So no matter what his windows machines thought they should be doing with ipv6 as dns or gateway, etc. That should not affect him pinging an IPv4 on the local segment.
He says no issue when connected directly to his pfsense interface - so that really really points to something odd with the switch. But what makes no sense is only window devices being effected?? Unless they are just on specific ports on one blade in the switch?
No details of the switch to work with other than mentioned its a managed one.
-
Hi Guys,
I found the wrongdoer. it happened to be a badly configured iphone. the owner had it configured as an accesspoint with the same gw ip address as the pfsense if. because the problem comes up now and then I thought it had to be such sort of device.
last time the problem appeared I started a wireshark session on both the switches (straight out layer 2, no vlans or other difficulties by the way, spanning tree enabled on the ports) from the monitoring port. on the pfsense if I only can scan for traffic on the incoming port which would not bring me to traffic between the assaulted clients and the bad iphone.
after that I looked up the arp table on one of the assaulted machines and found the bogger right away. the gateway ip had another mac-address as it should be.
a little analysing through the wireshark files and the arp table at pfsense brought me the ip-address and a beautiful hostname which stated his christian name. from there it all went easy.
I'd like to say I shot him but shure he did not know what he was doing.even though a question remains open. how to prevent an open network from such behaviour. could it help to use another ip range, away from the standard 192.168.2.0? or can I have something on pfsense that can recognise such behaviour and prevent the network from it. the way clients work the network has to be as open as possible. I'd like to share your thoughts on this.
thanks anyway for all your advise and thoughts, in the end it has been an interesting few days with loads of stress but also good learning moments and points. regards Fons -
I found the wrongdoer. it happened to be a badly configured iphone.
Wow. I did not expect that. ::)
I take it your wifi is on the same subnet as the affected clients then? That's another good reason to isolate wireless clients.
There were no 'duplicate IP' errors in the pfSense logs? Interesting.
Using an slightly unusual IP range would certainly have at least helped you trace the problem. clients would have been given a completely different address by the iphone if it was configured to do so.
If you have your wifi bridged to your wired lan through two pfSense interfaces you can filter DHCP requests from wired to wifi. This would stop a rouge DHCP server on wifi but perhaps not a dupe gateway. Much more likely to either not be a problem or show log errors since all traffic is processed by pfSense. That may present a network bottleneck though.Good to know anyway. Thanks for coming back with the info. :)
Steve
-
What doesn't make sense is why none of the other devices were affected.
If you had a device saying hay my IP address is the same as pfsense lan IP (your gateway) Then yes its possible that devices when they arp for the gateway IP they would get that mac and try to use it as their gateway.
but what doesn't make sense in that scenario is that only your window machines were affected. Since you stated all devices were on the same segment and such. All devices arping should of intermittently either gotten the correct mac for the IP, or the bad mac for the iphone. Maybe they were and only windows users reported the issue?
See my comment from quite a few posts back
" Now its possible you have a box that has duplicate IP of your pfsense IP.. So when you arp for the mac of the pfsense IP you get this other box, etc. But that should effect ALL machines on the network, not just windows machines."
-
Possibly Windows machines refresh their ARP table faster.
Maybe machines running other OSes are not rebooted every five minutes! ;)Still seems very odd.
Steve
-
Very true!! I believe windows would be some random time between 15 and 45 seconds unless modified
http://support.microsoft.com/kb/949589
on linux, for example ubuntu I show this
net.ipv4.neigh.eth1.gc_stale_time = 60So that should be 60 seconds?
But doesn't this come into play as well?
net.ipv4.neigh.eth1.locktime = 100One way to prevent this from happening again would be to create a static arp entry on each machine for the pfsense IP.
-
One way to prevent this from happening again would be to create a static arp entry on each machine for the pfsense IP.
And/Or create dhcp snooping protection from switches
-
Hi guys,
thanks for all your thoughts on this, and thank Johnpoz, for the interesting lecture about arp and windows. I surely don't understand why microsoft always do things different as standard rfc's mention and are able to get their own rules packed in slightly different rfc's. most of the time they create vulnerabilities, if not reboot every 5 minutes ;-)
anyway it seems I do have some studying to do the coming days to get some working measures on the network segment. I'll let you know what I will get working.the guy with the iphone had his hotspot settings enabled with indeed the same gateway address and all things hotspots need to do enabled like handing out ip addresses, and so on. he stated he wasn't aware but I think his battery should have been empty every few hours.
anyway, maybe a little bit early but I start the weekend after last week's stress and I hope the see you all again soon, bye for now, Fons
-
Hi Guys,
it happened again, last friday and this morning. but another macaddress acted as or was reached as a dhcp server. not the same macaddress from last thursday.
it seems this always starts at about 9:30, coming in time for most of the workers and it stops after 30 to 60 minutes.
this morning I was to late to start wireshark to intercept all udp traffic. I'll give it a go tomorrow.
what I do think now that this isn't a badly configured smartphone or computer but some malware capable of acting like a dhcp server to attrack others on the same network. A network virus maybe.
One problem to find it is the fact that I don't have access to all the hardware on the network. The only I provide on this network segment is connection and bandwith, the only hardware I'm responsable for is the firewall, two switches and a printer. As far as I can see there's nothing misconfigured in any of those.
So no chance to alter arp tables or add static arp for me. I can only advise themBut a question came up: on PfSense I got a floating rule on all internal segments for udp on 67 & 68, which is granted to and from any.
I had a equal rule working on my former shorewall and it always worked fine. should I narrow the functionality for this rule?
As far as I can see it would not help against an extra dhcp server on the same network segment, especially not when it is spoofing macaddresses or acting as the gateway address.any clues?
regards, Fons
-
Why do you think you even need that rule?
So is this dhcp server also having the same IP as your pfsense box?
-
Hi Johnpoz,
this dhcp server is indeed using the same ip-adres as the pfsense box
the rule is necessary because we leave all ports closed unless needed.
fons
-
I do not believe it is, since its one of those rules in the default set
http://doc.pfsense.org/index.php/How_can_I_see_the_full_PF_ruleset
So on mine if I do a pfctl -sa I see these rules which I did not create!
pass in quick on em0 inet proto udp from any port = bootpc to 255.255.255.255 port = bootps keep state label "allow access to DHCP server"
pass in quick on em0 inet proto udp from any port = bootpc to 192.168.1.253 port = bootps keep state label "allow access to DHCP server"
pass out quick on em0 inet proto udp from 192.168.1.253 port = bootps to any port = bootpc keep state label "allow access to DHCP server"So your specific rules become pointless? Since dhcp is part of the default rules.
Kind of wish the interface showed all the rules!!! And just locked the default rules like the above from delete. Kind of need them if your running a dhcp server on pfsense ;) Which sadly some users would not understand and not create the rules if not done for them, and then wonder why their dhcp server didn't work.
btw - just for clarity, I picked .253 as my pfsense lan IP, because many devices default to .1 or .254 – so you run into issues like what your seeing when you use a common IP. 192.168.2 is very common as well for many routers, and such. I personally would change your pfsense lan IP to not be on the ends and or even change your segment to be less common. 192.168.3 is not used by any devices that I recall for example.
-
Hi Johnpoz,
I wasn't aware of all the default rules on the pfsense box. apparently they come up when you activate a service. and indeed, it would be nice if default rules would be visible in the rule sets.
Used as I was to shorewall where I had to open up every specific port. That's why I call myself a newbie to pfsense, but learning as hell. ;-)I will disable the specific rule tonight and add some testing.
thanks, Fons
-
that would solve your issues if you have rouge dhcp server on the network. Just the that the rule is not required and keeps the listing cleaner. No reason for duplicate rules, etc.
