Re: IIS5 Passive FTP Networking problem (long)
From: WinGuy (no_spam_at_nomail.bot)
Date: Tue, 14 Dec 2004 17:16:43 GMT
"Alun Jones [MSFT]" <email@example.com> wrote in message
> "WinGuy" <firstname.lastname@example.org> wrote in message
>> I don't know if it's true or not, but a tech at Linksys said that version
>> 3 firmware for the BEFSR41 router correctly translates the LAN address
>> into its own WAN address in the packet that IIS sends, and the ARP is
>> thus avoided. But version 2 firmware can not be upgraded to version 3, so
>> I can only use the very latest release of the version 2 firmware (which I
>> do) from Linksys and it obviously does not do the needed IP address
>> This means I have to do a "fix" by somehow configuring IIS FTP Service to
>> spoof the WAN address of its router in its response to a request to use
>> passive mode, or do away with the router entirely (and the hardware based
>> security benefits that it provides) and give IIS a real (instead of
>> spoofed) public WAN address.
> Or... take the old router you have now, and update it to technology from
> the last century.
> I've used a BEFSR41 myself for FTP server use, and for several years I've
> had the ability to run an FTP server behind it without changing the IP
> address that the FTP server gives out. The NAT changes the PASV response
> in every case.
My BEFSR41 v2, which Linksys says can not be upgraded to v3, does indeed
translate the address fields of a packet. But the IIS5 FTP response to a
request to use passive mode is not a packet address field being stipulated,
the address the client is to use is embedded withing the packet *data* field
of the response packet! IE6 (and WS-FTP, too, I discovered) uses THAT
address, rather than the one in the address field of that very same packet,
to send request packets to. Therein is the problem, as an Ethereal trace
will prove, because the problem is not caused by the router but instead is
caused by the response *data* that is sent from the FTP server to a client
request to enter passive mode. That version 3 or higher of the BEFSR41
Linksys router is smart and will examine that passive FTP *data* field of a
response packet from a server is cool, but not something one can count on
for other brands or older models of the same brand of router! Lots of people
would be using the dumber routers on their servers, and never have a clue as
to the real reason that passive FTP isn't working when the server is behind
a router. But I get your drift, and I figured that would be the answer, and
I think I'm going to have to toss the router. Well, I already have a
"IP-Filter" box built! <grin>
> It is the NAT's responsibility to make this change, and it would be a less
> secure alternative to make this change happen in the FTP server.
> Why? Because a NAT is really a NAPT - it translates network addresses
> _and_ ports.
But not necessarily (depending on the router and its firmware version) an
address that is embedded in the *data* portion of a FTP server response
packet and which the client recognizes and then issues an ARP for a LAN
address that can not be routed to!
> The FTP server could in theory be modified to issue a spoofed IP address
> (although that would then prevent testing the FTP server's PASV
> connections from inside the NAT), but it would have to assume that the
> ports on the outside were mapped one-to-one to the ports on the inside.
> This is not always the case. If the FTP server were to spoof the IP
> address without this knowledge of the port mappings, your transfers would
> go astray - either files would go to the wrong person, or they would not
> transfer at all.
I hadn't considered that. The ability to spoof like that would prohibit
clients on the server LAN from responding to a spoofed (but real) WAN
address? But I'm not so sure about that. I think it would route, out the LAN
router (instead of to the sever via direct LAN path) and to the internet and
back into the same LAN router and to the FTP server via port forwarding on
Anyway, I can't wait for a mod to IIS5, it will never occur! I have to do
something else if the needed spoof is not configurable right now. It was a
long shot, but I had hope that some undocument feature that could do what I
need already existed.
> Linksys' web site suggests that the firmware for both BEFSR41 Ver3 and the
> BEFSR41 are being actively maintained - the former had its last update on
> April 1, 2004, and the latter had its last update on August 3, 2004.
> Download the most recent firmware and install it, to see if this problem
> has been fixed. If it has not, ask when the firmware will be fixed. If
> it will not be fixed, you might consider returning the router and buying
> one that has the features you need.
Heh. My last call to them was answered, I think, in India.<grin> And that's
not a practical solution for me anyhow, since I need to act before such a
fix is made available for version 2 of the BEFSR41 router, if it were even
ever to occur. :(
> Software Design Engineer, Internet Information Server (FTP)
> This posting is provided "AS IS" with no warranties, and confers no
Thanks for the comments, Alun, even though they tend to verify my nightmare
fears. Looks like I have to start thinking unix-like (ooh, I hate that!) and
toss the router and replace it with a transparent firewall box "IP-Filter"
on a FreeBSD platform. <sigh> At least I already have it built and fully
operational, I just have to finish configuring its firewall. I hate CIDR
notation, which it uses, since it's very hard to specify weird address
ranges without affecting ones outside the range (but someone did publicly
write a utility, that I quickly obtained, which very accurately does exactly
that kind drudgery work!)