What is going on here?
-
Can anyone figure this out for me? I run my own DHCP server external to my PFSense server, I know this range showing up is un-allocated and it is trying to access a broadcast address. The 169.254.217.204:Random Ports is showing up as on either LAN1 or LAN2 and the addresses are changing. All are trying to reach 239.255.255.250:1900, I am confused as to why I am seeing these in my logs. See screen shot.
There is also a bunch of IPV6 addresses showing up, I do not use IPV6 on any of my systems as of yet….
-
"Can anyone figure this out for me? I run my own DHCP server external to my PFSense server, I know this range showing up is un-allocated and it is trying to access a broadcast address. The 169.254.217.204:Random Ports is showing up as on either LAN1 or LAN2 and the addresses are changing. All are trying to reach 239.255.255.250:1900, I am confused as to why I am seeing these in my logs. See screen shot."
Isn't 169.254.217.204 a default address for when an ip address cannot be found either due to a network misconfiguration or possibly because you have bogons checked and you're just seeing default traffic for when the router boots up? I think it does have something to do with DHCP though and the way it says "hey who is this and how are we connecting today?" If there isn't an answer then you get 169.254.217.204 which is an address going to nowhere but it's usually just part of the DHCP check for when it looks up your ISP address and it does not get a response . I think it's just a check that happens every time you reboot. Those numbers show up quite a bit I believe. The 239.255.255.250:1900 is just an address with a multicast port. Is UPNP enabled by any chance?
They say when you see the 169.254.217.204 address that something is broken. You say the DHCP server is external? Like is it far away? Maybe there was a power outage and it just rebooted itself? usually the best way to solve a problem is to just open up a drawing program and draw your network. It will make more sense then and you wouldn't believe how many problems you could solve by doing that.
Check out these links:
https://askleo.com/why_cant_i_connect_with_a_169254xx_ip_address/
https://wiki.wireshark.org/SSDP
They have more details.
If there isn't anything really wrong, you might just have to adjust your logs and only have important things checked. Because otherwise that 239. number especially is going to run indefinitely if there is a Discovery(SSDP)/UPNP action going on which could just be it checking itself over and over.
the picture I made has nothing to do with this but it's just a demonstration of how you can make things clearer just by drawing it out.
-
Thanks for the reply, I have a lot of equipment on my network, as most do anymore. I use DHCP to assign a reservation to my equipment, that way I know what is on my network and what is alive.
The DHCP is on my local network, from the same server that deals with my DNS. I understand the address range is for something that is not being issued an address, but I have nothing on my network that does not have an address.
This has only started up recently, with no changes to my PFSense, it just started a week or so ago. UPNP, I am unsure, I have never turned it on as it has security issues.
-
**"Thanks for the reply, I have a lot of equipment on my network, as most do anymore. I use DHCP to assign a reservation to my equipment, that way I know what is on my network and what is alive.
The DHCP is on my local network, from the same server that deals with my DNS. I understand the address range is for something that is not being issued an address, but I have nothing on my network that does not have an address.
This has only started up recently, with no changes to my PFSense, it just started a week or so ago. UPNP, I am unsure, I have never turned it on as it has security issues."**
Welcome:) I enjoy doing this. Even if I'm not right 90% of the time. I do try lol.
So it is on your local network. I could be totally wrong on this but it might just be background noise for when it's doing discovery type actions. See what happens if you disable bogons in the logging options. I know that at one point it was bugged and bogons would show up anyways but I believe it's fixed now. It might not even be called that. I really need to install pfsense again. But it does have something to do with certain logging that most disable. You want to see stuff that's blocked by the default rule. But the 239's and the 169s will always show up with bogons checked. It's really nothing to worry about as long as everyone is able to connect. Get any complaints about connectivity from customers?
-
I only have bogons enabled at the WAN interface, my local interfaces are unchecked. Maybe something was enabled by mistake and I need to go over the log settings again to verify.
I appreciate your input.
-
"I only have bogons enabled at the WAN interface, my local interfaces are unchecked."
I believe that it will still show up with the source address being the Lan with the 169.254 address because that is just your system using discovery by way of multicast which does use the 239 address. So it comes from your machine with 169 as the source and the destination is still your machine but it's going out and clipping the WAN to check for an address. But it will still show up on the Lan interface logs because that is the interface that initiated the discovery action. I suppose that we could call it a never ending loop. One other reason for that particular log is because computers on your network are trying to talk to each other. Just for discovery purposes and possibly some file sharing. Pfsense is great at blocking things like discovery though especially if you didn't enable UPNP. See I'm thinking through this. But even if you didn't enable it, maybe you have devices that are trying to communicate that are on your network or even ones that are in your house and are excluded from your network. Our devices nowadays are so nosey. Especially apple devices like Iphones and Ipads. You name it. They want to know what you have lol. Here is another attempt at my drawing. I need practice. I may not be doing it right but eventually the answer will appear.
-
Here is the thing 169.254 is APIPA… Many devices will use this even when they have a valid IPv4 or IPv6 address.. I would track down the devices by mac address.. Do some simple sniffing on pfsense to find out mac that is sending the SSDP (port 1900) to multicast, Or they all could be announcements... Sniff them and take a look see..
For example.. My directv dvr and my directv wireless bridge like to use a 169.254 address..
See attached from my directv wireless bridge - using 169.254 on its br0, see its mac is different then the quick sniff I did to catch some traffic that my dvr is sending out..
As to your IPv6, many devices default to having ipv6 enabled be it your using it or not.. if you have no plans on using it - then for sure you can turn it off.. Windows machine is a simple reg key simple way.
reg add hklm\system\currentcontrolset\services\tcpip6\parameters /v DisabledComponents /t REG_DWORD /d 255
Linux OS will vary, But if your not wanting to see the blocks in your log, you can disable that.. I don't see any of that blocked traffic in my pfsense. You could also if you have as smart/managed switch enable igmp snooping that would block a lot of that noise from getting to pfsense.
-
Don't start fooling with your registry over that. It's just noise. That's all it is.
notice how his first post says this
"There is also a bunch of IPV6 addresses showing up, I do not use IPV6 on any of my systems as of yet…."
"I would track down the devices by mac address" waste of time
It's just noise. It's always going to be there.
The thing is that if you start messing with the registry over a little issue like that, bigger problems are usually on the horizon. Let's say he adds that key. It might not break anything right away but down the line it could and then he might not even remember what key was altered. Registry backups don't always work. Also if there was a system restore point saved that he needed. Consider it gone because it won't come back right. because it can't due to a registry key that is different from the actual save backup. I've been through this.
Oh yeah thanks for the bad karma by the way John. Always a classy individual who was really mean to quite a few users in the past. But anything from you to me is just garbage anyways. I did notice how you're starting to be nicer to people(thanks to me) and then you want to take it out on me just because I said something? you should be thanking me. All I see you doing now is trying to out do whatever I say. Me and the original poster were having a nice conversation. Then you showed up. Not to help anyone but just to take a few stabs at me. I've got news for ya. I'm not going anywhere. I'm always going to try and help people.
-
if he is not using ipv6, simple disable is not a waste of time… It is what anyone should be doing, you don't run protocols on your network your not using - this is security 101!!
Windows in its infinite wisdom runs 3 different transition methods for getting to ipv6 over ipv4, teredo, isatap and 6to4.. If your not going to use ipv6 as of yet then disable them should be what your doing. Its a simple reg entry - sorry ms doesn't give you a gui. If you want can give you a fixit exe they provide to make the setting.
You can do it all from netsh if you want as well and disable the interfaces your not using like teredo. But the simple reg key is much quicker and easier.
Understanding what device is putting out the noise is not a waste of time - its understanding the devices on your network.. Suggesting someone just completely ignore it because its "noise" is just beyond stupid!!! Once they understand what is sending out the noise, if he can not turn off the noise at the source, then they can either block it at switch level for stuff like multicast, or can just not log it in the firewall if they don't want to see the noise.
But saying tracking down the noise producing device is a waste of time is just beyond nonsense!
-
Certainly do appreciate your time and help. I figured out what was flooding my logs with all that crap, Darkstats is the culprit, with no way to turn the logging off, so bye bye Darkstats.
Again, guys thank you….
-
_"Certainly do appreciate your time and help. I figured out what was flooding my logs with all that crap, Darkstats is the culprit, with no way to turn the logging off, so bye bye Darkstats.
Again, guys thank you…."_
You're welcome:)
I never would've thought about darkstat. I do love that package. But, like you, I also ended up disabling it unless I really needed to analyze traffic. Most of the time I would just use wireshark. Gotta love that program. Speaking of wireshark by the way. I did a little test at home because I was suspicious of my cable boxes being mic'd due to the way I was getting commercials. So I went around and got the boxes IP addresses. I then started monitoring traffic from a clean slate on wireshark and wouldn't you know it. As soon as I started speaking I saw traffic from the box that was in the same room. I guess they do it for advertising but I still don't like it. Glad we could help. Good day to you.
-
"Darkstats is the culprit"
Why would dartstats be sending out multicast traffic from an APIPA??
That makes no sense at all.. And your running the package on pfsense - or some other box.. Why would pfsense be seeing traffic to its lan1 and lan2 interface from darkstat package running on pfsense? Darkstat doesn't even monitor multicast –- why would it be sending it out?? Not sure what you think was sending it out, but I find it REALLY REALLY unlikely that darkstat was sending out traffic to 1900 from an APIPA when it sniffs traffic on your interfaces and reports on stats...
BTW the smite is because your post was pure nonsense!! Sorry it was - so smite.. And then you take credit for helping the guy, you told him tracking down or turning off the noise maker was just a waste of time.. Yeah bad post so smite..
The post is bad it gets 1 smite, not the person that hit me with like 30 in a less than 2 days.. Because he didn't like a comment..
-
I hit you with one after you got me. The 30 you are talking about is not from me.
Before you start talking about how I write nonsense. Realize that sometimes when we answer something it may not be exactly what the poster is talking about even though it may be the right answer according to you. I know. You think that makes no sense. In other words it may be better to brainstorm a little bit rather than worrying about a direct answer that is a hit or miss. It's hit or miss because we're not actually in the room with the people asking questions and not every scenario is the same. Sometimes people don't know exactly how to express the problem that they are having and sometimes you might get half the problem. It really doesn't do any good to start with your own question of "what did you do that for?" It sounds snotty and it contributes absolutely nothing to what they asked and most likely they will look elsewhere for help and I can't blame them. You must have 29 other people that smited you. You say it was two days? You can only do 1 per hour and I hate to break it to you but I have much better things to do than to worry about smiting someone over and over.
-
Yes dude it was like over 2 days.. There is 48 hours in the day.. So yes its possible.. Maybe it was 3 – either way you get the point..
Telling someone to not track down stuff because its noise, after they ask about that specific noise is the WRONG freaking answer... And going to call you on it every time...
-
Do whatever makes you feel better:)
-
Not sure, can't understand it either. I stopped the service and my logs are back to normal.
-
well running the service would normally put your interfaces in to promiscuous mode… This might pulling stuff into the firewall that it would normally not see since the traffic was not sent to it??
If I turn on log default I see that sort of traffic without darkstat even installed..
Its possible that package turns on default rule logging that maybe you had disable before?
So your saying that your not seeing any more blocks to 1900, be it ipv6 or ipv4 169.254 to your interfaces and you have the log default block rule enabled?
what I would suggest is track down the stuff that is in the log, and if you do not want to see it either stop it at the source, block it at switch level for multicast if you don't want that traffic in your network. Or just turn off default logging, or create specific rules in your interfaces to not log the specific traffic you don't want to see in your log to reduce your noise level.
As you can see that 169.254 is coming from my dvr from my previous post and the apipa address..
darkstat is not causing this traffic, but maybe it changed a setting in your system so your now seeing it?? I would not uninstall darkstat for that reason but adjust your settings so your logs log what you want, or better yet use these logs to clean up noise on your network you don't want. Like ipv6 or multicast traffic, no matter what IP its coming from... If you don't understand where its coming from - simple sniff would help you find the device.
-
Since disabling darkstat, my logs are back to normal, I am unsure what it could of turned on. Just happy my logs are not being flooded anymore…
-
I believe I had the same thing and fixed it by Setting IPv6 to none on Lan interface versus Tracking. If set ti tracking it would not only flood the logs but will start blocking over 1 hop IPv4 traffic from LAN. Meaning if you have wifi hot spot attached it will start blocking some of that traffic - throwing it to default IPv4 rule
