Odd DNS Issue Causes SMB Transfer Slowness
-
There's not even an attempt to transfer a file there. Though I'd expect that if you captured from the LAN of the firewall, given that internal SMB traffic doesn't touch it. What were you doing when capturing that, and from where was the capture taken?
-
Capture on the machine your wanting to transfer from, ie the pc your using.. Be it your pulling a file down from a share or putting a file on a share. The PC your using will show us the transfer. As already stated multiple times if your moving a file to or from a machine on the same network segment pfsense doesn't even see or touch that traffic. So how would its dns settings slow anything down.
Also is hard to view details in that sort of info - upload the the actual capture. You can make it anon if you want with a tool such as https://www.tracewrangler.com/
But if your just doing a file copy via smb, etc. There really shouldn't be any data in there other than maybe the username and password you use to auth to the share - just create a test account before you do the sniff and use that, etc..
-
Cap Int: LAN
Proto: UDP
IP: storage server IP 1.30
Action: Open Network Share and File Transfer -
that is just broadcast traffic - again as stated pfsense is not going to see transfer between 2 boxes on the same network segment..
-
The only thing I can think of is we're really not talking about transfer rate but session start timeouts. Maybe OP's transferring a lot of little files and each transfer is dependent on DNS for something and has to timeout every time with one specific order of nameservers. Just guessing.
-
I don't even see any dns queries in there.. What I do see is prob plex which I believe uses that 32414 and 12 ports.. And some netbios stuff to ports 137 and 138 broadcast which pfsense is never going to answer anyway since it doesn't do any sort of wins support, etc. Even if that is what the traffic was - which I doubt since wins traffic is not broadcasted..
OP how are you access the shares via fqdn or IP? If your access shares like \1.2.3.4 then dns is never going to be invovled. If your doing \hostname or \hostname.something.tld then you could do a dns query for that, hostname is not good way to expect dns to respond anyway.
It can work with suffix search added by client, etc..
If you post a sniff of your file transfer working how you want (fast) and then when its slow we can take a look and help you figure out what the slow down is - but it sure is not going to have anything to do with pfsense.
-
Found out res was through the FW and not through the local DNS server.
-
No plex
-
It's on you to provide more info. I have no idea what that means.
-
No plex
I would beg to differ to be honest..
14:26:41.306997 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 49)
192.168.1.30.42027 > 192.168.1.255.32412: UDP, length 21
14:26:41.307097 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 49)
192.168.1.30.56755 > 192.168.1.255.32414: UDP, length 21Clearly 192.168.1.30 is broadcasting traffic on well known plex ports..
https://support.plex.tv/hc/en-us/articles/201543147-What-network-ports-do-I-need-to-allow-through-my-firewall-
The following ports are also used for different services:UDP: 1900 (for access to the Plex DLNA Server)
UDP: 5353 (for older Bonjour/Avahi network discovery)
UDP: 32410, 32412, 32413, 32414 (for current network discovery)
TCP: 32469 (for access to the Plex DLNA Server)While sure it could be something else - this is the only use of those ports that I am aware of.. Without seeing the actual sniff that can open in wireshark or something - that would be my guess to what the traffic is.
And again - this traffic has nothing to do with file transfers between 2 boxes on the 192.168.1.0/24 network - since pfsense would never even see that traffic. This is just typical broadcast noise..