• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Large number of UDP packets on network

Gamingphreek

Gamingphreek

Lifer
Everyday I get about 15 E-Mails from my Firewall at work filled with logs. There are a lot of denied/dropped packets going LAN -> WAN.

I have Wireshark and nmap running and am still unable to figure out which process is generating the packets.

The basic structure is:
IP Source: Primary Domain Controller or Secondary Domain Controller
IP Destination: Gateway
Protocol: UDP
Source Port: 53
Destination Port: The first packet starts at some port number and subsequent packets increment along all valid ports.

A netstat -b -a -p UDP reveals a LOT of connections open on non-standard (ie: Port 40000) ports that are tied to [dns.exe]. I have no idea what the DNS process is trying to do or if it is related to this at all.

There are about 150 packets of this nature that slam into the firewall over the course of about 10 minutes. I'd like to find which service is causing it and stop it.

There is no chance of virus or malicious application attempting to call home whatsoever. I am not able to provide the packet capture from Wireshark.

Any suggestions would be great.

Thank You,
-Kevin
 
Your DCs run DNS for name resolution. They are trying to talk to the roots or any forwarders (don't use them!) you may have setup. It really all depends on how you setup DNS on the servers but it could very well be normal.
 
spidey07 said:
Your DCs run DNS for name resolution. They are trying to talk to the roots or any forwarders (don't use them!) you may have setup. It really all depends on how you setup DNS on the servers but it could very well be normal.
Click to expand...

So the packets are ACTUALLY destined for WAN side and not for my Gateway, right as they are looking for higher order (<-Bad name, but I can't remember the correct terminology) DNS servers right?

Why no root hints and/or forwarders?

-Kevin
 
I meant use only root hints and no forwarders. Let your name servers go to "the internet" roots instead of pointing it to a single server somebody outside your control operates (if they get poisoned, you will as well).

What is the DNS server address for the servers IP configuration? Is it the server itself, or is it configured to go to your gateway for name resolution? Microsoft AD relies HEAVILY on DNS and if it isn't all setup correctly you could see a lot of queries you don't expect to or the domain controllers going to the internet for microsoft AD related lookups.
 
Last edited:
You need to allow your Domain controllers to make those DNS requests. They are falling back to doing DNS requests via TCP which is slower, higher load and ignored on certain servers.
 
spidey07 said:
I meant use only root hints and no forwarders. Let your name servers go to "the internet" roots instead of pointing it to a single server somebody outside your control operates (if they get poisoned, you will as well).

What is the DNS server address for the servers IP configuration? Is it the server itself, or is it configured to go to your gateway for name resolution? Microsoft AD relies HEAVILY on DNS and if it isn't all setup correctly you could see a lot of queries you don't expect to or the domain controllers going to the internet for microsoft AD related lookups.
Click to expand...

Well with this particular network, we are using both forwarders and root hints because there is no risk of being poisoned. But for a public facing system, I can absolutely understand what you are saying.

So there are no entries in the event log for DNS, only a lot of firewall logs which are dropping the packets.

DNS appears to work for both WAN/LAN side communication; though, as imagoon said, it could be using TCP and the increased overhead it carries with it.

The AD servers are configured to go to itself and the secondary AD server for all DNS requests. The forwarders and root hints are, obviously, all WAN side. This is why I'm confused.

All of this traffic is smacking into my Gateway's Firewall, but I don't know why it is going to the gateway in the first place for name resolution. Should my Firewall ACL's be configured:

A.) Domain Controllers, DNS -> Gateway = Allow
or
B.) Domain Controllers, DNS -> WAN = Allow
or
C.) Domain Controllers, DNS -> * = Allow

The reverse (*,DNS -> Domain Controllers = Allow), but my current rules are set to option A.

Thanks,
-Kevin
 
Gamingphreek said:
Well with this particular network, we are using both forwarders and root hints because there is no risk of being poisoned. But for a public facing system, I can absolutely understand what you are saying.

So there are no entries in the event log for DNS, only a lot of firewall logs which are dropping the packets.

DNS appears to work for both WAN/LAN side communication; though, as imagoon said, it could be using TCP and the increased overhead it carries with it.

The AD servers are configured to go to itself and the secondary AD server for all DNS requests. The forwarders and root hints are, obviously, all WAN side. This is why I'm confused.

All of this traffic is smacking into my Gateway's Firewall, but I don't know why it is going to the gateway in the first place for name resolution. Should my Firewall ACL's be configured:

A.) Domain Controllers, DNS -> Gateway = Allow
or
B.) Domain Controllers, DNS -> WAN = Allow
or
C.) Domain Controllers, DNS -> * = Allow

The reverse (*,DNS -> Domain Controllers = Allow), but my current rules are set to option A.

Thanks,
-Kevin
Click to expand...

You should allow Domain controller -> 53 udp/tcp -> WAN: Allow. For extra 'security' you can then set (the rest of the network) 53 tcp:udp -> WAN: deny. Basically something like that forces DNS to be configured correctly because only the DCs (or any other DNS daemons) are the only ones able to get out. Any misconfigured device would simple stop getting DNS replies.
 
imagoon said:
You should allow Domain controller -> 53 udp/tcp -> WAN: Allow. For extra 'security' you can then set (the rest of the network) 53 tcp:udp -> WAN: deny. Basically something like that forces DNS to be configured correctly because only the DCs (or any other DNS daemons) are the only ones able to get out. Any misconfigured device would simple stop getting DNS replies.
Click to expand...

That makes perfect sense. I haven't seen any dropped packets from elsewhere, so hopefully that works seamlessly.

Any ideas as to why all the packets destination IP is my Gateway instead of a WAN side address? I'm not pointing anything towards the Gateway for DNS (In fact, I purposefully didn't configure any DNS servers on the Firewall since I don't use DHCP and nothing points at it) so I don't understand why the packets are addressed to it instead of the public IP of the forward DNS server.

-Kevin
 
Gamingphreek said:
That makes perfect sense. I haven't seen any dropped packets from elsewhere, so hopefully that works seamlessly.

Any ideas as to why all the packets destination IP is my Gateway instead of a WAN side address? I'm not pointing anything towards the Gateway for DNS (In fact, I purposefully didn't configure any DNS servers on the Firewall since I don't use DHCP and nothing points at it) so I don't understand why the packets are addressed to it instead of the public IP of the forward DNS server.

-Kevin
Click to expand...

If I am understanding correctly, you have UDP warning on lan -> firewall trust messages? If so that means somewhere for some reason something is configured to ask the gateway for dns (firewall:trust is typically the gateway, at least for the segment it is in.) Unless you are using something like OpenDNS's filtering, you really shouldn't have any forwarders (except for some very strict reasons such as resolving internal non-public domain names.)
 
imagoon said:
If I am understanding correctly, you have UDP warning on lan -> firewall trust messages? If so that means somewhere for some reason something is configured to ask the gateway for dns (firewall:trust is typically the gateway, at least for the segment it is in.) Unless you are using something like OpenDNS's filtering, you really shouldn't have any forwarders (except for some very strict reasons such as resolving internal non-public domain names.)
Click to expand...

First things first, I am using forwarders on my Domain Controllers. Just know that it is both necessary and secure.

I modified the Access Rules and nothing worked. BUT, since I don't use DHCP to push DNS to my clients, I figured I could take the two Domain Controllers off the of the Network Settings on the firewall. When I did this, all of the traffic stopped, but the Firewall is (obviously) unable to resolve names in Log Files and unable to resolve the Mail Server name to send reports to me.

I re-entered the Domain Controllers as the Primary and Secondary DNS servers on the Firewall again and then I even went so far as to do this:
Domain Controllers -> *,* = Allow

Unfortunately, it still reports that it is dropping UDP packets from the Domain Controllers to the Firewall/Gateway.

The Firewall is a SonicWall Pro 2040 (Perhaps it is a bug given that this is an older piece of [junk] equipment)?

-Kevin
 
Last edited:
Ok in that case... when a device setups up a connection, it will typically pick a high port number above 1024. So "DNS request" goes like this: Pick random high port say 2048. Open connection FW:2048 udp -> DC 53 udp. Reply: DC 53 UDP -> FW:2048 udp. I guess that what likely is happening is the firewall is dropping the response because of some rule for LAN<>Firewall.
 
imagoon said:
Ok in that case... when a device setups up a connection, it will typically pick a high port number above 1024. So "DNS request" goes like this: Pick random high port say 2048. Open connection FW:2048 udp -> DC 53 udp. Reply: DC 53 UDP -> FW:2048 udp. I guess that what likely is happening is the firewall is dropping the response because of some rule for LAN<>Firewall.
Click to expand...

Ok yea - you pick a high port because it is unlikely to already be bound to a particular service/process.

I honestly don't have any rule which is denying this though. It is just flat out dropping the response it looks like...

-Kevin
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top