At the end of this message is an abreviated Ethereal capture that shows the
passive FTP problem that I have. Networking isn't really the issue but it is
a victim if I can not configure IIS5 FTP Service to identify (spoof) itself
during a passive FTP connection setup the way that I need for it to do.
Maybe someone can help after reading all this, lengthy as it surely is!



I've an interesting networking problem in trying to get IIS5 on W2K, which
is behind a Linksys router, working with passive FTP initiated by a client
that is behind a Microsoft Base Station router (or any client on the
internet, actually). The IIS5 server box is the only computer connected to
the Linksys. Several computers are connected to the MBS router. Both routers
connect to a DSL modem via a hub. Each router has a dedicated public IP
address. So there are 2 LANs. The Linksys uses only static LAN addresses,
the MSB uses dynamic.



The intent was if one LAN got infected then it could not easily infect the
other, as only the clients on the MSB side can initiate a connection to the
server, and then only via internet, and the server can not initiate a
connection to any client on the MSB side. The other advantage was to
decrease load on the software based firewalls that every computer uses, as a
router isn't a very good firewall compared to BlackIce, ZoneAlarm Pro, and
so on - and so a DoS would be mitigated to some degree by the routers,
decreasing CPU load on the boxes. BlackIce is pretty good in tangent with
URLScan for webserver security and with recognizing FTP or SMTP attacks, and
ZoneAlarm is great for controlling ports and keeping a rogue infection from
being able to use the internet to spread havoc. And the software firewalls
allow denying internet connections from IP addresses or specified domains,
which the routers can not do. It's a very secure setup, actually, and it has
withstood all attacks for over 2 years now.



Active FTP works fine, but there's a problem implementing passive FTP. The
registry entry was performed for IIS so that passive FTP would use ports
5555-5700, per Microsoft  KB555022. The IIS Linksys router was configured to
forward the port range of 5555-5700 to the static 192.168.1.252 IP address
that the server uses. So they are not blocked by the Linksys router. With
passive FTP the clients initiate all connections, so the MBS router also
does not block that range.



The first problem is that I can not tell by the below listing if that
5555-5700 port range is being respected when the server responds with
"Entering Passive Mode (192,168,1,100,21,188)". I see that the IIS IP
address of 192.168.1.100 is represented there, and that the command port is
21, but I don't see how "188" is supposed to represent a data port within
the range of 5555-5700.



The 2nd problem is that I can't seem to tell IIS5 FTP Service to say
"67,115,67,162" instead of "192,168,1,100". If I set it to 67.115.67.162
using the IIS Manager then FTP doesn't work in active mode anymore, and
still doesn't work in passive mode either. The router has that public WAN
address, is why.



Because I can't tell (or don't know how to tell) the FTP Service to say
"67,115,67,162", the client gets confused as the below listing shows and
issues an ARP broadcast looking for the machine "192,168,1,100". Of course,
since it's on a different LAN, there is never any response and the passive
data transfer errors on timeout. Same thing happens for any internet based
client. If the IIS FTP Service could be configured to say "67,115,67,162"
even though it really is "192,168,1,100" then the Linksys router would
forward the packets just fine and everything would work. My Linksys BEFSR41
is a version 2 and so it can not be upgraded to version 3, but it is at the
highest firmware level available from Linksys for version 2. So, no joy
there.



I was thinking to split the 192.168.x.x range into 2 equal parts, one part
used by each router, and to hub the LAN sides of each router together so
they can both respond to an ARP broadcast on the resultant "super LAN"
configuration. I think that would solve the passive FTP problem from the
perspective of both LANs, but that still would not make passive FTP work for
the general internet (who would be still be wanting to do ARP broadcasts
looking for 192.168.1.100).



So, I'm stuck and I don't seem to be able to offer passive FTP over internet
if I wish to maintain the security that the current arrangement of routers
provides. Unless there's some way to make the IIS5 FTP Service spoof
"67.115.67.162" (the Linksys static public IP address) instead of it saying
"192.168.1.100" (the actual static LAN IP address of IIS). Can this be done?



If not, then I guess the only practical solution remaining is to use yet
another box to run a "transparent IP-less" firewall called "IP Filter"
(which comes with FreeBSD) so that IIS can have a public WAN rather than a
private LAN address, and toss the Linksys router. How ironic. I'd really
rather not have to do that! But I have to keep the firewall load off of the
IIS box, so I'll do it if I have to. Do I really have to do that?



Winguy



====================== LISTING FOLLOWS

Source        Destination  Proto Info

192.168.1.252 67.115.67.162 TCP 2540 > ftp [SYN] Seq=0 Ack=0 Win=65535 L
en=0
MSS=1460

67.115.67.162 192.168.1.252 TCP ftp > 2540 [SYN, ACK] Seq=0 Ack=1 Win=17
520
Len=0 MSS=1460

192.168.1.252 67.115.67.162 TCP 2540 > ftp [ACK] Seq=1 Ack=1 Win=65535 L
en=0

67.115.67.162 192.168.1.252 FTP Response: 220 svr1 Microsoft FTP Service
(Version 5.0)

192.168.1.252 67.115.67.162 FTP Request: USER anonymous

67.115.67.162 192.168.1.252 FTP Response: 331 Anonymous access allowed, send
identity (e-mail name) as password

192.168.1.252 67.115.67.162 FTP Request: PASS IEUser@

67.115.67.162 192.168.1.252 FTP Response: 230-Private Site. Unauthorized
access prohibited.

192.168.1.252 67.115.67.162 TCP 2540 > ftp [ACK] Seq=31 Ack=172 Win=6536
4
Len=0

67.115.67.162 192.168.1.252 FTP Response: 230-

192.168.1.252 67.115.67.162 FTP Request: opts utf8 on

67.115.67.162 192.168.1.252 FTP Response: 500 'OPTS utf8 on': command not
understood

192.168.1.252 67.115.67.162 FTP Request: syst

67.115.67.162 192.168.1.252 FTP Response: 215 Windows_NT version 5.0

192.168.1.252 67.115.67.162 FTP Request: site help

67.115.67.162 192.168.1.252 FTP Response: 214-The following SITE  commands
are recognized(* ==>'s unimplemented)

192.168.1.252 67.115.67.162 FTP Request: PWD

67.115.67.162 192.168.1.252 FTP Response: 257 "/Anonymous" is current
directory

192.168.1.252 67.115.67.162 FTP Request: noop

67.115.67.162 192.168.1.252 FTP Response: 200 NOOP command successful

192.168.1.252 67.115.67.162 FTP Request: CWD /Anonymous/

67.115.67.162 192.168.1.252 FTP Response: 250 CWD command successful

192.168.1.252 67.115.67.162 FTP Request: TYPE A

67.115.67.162 192.168.1.252 FTP Response: 200 Type set to A.

192.168.1.252 67.115.67.162 FTP Request: PASV

67.115.67.162 192.168.1.252 FTP Response: 227 Entering Passive Mode
(192,168,1,100,21,188)

192.168.1.252 Broadcast     ARP Who has 192.168.1.100?  Tell 192.168.1.252
<=== PROBLEM !!!

[ Post a follow-up to this message ]

Great stuff ! The problem is with the NAT. while I can't give you a good
explanation compare to the MS 'F' guy that care of IIS FTP, here's what I
can tell you.

> The first problem is that I can not tell by the below listing if that
> 5555-5700 port range is being respected when the server responds with
> "Entering Passive Mode (192,168,1,100,21,188)". I see that the IIS IP
> address of 192.168.1.100 is represented there, and that the command port
> is 21, but I don't see how "188" is supposed to represent a data port
> within the range of 5555-5700.

Yes, it is within the port range, to calculate it. you take the last two
'numbers'
21 * 256 + 188 = 5564
detail -
Information About the IIS File Transmission Protocol (FTP) Service
http://support.microsoft.com/?id=283679

> The 2nd problem is that I can't seem to tell IIS5 FTP Service to say
> "67,115,67,162" instead of "192,168,1,100". If I set it to 67.115.67.162
> using the IIS Manager then FTP doesn't work in active mode anymore, and
> still doesn't work in passive mode either. The router has that public WAN
> address, is why.

This is related to the design of NAT and it is correct when you see Internal
IP address while NAT is doing the port translation.


Your setup is kinda complicated  I mean in terms of of NAT. and I'm not
sure if I get you correctly, but I have seen the same model of routers that
able to support ftp passive mode without any problem.
so you have:

Net | MBS + LAN | Linksys and IIS FTP

am I correct ?
my question now can LAN users connect ftp succesfully in passive mode ?

let's wait for Alun to comment further.

--
Regards,
Bernard Cheah
http://www.tryiis.com/
http://support.microsoft.com/
http://www.msmvps.com/bernard/



"WinGuy" <no_spam@nomail.bot> wrote in message
news:sauvd.59435$QJ3.41357@newssvr21.news.prodigy.com...
> At the end of this message is an abreviated Ethereal capture that shows
> the passive FTP problem that I have. Networking isn't really the issue but
> it is a victim if I can not configure IIS5 FTP Service to identify (spoof)
> itself during a passive FTP connection setup the way that I need for it to
> do. Maybe someone can help after reading all this, lengthy as it surely
> is!
>
>
>
> I've an interesting networking problem in trying to get IIS5 on W2K, which
> is behind a Linksys router, working with passive FTP initiated by a client
> that is behind a Microsoft Base Station router (or any client on the
> internet, actually). The IIS5 server box is the only computer connected to
> the Linksys. Several computers are connected to the MBS router. Both
> routers connect to a DSL modem via a hub. Each router has a dedicated
> public IP address. So there are 2 LANs. The Linksys uses only static LAN
> addresses, the MSB uses dynamic.
>
>
>
> The intent was if one LAN got infected then it could not easily infect the
> other, as only the clients on the MSB side can initiate a connection to
> the server, and then only via internet, and the server can not initiate a
> connection to any client on the MSB side. The other advantage was to
> decrease load on the software based firewalls that every computer uses, as
> a router isn't a very good firewall compared to BlackIce, ZoneAlarm Pro,
> and so on - and so a DoS would be mitigated to some degree by the routers,
> decreasing CPU load on the boxes. BlackIce is pretty good in tangent with
> URLScan for webserver security and with recognizing FTP or SMTP attacks,
> and ZoneAlarm is great for controlling ports and keeping a rogue infection
> from being able to use the internet to spread havoc. And the software
> firewalls allow denying internet connections from IP addresses or
> specified domains, which the routers can not do. It's a very secure setup,
> actually, and it has withstood all attacks for over 2 years now.
>
>
>
> Active FTP works fine, but there's a problem implementing passive FTP. The
> registry entry was performed for IIS so that passive FTP would use ports
> 5555-5700, per Microsoft  KB555022. The IIS Linksys router was configured
> to forward the port range of 5555-5700 to the static 192.168.1.252 IP
> address that the server uses. So they are not blocked by the Linksys
> router. With passive FTP the clients initiate all connections, so the MBS
> router also does not block that range.
>
>
>
> The first problem is that I can not tell by the below listing if that
> 5555-5700 port range is being respected when the server responds with
> "Entering Passive Mode (192,168,1,100,21,188)". I see that the IIS IP
> address of 192.168.1.100 is represented there, and that the command port
> is 21, but I don't see how "188" is supposed to represent a data port
> within the range of 5555-5700.
>
>
>
> The 2nd problem is that I can't seem to tell IIS5 FTP Service to say
> "67,115,67,162" instead of "192,168,1,100". If I set it to 67.115.67.162
> using the IIS Manager then FTP doesn't work in active mode anymore, and
> still doesn't work in passive mode either. The router has that public WAN
> address, is why.
>
>
>
> Because I can't tell (or don't know how to tell) the FTP Service to say
> "67,115,67,162", the client gets confused as the below listing shows and
> issues an ARP broadcast looking for the machine "192,168,1,100". Of
> course, since it's on a different LAN, there is never any response and the
> passive data transfer errors on timeout. Same thing happens for any
> internet based client. If the IIS FTP Service could be configured to say
> "67,115,67,162" even though it really is "192,168,1,100" then the Linksys
> router would forward the packets just fine and everything would work. My
> Linksys BEFSR41 is a version 2 and so it can not be upgraded to version 3,
> but it is at the highest firmware level available from Linksys for version
> 2. So, no joy there.
>
>
>
> I was thinking to split the 192.168.x.x range into 2 equal parts, one part
> used by each router, and to hub the LAN sides of each router together so
> they can both respond to an ARP broadcast on the resultant "super LAN"
> configuration. I think that would solve the passive FTP problem from the
> perspective of both LANs, but that still would not make passive FTP work
> for the general internet (who would be still be wanting to do ARP
> broadcasts looking for 192.168.1.100).
>
>
>
> So, I'm stuck and I don't seem to be able to offer passive FTP over
> internet if I wish to maintain the security that the current arrangement
> of routers provides. Unless there's some way to make the IIS5 FTP Service
> spoof "67.115.67.162" (the Linksys static public IP address) instead of it
> saying "192.168.1.100" (the actual static LAN IP address of IIS). Can this
> be done?
>
>
>
> If not, then I guess the only practical solution remaining is to use yet
> another box to run a "transparent IP-less" firewall called "IP Filter"
> (which comes with FreeBSD) so that IIS can have a public WAN rather than a
> private LAN address, and toss the Linksys router. How ironic. I'd really
> rather not have to do that! But I have to keep the firewall load off of
> the IIS box, so I'll do it if I have to. Do I really have to do that?
>
>
>
> Winguy
>
>
>
> ====================== LISTING FOLLOWS
>
> Source        Destination  Proto Info
>
> 192.168.1.252 67.115.67.162 TCP 2540 > ftp [SYN] Seq=0 Ack=0 Win=65535
> Len=0 MSS=1460
>
> 67.115.67.162 192.168.1.252 TCP ftp > 2540 [SYN, ACK] Seq=0 Ack=1
> Win=17520 Len=0 MSS=1460
>
> 192.168.1.252 67.115.67.162 TCP 2540 > ftp [ACK] Seq=1 Ack=1 Win=65535
> Len=0
>
> 67.115.67.162 192.168.1.252 FTP Response: 220 svr1 Microsoft FTP Service
> (Version 5.0)
>
> 192.168.1.252 67.115.67.162 FTP Request: USER anonymous
>
> 67.115.67.162 192.168.1.252 FTP Response: 331 Anonymous access allowed,
> send identity (e-mail name) as password
>
> 192.168.1.252 67.115.67.162 FTP Request: PASS IEUser@
>
> 67.115.67.162 192.168.1.252 FTP Response: 230-Private Site. Unauthorized
> access prohibited.
>
> 192.168.1.252 67.115.67.162 TCP 2540 > ftp [ACK] Seq=31 Ack=172 Win=65
364
> Len=0
>
> 67.115.67.162 192.168.1.252 FTP Response: 230-
>
> 192.168.1.252 67.115.67.162 FTP Request: opts utf8 on
>
> 67.115.67.162 192.168.1.252 FTP Response: 500 'OPTS utf8 on': command not
> understood
>
> 192.168.1.252 67.115.67.162 FTP Request: syst
>
> 67.115.67.162 192.168.1.252 FTP Response: 215 Windows_NT version 5.0
>
> 192.168.1.252 67.115.67.162 FTP Request: site help
>
> 67.115.67.162 192.168.1.252 FTP Response: 214-The following SITE  commands
> are recognized(* ==>'s unimplemented)
>
> 192.168.1.252 67.115.67.162 FTP Request: PWD
>
> 67.115.67.162 192.168.1.252 FTP Response: 257 "/Anonymous" is current
> directory
>
> 192.168.1.252 67.115.67.162 FTP Request: noop
>
> 67.115.67.162 192.168.1.252 FTP Response: 200 NOOP command successful
>
> 192.168.1.252 67.115.67.162 FTP Request: CWD /Anonymous/
>
> 67.115.67.162 192.168.1.252 FTP Response: 250 CWD command successful
>
> 192.168.1.252 67.115.67.162 FTP Request: TYPE A
>
> 67.115.67.162 192.168.1.252 FTP Response: 200 Type set to A.
>
> 192.168.1.252 67.115.67.162 FTP Request: PASV
>
> 67.115.67.162 192.168.1.252 FTP Response: 227 Entering Passive Mode
> (192,168,1,100,21,188)
>
> 192.168.1.252 Broadcast     ARP Who has 192.168.1.100?  Tell 192.168.1.252
> <=== PROBLEM !!!
>
>

[ Post a follow-up to this message ]

"Bernard" <qbernard@hotmail.com.discuss> wrote in message
news:e9dWS5a4EHA.2540@TK2MSFTNGP09.phx.gbl...
... 
>
> Yes, it is within the port range, to calculate it. you take the last two
> 'numbers'
> 21 * 256 + 188 = 5564
> detail -
> Information About the IIS File Transmission Protocol (FTP) Service
> http://support.microsoft.com/?id=283679

Oh! Thanks! I fell for an improper assumption. In the server response
67.115.67.162 192.168.1.252 FTP Response: 227 Entering Passive Mode
(192,168,1,100,21,188)
I improperly assumed that the "21" referred to the FTP command port. I
didn't realize that it represented the high-byte of a decimal representation
of a 2-byte value, in high+low format instead of the (in code programming)
traditional low+high format. Pure coincidence! But I should have realized
that the FTP control port 21 is always used regardless of if active or
passive mode is implemented, and thus the control port 21 (defined by RFC)
never needs to be specified (and in fact is not specified).

That leaves me only with the client side Microsoft Base Station (MBS) router
client response of
192.168.1.252 Broadcast     ARP Who has 192.168.1.100?  Tell 192.168.1.252
being the sole remaining problem; keeping in mind that 192.168.1.252 is one
of many LAN clients behind the MBS that has a static public WAN address of
67.115.67.161, while 192.168.1.100 is the IIS box behind the Linksys v2
router that has a static WAN address of 67.115.67.162. The ARP broadcast
would also occur for any other client on the internet that is behind a
router, since it wouldn't know who 192.168.1.100 is. Worse, if the LAN that
hosts the box that issues that ARP happens to have a box with a
192.168.1.100 address then an improper LAN network condition would exist!
The client side LAN problem is not constrained to my own LAN, it also occurs
for any client that is hiding behind a router (such as many do when
connecting to IIS via internet).

That ARP is a direct result of the IIS5 FTP Service response (it is not a
response from the router):
67.115.67.162 192.168.1.252 FTP Response: 227 Entering Passive Mode
(192,168,1,100,21,188)
where IIS identifies itself as being 192.168.1.100 instead of it spoofing
itself as being 67.115.67.162. If it did the spoof (if IIS could be
configured to respond like that) then the Linksys router would forward the
ports just fine to IIS (which is truly assigned a LAN address of
192.168.1.100) and passive FTP would work.

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 translation.

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. If I toss the router then I have to replace it with an
transparent IP-less firewall called "IP-Filter", which comes with FreeBSD,
if I want to take the majority of firewall load off of the server CPU
(primarily to protect it from a DoS, as well as to take the load off of its
own software based firewalls BlackIce and ZAP -- yes, I run 2 firewalls on
the IIS box!) I don't see how I can make IIS do the spoof, though, as the
IIS5 FTP Service obviously can not be configured to truly have the same WAN
address as the one that is used by its Linksys router. But I'd really like
to not have to use IP-Filter on FreeBSD, either! It's hard to maintenance.

This all is not a problem with active FTP, since the routers properly
translate and forward things for ports 20 and 21. But (most) routers do not
do the same for passive FTP data ports, although usage of the control
channel only (port 21) does still get properly translated and only the
passive data channel gets munged. Active FTP works fine. But most people
behind a router would use passive mode, if for no other reason than IE6 (in
its Advanced settings) suggests that one should do so for DSL and router
based networks!  So, I need to tell IIS5 how to spoof its FTP Service IP
address, or I need to toss the router.

Anyone know if its possible to make IIS FTP Service do the necessary spoof?
Or is there some other solution without having to toss the Linksys router?

Winguy

[ Post a follow-up to this message ]

"WinGuy" <no_spam@nomail.bot> wrote in message
news:pjDvd.33831$zx1.26989@newssvr13.news.prodigy.com...
> 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
> translation.
>
> 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.

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.  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.

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.

Alun.
~~~~
--
Software Design Engineer, Internet Information Server (FTP)
This posting is provided "AS IS" with no warranties, and confers no rights.

[ Post a follow-up to this message ]

"Alun Jones [MSFT]" <alunj@online.microsoft.com> wrote in message
news:u1qsPif4EHA.2016@TK2MSFTNGP15.phx.gbl...
> "WinGuy" <no_spam@nomail.bot> wrote in message
> news:pjDvd.33831$zx1.26989@newssvr13.news.prodigy.com... 
>
> 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
the router?

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.  

> Alun.
> ~~~~
> --
> Software Design Engineer, Internet Information Server (FTP)
> This posting is provided "AS IS" with no warranties, and confers no
> rights.

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!)

Winguy

[ Post a follow-up to this message ]

"WinGuy" <no_spam@nomail.bot> wrote in message
news:%dFvd.33842$zx1.4115@newssvr13.news.prodigy.com... 
>
> 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!

RFC 1631, the first RFC to describe what a NAT does, calls it out as a
specific example:

"  The arguments to the File Transfer Protocol (FTP) PORT command
include an IP address (in ASCII!). If the IP address in the PORT
command is local to the stub domain, then NAT must substitute this.
Because the address is encoded in ASCII, this may result in a change
in the size of the packet (for instance 10.18.177.42 is 12 ASCII
characters, while 193.45.228.137 is 14 ASCII characters). If the new
size is the same as the previous, only the TCP checksum needs
adjustment (again). If the new size is less than the previous, ASCII
zeroes may be inserted, but this is not guaranteed to work. If the
new size is larger than the previous, TCP sequence numbers must be
changed too."

PORT and PASV both quote IP addresses, in the same fashion, and should both
be analysed by the NAT, not only to be translated, but also potentially to
dynamically open ports.

> 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 the router?

No.  NATs generally enforce a separation between "inside" and "outside", and
while they will translate when they route traffic across themselves, they
will not translate packets on just one side.

> 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.

You will really need to get a NAT that works as you want.  As I said, there
are recent firmware updates listed on the Linksys site for your model of
router, so it may be that this has already been resolved, without the
technician you spoke to knowing about it.

> 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.  

These routers are pretty cheap now.  You may have spent more in terms of
time than it would cost to simply replace the router with a device that
works the way you need.

Alun.
~~~~
--
Software Design Engineer, Internet Information Server (FTP)
This posting is provided "AS IS" with no warranties, and confers no rights.

[ Post a follow-up to this message ]

"Alun Jones [MSFT]" <alunj@online.microsoft.com> wrote in message
news:O6PKyQh4EHA.2804@TK2MSFTNGP15.phx.gbl...
...
> RFC 1631, the first RFC to describe what a NAT does, calls it out as a
> specific example:
...
> PORT and PASV both quote IP addresses, in the same fashion, and should
> both be analysed by the NAT, not only to be translated, but also
> potentially to dynamically open ports.

Hmmm. If I understand the above (and the example I ommitted) then:

67.115.67.162 192.168.1.252 FTP Response: 227 Entering Passive Mode
(192,168,1,100,21,188)

is not per RFC and should instead look like:

67.115.67.162 192.168.1.252 FTP Response: 227 Entering Passive Mode
(67,115,67,162,21,188)

when exiting the BEFSR41 v2 and appearing on the internet?

Since I stipulated to IIS5, per Microsoft KB555022, what port range to use
and I assured that those ports are forwarded in the BEFSR41 router to
192.168.1.100 then the router should by RFC do the above "should instead
look like" translation and any packets arriving at the router WAN address
67.115.67.162 that are also within the forwared range of ports should get
routed to the 192.168.1.100 IIS address?

I've emailed description of the problem and the 2 related Ethereal packet
traces to Linksys, under reference number 041214-001156. They should answer
within 24 hours, the website says, and I'll post the reply here.

===== the problem =====
IIS response behind BEFSR41 v2 having WAN address of 67.115.67.162 and as
traced by client behind Microsoft Base Station having WAN address of
67.115.67.163:
67.115.67.162 192.168.1.252 FTP Response: 227 Entering Passive Mode
(192,168,1,100,21,188)

Next client packet, as traced by client behind Microsoft Base Station having
WAN address of 67.115.67.163
192.168.1.252 Broadcast ARP Who has 192.168.1.100?  Tell 192.168.1.252
===================

Winguy

[ Post a follow-up to this message ]

Well, I got my reply from Linksys but I can't quote its entirety because it
contains the text "This correspondence is considered confidential and any
reproduction for the purpose of public disclosure is forbidden without
written permission by the author". I don't think I like that attitude, as I
don't see what there should be to hide from the public. But, whatever, and
I'm not here quoting per se from the response. The response suggestions were
to (1) place the server in DMZ and/or (2) adjust the packet size in the
router setup to some value of MTU, decreasing by 10 from an initial value of
1472 until packets come non fragmented; using a special ping command format
of "ping x.x.x.x -f -1 1472" until the response does not indicate a
fragmented packet.

I've not yet tried the fragmented packet suggestion. Nor the DMZ suggestion,
which seems to defeat my purpose for usage of the router, and which is to
disallow some port ranges. But maybe I can forward disallowed port ranges to
a non-existent LAN address even if one is associated within a packet
intended for the DMZ -- I'll have to experiment and observe the result. I'd
be very surprised if either suggestion would change this problem where 2
machines behind 2 different LANs are communicating via internet and a
translation does not occur and so an ARP results and fails on any passive
FTP data channel. Active FTP works fine, though.

67.115.67.162  192.168.1.252  FTP Response: 227 Entering Passive Mode
(192,168,1,100,21,188)
192.168.1.252  Broadcast ARP Who has 192.168.1.100?  Tell 192.168.1.252
[The ARP fails because the 2 machines are not on the same LAN.]

Winguy

[ Post a follow-up to this message ]