Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Saturday, March 14, 2015 5:54 PM
Windows Server 2012 R2 with three network interfaces; two on public networks, and the third is a private non-routable 192.168.x.x network. Routing & Remote Access enabled so that machine is acting as a router, and NAT is enabled on the two public interfaces so that clients from the non-routable third network can access services on the public networks.
Windows Firewall is enabled, and the network profiles are logical: The two public network interface connections are running with the Public network profile, and the private network interface connection is assigned the Private network profile. It's a non-Domain-joined server, and all the Windows Firewall settings are default. (e.g. Drop inbound connections by default, etc.)
All of that is working great; private network clients can access standard services like HTTP from the public networks, but also successfully access non-standard services for which no Windows Firewall rule exists at all (e.g. third-party instant messaging servers, non-POP/IMAP mail systems, etc.).
Everything except FTP. To be clear, there is NO FTP SERVER on the Windows Server 2012 R2 machine. We're talking about FTP traffic being able to pass through RAS and NAT to the public networks, not "how do I access an FTP service running on the Windows Server machine."
If a client on the private network tries to initiate a port 21 connection to an FTP server out on the public networks, the TCP SYN never makes it any further than the private network interface of the Windows Server 2012 R2 machine. Meaning if I let Wireshark capture traffic across all three network interfaces, the TCP SYN for the remote port 21 is shown as arriving on the private network interface, but is never repeated/forwarded on one of the public interfaces (post-NAT). So we're not even talking anything complicated yet like SSL or trying to enter passive/active mode; we're not getting past the initial TCP SYN for port 21.
And I would say "well, I must need to NETSH ROUTING IP NAT ADD FTP or something like that, because the NAT doesn't seem to want to handle passing through FTP client traffic." (Which I've tried, and it does not make a difference.)
But all I actually have to do to make FTP clients work is turn off Windows Firewall for the private network interface. (i.e. Exclude the private network interface from the Private network profile in Windows Firewall.) Then the TCP SYN for port 21, and everything else the FTP client does will work, and passes through NAT just fine. Turn the Windows Firewall back on for the private network interface, and FTP is blocked for the private network clients again.
And I would say "well, I must need to add port 21 & port 20 rules to the Windows Firewall, because the Windows Firewall is blocking this communication." I can create an inbound port 21 & port 20 rule for the Private network profile in Windows Firewall just fine, allowing "inbound" traffic "to port 21" for all/any programs and all/any addresses.
But defining such a rule seems to have no effect on the FTP traffic trying to pass through this Windows Server router & NAT, meaning I still see the TCP SYN for port 21 still never makes it beyond arriving at the private network interface. Allowing "Edge Traversal" seems like a potentially relevant concept, but enabling that in the rule did not help either.
So what will allow FTP traffic from clients on the private network to route and pass out through NAT, without having to completely disable Windows Firewall on the private network interface? Presumably if I had an FTP service on the Windows Server itself, these firewall rules would make sense and would allow access to the Windows Server service. But what about Windows Firewall is blocking FTP traffic that would simply be routed, and isn't for a local port / program / address?
All replies (6)
Friday, March 27, 2015 11:39 AM âś…Answered | 2 votes
I had the same issue and found the solution here:
Execute the following command on the RRAS server:
netsh routing ip nat delete ftp
Best Regards.
Tuesday, March 17, 2015 4:00 AM
Hi Alan,
Maybe there is some other rule block the FTP traffic. Please follow the steps below to find which rule block the FTP:
- Enable the audit for WFP on RRAS server:
- auditpol /set /subcategory:"Filtering Platform Packet Drop" /success:enable /failure:enable
auditpol /set /subcategory:"Filtering Platform Connection" /success:enable /failure:enable - Reproduce the issue.
- Run command netsh wfp show state to get a .xml file.
- Check the event viewer of the RRAS server, we should find the audit log of the dropping packet. Please find the Filter Run-time ID of the filter.
- Then search the id in the .xml file to find which rule block the FTP traffic.
I tested it in my lab, it works properly. Here is the screenshot of my lab:
Best Regards.
Steven Lee Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Support, contact [email protected].
Wednesday, March 18, 2015 1:21 AM
Thank you, Steven.
I am sure it is a clue to something, but I am not sure what. I setup the auditing as described, cleared the security event log, ran a concurrent LAN trace, and reproduced the issue.
The LAN trace clearly shows an inbound packed from 192.168.3.25 (a host on the private network attempting to make an FTP connection) using ephemeral port 52975, trying to reach port 21 of an FTP server host IP address that is out on one of the public networks. The TCP SYN attempt is transmitted a total of three times before the attempt times out.
I export the entire previously-cleared Security log to .XML, and look for references to "Destination port: 21". There are none. I look for references to the public FTP server's IP address. There are none.
I look for references to port 52975, and I see the private network host (192.168.3.25) involved in blocked traffic in two directions:
Direction: Inbound
Source Address: 192.168.3.1
Source Port: 49168
Destination Address: 192.168.3.25
Destination Port: 52975
Protocol: 6
and:
Direction: Inbound
Source Address: 192.168.3.25
Source Port: 52975
Destination Address: 192.168.3.1
Destination Port: 49168
Protocol: 6
The number of these events (six total) seems to match the TCP SYN attempts. (Three total SYN attempts; two events for each attempt, one "inbound" from 192.168.3.25 and one "outbound" returning to 192.168.3.25, even though the events themselves all say "Direction: Inbound".)
192.168.3.1 is the Windows Server 2012 R2 machine's interface onto the private network. The fact that it's the 192.168.3.1 interface being cited as the source/destination address, and the fact there is this mysterious 49168 port being cited instead of the actual port 21 destination port, are making me think "NAT is enabled on the private interface"? i.e. Something turned the "destination public FTP host, port 21" that I can see in the LAN trace into "destination 192.168.3.1 port 49168" before the firewall saw it?
But "Routing and Remote Access" confirms the Private network interface (192.168.3.1) is "Private interface connected to private network", and does not have NAT enabled.
The Filter Runtime ID involved in the blocked events is 109239, which in the wfpstate.xml is "<name>Query User</name><description>Prompt the User for a decision corresponding this Inbound Traffic</description>".
Any idea what absence of seeing port 21 mentioned here in the filtering logs really means?
An example of two entire event log entries, and the entire matching wfpstate.xml entry, are here:
<Event xmlns='http://schemas.microsoft.com/win/2004/08/events/event'><System><Provider Name='Microsoft-Windows-Security-Auditing' Guid='{54849625-5478-4994-A5BA-3E3B0328C30D}'/><EventID>5157</EventID><Version>1</Version><Level>0</Level><Task>12810</Task><Opcode>0</Opcode><Keywords>0x8010000000000000</Keywords><TimeCreated SystemTime='2015-03-18T00:42:09.203329200Z'/><EventRecordID>18091</EventRecordID><Correlation/><Execution ProcessID='4' ThreadID='2820'/><Channel>Security</Channel><Computer>ALANADAMS-BUILD</Computer><Security/></System><EventData><Data Name='ProcessID'>3600</Data><Data Name='Application'>\device\harddiskvolume2\windows\system32\alg.exe</Data><Data Name='Direction'>%%14592</Data><Data Name='SourceAddress'>192.168.3.1</Data><Data Name='SourcePort'>49168</Data><Data Name='DestAddress'>192.168.3.25</Data><Data Name='DestPort'>52975</Data><Data Name='Protocol'>6</Data><Data Name='FilterRTID'>109239</Data><Data Name='LayerName'>%%14610</Data><Data Name='LayerRTID'>44</Data><Data Name='RemoteUserID'>S-1-0-0</Data><Data Name='RemoteMachineID'>S-1-0-0</Data></EventData><RenderingInfo Culture='en-US'><Message>The Windows Filtering Platform has blocked a connection.
Application Information:
Process ID: 3600
Application Name: \device\harddiskvolume2\windows\system32\alg.exe
Network Information:
Direction: Inbound
Source Address: 192.168.3.1
Source Port: 49168
Destination Address: 192.168.3.25
Destination Port: 52975
Protocol: 6
Filter Information:
Filter Run-Time ID: 109239
Layer Name: Receive/Accept
Layer Run-Time ID: 44</Message><Level>Information</Level><Task>Filtering Platform Connection</Task><Opcode>Info</Opcode><Channel>Security</Channel><Provider>Microsoft Windows security auditing.</Provider><Keywords><Keyword>Audit Failure</Keyword></Keywords></RenderingInfo></Event>
<Event xmlns='http://schemas.microsoft.com/win/2004/08/events/event'><System><Provider Name='Microsoft-Windows-Security-Auditing' Guid='{54849625-5478-4994-A5BA-3E3B0328C30D}'/><EventID>5152</EventID><Version>0</Version><Level>0</Level><Task>12809</Task><Opcode>0</Opcode><Keywords>0x8010000000000000</Keywords><TimeCreated SystemTime='2015-03-18T00:42:09.203329200Z'/><EventRecordID>18090</EventRecordID><Correlation/><Execution ProcessID='4' ThreadID='2820'/><Channel>Security</Channel><Computer>ALANADAMS-BUILD</Computer><Security/></System><EventData><Data Name='ProcessId'>3600</Data><Data Name='Application'>\device\harddiskvolume2\windows\system32\alg.exe</Data><Data Name='Direction'>%%14592</Data><Data Name='SourceAddress'>192.168.3.25</Data><Data Name='SourcePort'>52975</Data><Data Name='DestAddress'>192.168.3.1</Data><Data Name='DestPort'>49168</Data><Data Name='Protocol'>6</Data><Data Name='FilterRTID'>109239</Data><Data Name='LayerName'>%%14610</Data><Data Name='LayerRTID'>44</Data></EventData><RenderingInfo Culture='en-US'><Message>The Windows Filtering Platform has blocked a packet.
Application Information:
Process ID: 3600
Application Name: \device\harddiskvolume2\windows\system32\alg.exe
Network Information:
Direction: Inbound
Source Address: 192.168.3.25
Source Port: 52975
Destination Address: 192.168.3.1
Destination Port: 49168
Protocol: 6
Filter Information:
Filter Run-Time ID: 109239
Layer Name: Receive/Accept
Layer Run-Time ID: 44</Message><Level>Information</Level><Task>Filtering Platform Packet Drop</Task><Opcode>Info</Opcode><Channel>Security</Channel><Provider>Microsoft Windows security auditing.</Provider><Keywords><Keyword>Audit Failure</Keyword></Keywords></RenderingInfo></Event>
<item>
<filterKey>{e3da1bce-750b-428d-af89-9c4e9cc48005}</filterKey>
<displayData>
<name>Query User</name><description>Prompt the User for a decision corresponding this Inbound Traffic</description>
</displayData>
<flags/>
<providerKey>{decc16ca-3f33-4346-be1e-8fb4ae0f3d62}</providerKey>
<providerData>
<data>461d000000000000</data>
<asString>F.......</asString>
</providerData>
<layerKey>FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V4</layerKey>
<subLayerKey>{b3cdd441-af90-41ba-a745-7c6008ff2301}</subLayerKey>
<weight>
<type>FWP_UINT8</type>
<uint8>8</uint8>
</weight>
<filterCondition numItems="1">
<item>
<fieldKey>FWPM_CONDITION_ORIGINAL_PROFILE_ID</fieldKey>
<matchType>FWP_MATCH_EQUAL</matchType>
<conditionValue>
<type>FWP_UINT32</type>
<uint32>2</uint32>
</conditionValue>
</item>
</filterCondition>
<action>
<type>FWP_ACTION_BLOCK</type>
<filterType/>
</action>
<rawContext>0</rawContext>
<reserved/>
<filterId>109239</filterId>
<effectiveWeight>
<type>FWP_UINT64</type>
<uint64>9223372036854776256</uint64>
</effectiveWeight>
</item>
Wednesday, March 18, 2015 2:46 AM
Hi Alan,
Did you configure the proxy on the client? Proxy can change the port of the destination.
I can't explain why the result of the network capture and the WFP audit are different. Please check if the connection between 192.168.3.25:52975 and 192.168.3.1:49168 has been captured. Also, please check if the port 49168 is mapping to other remote host on the RRAS server.
Besides, have you configured the multiple gateway on the RRAS server? Multiple gateway may cause communication issues. Please try to remove the other gateway and try again.
Best Regards.
Steven Lee Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Support, contact [email protected].
Wednesday, March 18, 2015 3:42 AM
I am not configuring, nor intending to have to use, a proxy for the FTP client. Are you saying that I must, or inherently am, needing to use a proxy in order to pass through the Server 2012 R2's router and NAT?
By "multiple gateway" I presume you mean multiple default gateways. I did check that, and confirmed there is only a single default gateway specified among all of the interfaces, and it was set on only one interface, and was set the next hop router leading to my ISP on one of the public interfaces.
I'll check whether the LAN trace shows anything about the mysterious 192.168.3.1:49168 endpoint. I did have the LAN trace filtered for "anything to or from 192.168.3.25", so based on what WFP logged I should have seen it already, but I will double-check that and whether any mapping using port 49168 exists at the time of the event.
I have some critical FTP'ing going on at the moment, so I can't break things tonight by re-enabling the firewall on the private interface, but I'll get back to you once I've been able to test that.
Thanks again. -Alan
Wednesday, March 18, 2015 6:01 AM
Hi Alan,
>>Are you saying that I must, or inherently am, needing to use a proxy in order to pass through the Server 2012 R2's router and NAT?
No. As you have asked "i.e. Something turned the "destination public FTP host, port 21" that I can see in the LAN trace into "destination 192.168.3.1 port 49168" before the firewall saw it?", I just provide the possible cause of this behavior.
>>I have some critical FTP'ing going on at the moment, so I can't break things tonight by re-enabling the firewall on the private interface, but I'll get back to you once I've been able to test that.
OK. Wait for your update.
Best Regards.
Steven Lee Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Support, contact [email protected].