Windows 10 is not relaying remote TFTP server packets to the VM.

Question

Hello Everyone,

I have a Virtual Machine (an Ubuntu Server) that is running as a VM on VMware Workstation Pro 16 on my Windows 10 laptop. I am trying to use the VM's TFTP client to transfer a file from another computer connected to the same LAN as my laptop. My laptop would communicate with the remote TFTP server as expected, using its LAN side ip address (on behalf of my VM), but it does not relay the TFTP server packets back to the VM. I used Wireshark to capture the traffic on both the Wi-Fi NIC connected to the LAN and the virtual interface that connects my VM to the Internet and the LAN.

From the VM, I tried to get the file from the TFTP sever running on my laptop and it worked fine. The question now is: Why Windows 10 would not allow the VM (using TFTP client) to get the same file from the other computer?

I feel it is a security issue. How should I solve this problem?

Answer 1

Well the obvious suspect is the Windows firewall. Have you temporarily disabled that and tested? You can also configure it log dropped packets where you can then check the log.

My laptop would communicate with the remote TFTP server as expected, using its LAN side ip address (on behalf of my VM),

I assume that means that you are using the NAT option. Have you tried the bridged option?

Answer 2

@MotoX80 , thank you for your reply. The "bridged" option that you suggested works, but for some reason I do not want to change my VM interface card from NAT to bridged. I also enabled the logging of dropped packets as you suggested. When I opened the log file, I found that the first data packets from the TFTP server are actually being dropped by the Wi-Fi interface of my laptop. When I disabled the windows 10 firewall, everything worked fine.

BTW: from the laptop. even with the firewall active, I can use the Windows TFTP client to request the same file from the same TFTP server without any problem.

How come my laptop sends the client request to the TFTP server (after translating the source IP of the original TFTP packet to it's own IP address) and then drops off the reply packet from the server?

I also noticed that the TFTP server reply packets have a randomly selected UDP source port instead of UDP port 69. Could that be the problem?

Answer 3

I haven't used TFTP since the NT 3.51 days. I have no idea what it's doing.

Here's a post that describes how to identify the rule that blocks the traffic.

https://superuser.com/questions/1130078/how-to-tell-which-windows-firewall-rule-is-blocking-traffic

Answer 4

Hi,
I would suggest you contact Microsoft Customer Support and Services where more in-depth investigation can be done so that you would get a more satisfying explanation and solution to this issue. In addition, if the issue has been proved as system flaw, the consulting fee would be refund. You may find phone number for your region accordingly from the link below.
Global Customer Service phone numbers:
https://support.microsoft.com/en-us/help/13948/global-customer-service-phone-numbers

Thanks for your time.
Best regards,
Danny

-----------------------------

If the Answer is helpful, please click "Accept Answer" and upvote it.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 5

@TechNetMania I got curious about this and wrote a Powershell script to report on which rule blocked the traffic. On my Win10 laptop most of the packets are dropped by 2 hidden rules, "WSH Default Inbound Block" and "Port Scanning Prevention Filter".

I am still looking into this, but I thought that this script might help you.

# Name: BlockedTraffic.ps1  
# Version: 1.0  (10-May-2021)  
# Desc: Analyze audit events in the security event log and report on which   
#       firewall rule blocked the traffic.   
# Author: Dave (MotoX80)  
#  
# Enable auditing with these commands. (Or use gpedit.msc)  
#  
#   auditpol /set /subcategory:"Filtering Platform Packet Drop" /success:enable /failure:enable  
#   auditpol /set /subcategory:"Filtering Platform Connection" /success:enable /failure:enable  
#  
# To turn off auditing run:  
#  
#   auditpol /set /subcategory:"Filtering Platform Packet Drop" /success:disable /failure:disable  
#   auditpol /set /subcategory:"Filtering Platform Connection" /success:disable /failure:disable  
#  
# To look at the firewall log  
#  
#   Get-content c:\windows\System32\LogFiles\Firewall\pfirewall.log | Select-String '192.168.1.2'  
#  
cls  
"Gathering filter ID's."  
netsh.exe wfp show filters verbose=on file="$env:TEMP\filters.xml"  
[xml]$x = Get-Content  "$env:TEMP\filters.xml"  
$n = @{}  
"Processing XML."  
   $x.wfpdiag.filters.ChildNodes | foreach {  
        $n.add($_.filterid,$_.displayData.name)       # Rule name collection  
   }  
  
"Querying last 24 hours from Security event log."  
$fXML = '<QueryList>  
            <Query Id="0" Path="Security">  
            <Select Path="Security">*[System[(Level=4 or Level=0) and (EventID=5152 or EventID=5157) and TimeCreated[timediff(@SystemTime) &lt;= 86400000]]]</Select>  
            </Query>  
        </QueryList>'  
		  
$AllEvents = Get-WinEvent -FilterXml $fXML -ErrorAction SilentlyContinue  # append the events (if any)  
"Found {0} events." -f $AllEvents.count  
$blocked =@()  
foreach ($evt in $allevents) {  
    $rule = $n[$evt.properties[8].value.ToString()]      
    $blocked += [PSCustomObject]@{  
       TOD       = $evt.TimeCreated  
       Source    = $evt.properties[3].value  
       SrcPort   = $evt.properties[4].value  
       Dest      = $evt.properties[5].value  
       DestPort  = $evt.properties[6].value  
       FilterID  = $evt.properties[8].value          
       Rule      = $rule  
   }   
}  
  
$blocked  | format-table -AutoSize