pfSense using unreasonable amount of bandwidth while idle
-
@CyberMinion said in pfSense using unreasonable amount of bandwidth while idle:
I see several pages of this for each second that passes.
Hello!
Are you running any python modules in unbound?
John
-
Be it that is causing that much bandwidth or not.. You got something doing A queries for what is suppose to be an IP it looks like..
Figure out what is doing asking for that.. Pfsense out of the box is not going to query for that..
And doing a suffix search, which is just local? If so why are you hiding it?
-
Are you running any python modules in unbound?
None that I am aware of...unless maybe SNORT is running unbound. I can't find any mention of that in the config, but I think it might use Python. EDIT: Oh duh, pfBlocker uses Unbound.
All I know is that it is originating from the pfSense. Here are the packages I have installed. There's always the possibility of a misconfiguration on one or more of them.
And doing a suffix search, which is just local? If so why are you hiding it?
I'm not sure what kind of a lookup it is doing, but I'm hiding that part of it just because it is the internal hostname. Names are hidden to protect the guilty.
Just suppose what I covered is "MyLAN" or "MyNetworkName"I don't need SNORT, so maybe I will try shutting that off for a bit. It shouldn't be doing any lookups of its own, but it's worth a try. If that doesn't work, maybe I'll try shutting down pfBlocker. I don't want to do that, but I can if needed. These are the two main packages I have running here.
Is there a way to get details on resource utilization of each process? That way, I might be able to correlate the network traffic with a specific pid.
-
@CyberMinion said in pfSense using unreasonable amount of bandwidth while idle:
I'm not sure what kind of a lookup it is doing,
Says right there what its doing, its doing a A query.. but 066.159.140.072 is very ODD A query and yeah it would return a NX since there is no .072 TLD, and same for any local domain, public dns not going to know anything about those..
Are you doing any direction of dns to loopback, ie trying to redirect things from using external dns?
For example.. here is pfsense trying to check for updates
Aug 12 13:04:47 unbound 52178:3 info: 127.0.0.1 files01.netgate.com. A IN NOERROR 0.000000 1 53 Aug 12 13:04:47 unbound 52178:3 info: 127.0.0.1 files01.netgate.com. A IN Aug 12 13:04:47 unbound 52178:0 info: 127.0.0.1 files01.netgate.com. AAAA IN NOERROR 0.040565 0 65 Aug 12 13:04:47 unbound 52178:0 info: 127.0.0.1 files01.netgate.com. AAAA IN Aug 12 13:04:47 unbound 52178:3 info: 127.0.0.1 files01.netgate.com. A IN NOERROR 0.036122 0 53 Aug 12 13:04:47 unbound 52178:3 info: 127.0.0.1 files01.netgate.com. A IN Aug 12 13:04:47 unbound 52178:0 info: 127.0.0.1 _https._tcp.firmware.netgate.com. SRV IN NOERROR 0.195872 0 128 Aug 12 13:04:47 unbound 52178:0 info: 127.0.0.1 _https._tcp.firmware.netgate.com. SRV INOff the top of my head, I am not sure how you would find out what process is asking loopback for query?
-
@johnpoz Nothing should be mapped to the loopback address. I have given two internal IPs local domain names in my resolver, and pfBlocker returns a dummy internal IP for "blocked" DNS requests (192.168.5.1). Other than that, it should be operating normally.
-
Where does pfsense point to? It points to loopback (127.0.0.1) out of the box, any process running on pfsense would be using that for dns queries.
-
@johnpoz Ah, I see.
-
To be honest if what you want to make sure pfsense queries are using tls to talk to 1.1.1.1 or quad 9.. You have to do the forwards in the unbound resolver options box.. Because when setup this way if for some reason pfsense own dns client goes to ask 1.1.1.1 or quad9 it will just do a normal dns query and will not use tls.
So from your log you show that loopback is asking for that weird A query.. Out of the box pfsense would not ask for that.. It only checks to see if there is any updates. From like what I showed you, or if it trying to resolve something via some other process running on it, like a package.. Filterdns would ask for stuff if you setup any aliases, etc.
It would look to download bogon, etc..
The trick is trying to figure out where that query is coming from.. Off the top I do no know a way to monitor all internal processes for what they query for..
That sort of tracking has always been tricky no matter the os, be it windows, linux or a bsd..
-
You have to do the forwards in the unbound resolver options box..
I am, but before I enabled DoH, I added these DNS providers to the standard resolver, to use them in the clear (both are much faster than my ISP's DNS). Since then, I've run tests and do see DoH traffic, not regular UDP, so I assume those are no being used. Here is what I have in my custom box right now:
forward-zone: name: "." forward-ssl-upstream: yes forward-addr: 1.1.1.1@853 forward-addr: 9.9.9.9@853 server:include: /var/unbound/pfb_dnsbl.*conf server: log-queries: yes log-replies: yesThe trick is trying to figure out where that query is coming from
Agreed. Other than the OS itself doing the basic stuff, the only other lookups I would expect to see from this box are from pfBlocker, which uses numerous block lists which it updates periodically. This process certainly shouldn't be doing what we are seeing happen, but it is the only other main source of queries I can think of. It is also doing Geo blocking (yes, I know...it probably isn't really that helpful in most circumstances) so it needs to update those IP lists periodically.
-
Yeah something is not right because that is not really a valid query.. A query for an IP should be a PTR query.. And a A record like that would really never resolve because that last part would be considered the tld.. and .072 sure isn't a valid tld..
Now your 066.140.x.x.localdomain could resolve.. if the local NS you were asking had a record like that in it.. but public would never resolve that sort of query.
Maybe look through your xml, you can download a full backup and search for anything that could be put in somewhere that matches that odd query.
edit: BTW your not seeing any other odd queries like that? Just that 1 weird one that repeats over and over?
Are you seeing any firewall logs with that IP in it? Or that IP reversed, where maybe the PTR got messed up? so like 72.140.159.66 or 66.159.140.72 ?
-
My apologies for taking so long to respond. Some other things we demanding my time.
@johnpoz said in pfSense using unreasonable amount of bandwidth while idle:
Now your 066.140.x.x.localdomain could resolve.. if the local NS you were asking had a record like that in it.. but public would never resolve that sort of query.
My local resolver does not have any entries like that.
Maybe look through your xml, you can download a full backup and search for anything that could be put in somewhere that matches that odd query.
I'm not exactly sure what to look for, but I found no references to that address in the XML
edit: BTW your not seeing any other odd queries like that? Just that 1 weird one that repeats over and over?
Pretty much, although I think I have seen one or two other addresses on rare occasions. I ran another pcap, but forgot I had DoH on, so it doesn't offer many insights...just that it was communicating a great deal with both DNS providers. (I can hear your "I told you so"'s already...)
I forgot to grab the DNS log at the time.Are you seeing any firewall logs with that IP in it? Or that IP reversed, where maybe the PTR got messed up? so like 72.140.159.66 or 66.159.140.72 ?
Well, I haven't checked recently. I will do that next time. My log is currently swamped with some IPv6 address pounding away on it with UDP. (odd, since this is behind another firewall...)
By the way, I tried disabling pfblocker while this noise was going on, and it didn't resolve the problem. I didn't restart the device though, since that would temporarily "solve" the issue anyway. When I turned off pfblocker, here is what happened for network activity.
Then it resumed the background noise again. I did think it was a little interesting that the download speed actually dipped as the upload spiked. Maybe that's just due to a network bottleneck though. Also, why so much upload for this?Upon re-enabling pfblocker, the same basic thing happened.
I doubt that is significant, but I figured I'd share it anyway.
Also, FYI here is a "baseline" of sorts, from later in the day while it has 4 computers semi-active on it.
Note that it has quieted down. -
So link local looking for something via LLMR (5355)..
Dude sorry but the couple of packets you list in you sniff does not account for 200K of traffic..
You got something going on that your not catching in the sniff or you not showing ups the details of capture.. Are you seeing 1000's of queries and your just showing us the 1?
How about you turn off that doh shit and see if your issue goes away? But for doh to generate that amount of traffic there would have to be way more queries than your showing.
-
@johnpoz said in pfSense using unreasonable amount of bandwidth while idle:
So link local looking for something via LLMR (5355)..
I found nothing in that regard
Dude sorry but the couple of packets you list in you sniff does not account for 200K of traffic..
Agreed, I don't seem to be seeing enough packets to explain the bandwidth consumption.
You got something going on that your not catching in the sniff or you not showing ups the details of capture.. Are you seeing 1000's of queries and your just showing us the 1?
No, I just don't seem to be seeing very many packets in my pcaps. The DNS resolver was generating 1000 log entries about every 6 seconds though.
How about you turn off that doh shit and see if your issue goes away? But for doh to generate that amount of traffic there would have to be way more queries than your showing.
I did that a month or so ago, and the problem was still occurring. I turned it off again though, for argument's sake. Someone upstream of me will be very happy...
By the way, last night it was looping a request over and over again for 185.190.088.000.MyNetworkName It was mostly requesting the AAAA record, which is slightly interesting since IPv6 traffic is blocked on the pfSense.
-
@CyberMinion said in pfSense using unreasonable amount of bandwidth while idle:
It was mostly requesting the AAAA record
That has nothing to do with if IPv6 is enabled or not..
What was asking for that 185.190.088.000.MyNetworkName - your saying pfsense was asking itself for that.. or some client on your network was asking for it?
Do you have any sort of haproxy setup with a backend check. Or the old loadbalancer setup?
-
Hi @CyberMinion - Does using Diagnostics -> pfTop reveal anything interesting? For instance, try using View = "speed" and Sort By = "Bytes"
Hope this helps.
-
@johnpoz said in pfSense using unreasonable amount of bandwidth while idle:
What was asking for that 185.190.088.000.MyNetworkName - your saying pfsense was asking itself for that.. or some client on your network was asking for it?
It was being requested by the loopback address on the pfsense - 127.0.0.1
Do you have any sort of haproxy setup with a backend check. Or the old loadbalancer setup?
No, nothing so fancy.
@tman222
Good idea, but I'm not seeing anything which particularly stands out to me. I see a bunch of idle connections to by backup DNS provider, and while I don't see any connections to my primary DNS IP (1.1.1.1)listed, I am seeing connections to two other CloudFlare IPs, so maybe the requests got load balanced off to other IPs.
By the way, is it normal to have over 130 processes running on this this FreeDSD/pfSense build? I honestly don't know, but it seems a little high to me.
When I run ps I only see this:
PID TT STAT TIME COMMAND 5340 u0 I+ 0:00.02 /bin/sh /etc/rc.initial 56616 u0- IN 0:35.73 /bin/sh /var/db/rrd/updaterrd.sh 87977 u0 Is 0:00.04 login [pam] (login) 95417 u0 I 0:00.02 -sh (sh)but in monitoring, I see this:
Note also that there was a PC actively doing stuff behind this firewall until a little after 3am. It automatically powered down, leaving just two idle service computers running. Almost immediately, the "user utilization" increased markedly.
-
That IP isn't even valid - its a bogon
185.190.88.0/22
-
@johnpoz said in pfSense using unreasonable amount of bandwidth while idle:
That IP isn't even valid - its a bogon
185.190.88.0/22
Good point. Bogons are set to be blocked by both the pfSense native rules, and pfBlocker. Interesting.
-
A few dns queries even using tls is not going to generate that sort of traffic..
Do a sniff on wan in promiscuous mode capturing all the traffic, not just 100 packets..
What is in front of pfsense? This 192.168.1.232 is not an IP your ISP would give you..
Also on you traffic graph, set the filter to all - so we can see where the traffic is coming from.. No just your IP. Or use the iftop package.. Where is this that amount of traffic coming from or going to - makes no sense that a few queries over tls could generate anywhere near that amount of constant traffic.
-
@johnpoz said in pfSense using unreasonable amount of bandwidth while idle:
A few dns queries even using tls is not going to generate that sort of traffic..
Do a sniff on wan in promiscuous mode capturing all the traffic, not just 100 packets..
Done. After filtering out the significant amount of DNS noise, I do still have a lot left over. For example, the upsteam NAT router is apparently pinging me a fair amount. I confirmed that wasn't anything being done manually by anyone on my end, although I can't imagine ICMP pongs justifying this load.
I'm not sure what I should be looking for here, though. Nothing else jumps out at me--any particular suggestions?
What is in front of pfsense? This 192.168.1.232 is not an IP your ISP would give you..
Correct, I thought I'd explained this, but in skimming back, I don't see it. The pfSense is behind a NAT router (192.169.1.1), which is mostly outside my control. It has some devices on it I don't control, so I wanted a barrier between me and them. The pfSesne firewall is on DHCP from that, currently with 192.168.1.232.
Also on you traffic graph, set the filter to all - so we can see where the traffic is coming from.. No just your IP.
Oh, right. the network is in use some now, so it's harder to get a clean graph...pardon the brief spikes. The "background noise" is still there though, clearly, which is somewhat unusual. Typically once the network starts getting more use, this noise goes away.
Or use the iftop package.. Where is this that amount of traffic coming from or going to - makes no sense that a few queries over tls could generate anywhere near that amount of constant traffic.
The only devices on this list which remain online through the night (when this noise typically starts) are 192.168.4.70 and 192.168.3.2 (SOHO NAT router). I masked one IP, since it is somewhat identifying. It is a trusted remote server.Any thoughts on the processes/hardware utilization I mentioned earlier? Or is that a dead-end?
