Windows can't connect to the internet

Fons

Hi Guys,

I've got some new information. When windows users are rejected from connection. If you do a ipconfig /release and ipconfig /renew on a windows machine they sometimes can't find the dhcp server.
But the machines are up in the dhcp leases. so I presume they don't get answers back. or to say the dhcp ack does.not reach the client. does anyone know of extra udp ports that need to be opened to let windows machines accept the dhcp ack.

hope to hear from you, Fons

johnpoz

If you have lost connection, you would not be able to release it on the server even if you released it local - which is why lease would still be listed on server.

When this happens, what do you show for the MAC of the pfsense IP?? Is it there, is it correct? If you have some rouge machine with pfsense dupe IP and that is what answers arp for the IP, then that could explain your issue.

Problem is all devices should be seeing this problem, not just windows machines.

stephenw10

This is an interesting thread. From my point of view at least, not being the person receiving complaints. ;)

If there was a dupe IP on the subnet pretending to be the gateway I would expect to see some 'duplicate IP' errors in the pfSense logs.

Windows machines have been infected with some malware that's rewriting the gateway information? Similar to some of those DNS viruses I read about but have never seen.

Your switch is somehow misconfigured? What sort of switch is it? Layer 3 capabilities?
Malfunctioning switches can cause all manner of odd behaviour.

IPv6 on something causing some alternative route/gateway? That might explain why only windows machines.

Steve

johnpoz

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.

Fons

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

stephenw10

@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

johnpoz

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."

stephenw10

Possibly Windows machines refresh their ARP table faster.
Maybe machines running other OSes are not rebooted every five minutes! ;)

Still seems very odd.

Steve

johnpoz

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 = 60

So that should be 60 seconds?

But doesn't this come into play as well?
net.ipv4.neigh.eth1.locktime = 100

One way to prevent this from happening again would be to create a static arp entry on each machine for the pfsense IP.

Metu69salemi

@johnpoz:

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

Fons

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

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 them

But 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

johnpoz

Why do you think you even need that rule?

So is this dhcp server also having the same IP as your pfsense box?

Fons

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

johnpoz

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.

Fons

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

johnpoz

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.