NAT question. Passive inbound FTP to masq'd server.
Matthew Schalit
Now that NAT has been released, I would like to know the
capabilities of it to support passive inbound ftp from a
remote client to a masq'd internal server.
That occurs, as you may know, when the remote user is running
Netscape and they try the url, ftp://mydom.com/
The problems that most NAT subsystems have, as you may also
know, is that they only masq the ip addresses that are in the
datagram header, and they don't manipulate the protocol data.
A passive ftp server sends its IP address and a port number in
respose to the PASV command sent by Netscape, but that IP address
is unfortunately the real private one, like 10.1.1.28.
The GnatBox can manipulate that protocol data.
The Linux Router Project can not.
Can SCO's implementation of NAT do this?
I'd try it, but there's no TLS for Uw7 yet.
Thanks,
Matt
----------------------
Lose dablues to reply.
Tony Lawrence
>
> Now that NAT has been released, I would like to know the
> capabilities of it to support passive inbound ftp from a
> remote client to a masq'd internal server.
I can, using NAT, ftp from any of the clients on my network
and get files from SCO, from my own website, and any place
else I've been so far..
--
Tony Lawrence (to...@aplawrence.com)
SCO articles, help, book reviews, tests,
job listings and more : http://www.ApLawrence.com
Matthew Schalit
|Matthew Schalit wrote:
|>
|> Now that NAT has been released, I would like to know the
|> capabilities of it to support passive inbound ftp from a
|> remote client to a masq'd internal server.
|
|I can, using NAT, ftp from any of the clients on my network
|and get files from SCO, from my own website, and any place
|else I've been so far..
I just successfully used Netscape to connect to
ftp.aplawrence.com. It worked very well :) May I
ask if that ftp server is on a private LAN behind an OS5
firewall/router/NAT box?
Thanks!
Matt
Tony Lawrence
No, that site is served by an ISP- no OS5 involved.
But my point was that I haven't yet seen an ftp site that
the NAT clients can't access, download from, etc. with
Netscape or IE or from command line FTP. There's no problem
with it at the NAT level.
That doesn't mean that you wouldn't have problems if you
start using firewall configurations. I regretfully haven't
yet had the time to even begin to look at the firewall
aspects of the ipfilter pakage, so I don't know what
provisions it makes for ftp- someone else here may..
Shaukat Manji
Matthew Schalit
|Matthew Schalit wrote:
|>
|> Recently, to...@aplawrence.com said...
|> |Matthew Schalit wrote:
|> |>
|> |> Now that NAT has been released, I would like to know the
|> |> capabilities of it to support passive inbound ftp from a
|> |> remote client to a masq'd internal server.
|> |
|> |I can, using NAT, ftp from any of the clients on my network
|> |and get files from SCO, from my own website, and any place
|> |else I've been so far..
|>
|> I just successfully used Netscape to connect to
|> ftp.aplawrence.com. It worked very well :) May I
|> ask if that ftp server is on a private LAN behind an OS5
|> firewall/router/NAT box?
|
|No, that site is served by an ISP- no OS5 involved.
|
|But my point was that I haven't yet seen an ftp site that
|the NAT clients can't access, download from, etc. with
|Netscape or IE or from command line FTP. There's no problem
|with it at the NAT level.
|
Ok. If there are no packet fileter rules keeping traffic from
moving, then my question is a function of NAT capability alone.
An ftp client on a masq'd private LAN, downloading from the net,
is very different from an ftp server on a masq'd private LAN,
being contacted by a remote client on the net in PASV mode.
The reason is complex and has to do with the IP address and port
that the server reponds with, to the PASV command.
Until someone has had success with it, I still can't be sure, and
I'm sorry that I sort of need other people to be curious when I don't
have an OS5 test box.
Thanks Tony,
Matt
Jean-Pierre Radley
| Could someone tell me where to get the Nat package from?
It's in TLS709.
--
JP
John Temples
Tony Lawrence <to...@aplawrence.com> wrote:
>But my point was that I haven't yet seen an ftp site that
>the NAT clients can't access, download from, etc. with
>Netscape or IE or from command line FTP. There's no problem
>with it at the NAT level.
Matthew is asking whether OSR5 NAT supports an FTP *server* on the
private network, not a client.
--
John W. Temples, III
Tony Lawrence
> An ftp client on a masq'd private LAN, downloading from the net,
> is very different from an ftp server on a masq'd private LAN,
> being contacted by a remote client on the net in PASV mode.
Well, yeah, that's an entirely different thing.
If I understand you correctly, what you want is this:
------ --------- ++++++++++++++
| | | | + +
| Box A | --> | NAT Srv | ---> + Internet +
| | <-- | | <--- + +
------- ---------- ++++++++++++++
And you want Box A to be an FTP server so that someone from
the Internet can access it.
So you'd have some IP address that would come tripping down
to the NAT server, and it would pass it to Box A, and keep
track of the ftp sessions so that everything went where it's
supposed to.
That's a firewall, not NAT. And the problem isn't really
that it's passive ftp or normal ftp- it's that Box A is
invisible.
A quick simple explanation of ftp/passive ftp for those not
familiar with it:
Ftp is a little different than most protocols. When you
connect to an ftp server, you connect on what's called the
"Control" port. When you want to transfer a file, the ftp
server opens a data connection back to you. There's two
connections: one that you originated, and one that the
server opened for data. And there's the problem for most
firewalls: they block that data connection because it comes
from outside.
Passive ftp works by the client (that's you) telling the
server to use Passive mode-the client opens it's own data
connection, and the server uses that. The server is being
"passive"- it isn't actively opening connections. For your
typical firewall, that's much easier- the connection
originates inside the firewall, therefore it's OK (though
the firewall does usually have to be told that this is OK
ahead of time).
From the strict NAT side of things- where Box A is the
client trying to access an ftp site on the Internet, the
regular ftp session is the bitchier of the two- the passive
mode is easy, but for normal ftp the NAT has to know who
that data connection that suddenly comes knocking belongs
to. But, if it has properly mangled eveything and kept
track of who's doing what, it can do the magic, and it does.
But for Box A to be the server, that's upside down. Now
it's the client that comes knocking, and something has to
pass it to Box A. That's so whether the client wants the
server to be passive or not. Actually, for that, I'd think
it would be easier if it were NOT passsive, because with
passive we have two outside visitors to contend with, but
otherwise only half originates outside. But I'm no firewall
expert.
Again, I haven't even begun to look at the rest of the
ipfilter package to see what, if anything, it could do like
this, but I don't think ipnat by itself is going to help
you.
Looking into ipfilter was something I really wanted to do
this month, but it's turning out to be so busy, I don't know
if I can get to it :-(
Tony Lawrence
Yeah :-)
I totally misunderstood him at first, but see now that he
was rather clear about it and it was entirely my fault.
Matthew Schalit
|Matthew Schalit wrote:
|
|> An ftp client on a masq'd private LAN, downloading from the net,
|> is very different from an ftp server on a masq'd private LAN,
|> being contacted by a remote client on the net in PASV mode.
|
|Well, yeah, that's an entirely different thing.
|
|If I understand you correctly, what you want is this:
|
| ------ --------- ++++++++++++++
|| | | | + +
|| Box A | --> | NAT Srv | ---> + Internet +
|| | <-- | | <--- + +
| ------- ---------- ++++++++++++++
|
|And you want Box A to be an FTP server so that someone from
|the Internet can access it.
Exactly. There are Box A, Box B, and Box C, all hidden behind
a NAT Srv that is using my one registered IP address.
Box A is the ftp server.
My hypotheical also states that there are no "firewall" rules
to keep traffic out. Everything is allowed in and out of both
NAT Srv nics. Also the NAT Srv is set to forward inbound connections
on it's port 21 to Box A's port 21.
...
|Passive ftp works by the client (that's you) telling the
|server to use Passive mode-the client opens it's own data
|connection, and the server uses that.
Here you left out the crucial part. This is crux of my whole
point, and it involves the details that you were so kind to
bring up. You statement would have been more complete and
would have highlighted my problem if you had written:
"Passive ftp works by the client (that's you) telling the
server to use Passive mode (with the PASV command) when
the client asks for a file. The server responds on the
control port with the server's IP address and a port
number to which the client should open the data connection.
-the client opens (this) data connection, and the server
uses that."
Now when the server responds to PASV with it's IP address and
a good data port for the client to use,
**** the server sends its private IP address and a port ****
That's the problem. It sends 10.1.1.24, not the NAT Srv IP that's
the registered one. I'm not sure if I can make that clearer,
but please let me know.
Sooo, this datagram, with the bad private address and useless port number
in the protocol data, goes out to the NAT Srv where the source
address and source port gets properly masq'd, but does the protocol data's
bad IP, 10.1.1.24, get modified too?
|(... for brevity)
Thanks!
Matt
--------------
Lose dablues.
Tony Lawrence
> Now when the server responds to PASV with it's IP address and
> a good data port for the client to use,
> **** the server sends its private IP address and a port ****
>
> That's the problem. It sends 10.1.1.24, not the NAT Srv IP that's
> the registered one. I'm not sure if I can make that clearer,
> but please let me know.
Well, yeah. Because (AFAIK) NAT doesn't dig into packets
and try to understand their purpose. The ftp server's
response is just data to be interpreted by the client, from
NATS pov.
For this to work, I'd say that either the server has to be
aware that it's passing through NAT (so it packs its
responses properly), or the NAT server has to do stateful
inspection of packets from the server and modify data rather
than just source addresses.
But again, I'm so far from an expert at ipfilters or even
firewalls in general that I could be completely wrong.
There could be a lovely little command switch that says
"Passive server at xxx.xxx.xxx.xxx - inpect its packets and
fix 'em up, 'kay?". Conceptually I could see that could be
done- but don't have the beginnings of a clue as to whether
it has been.
Matthew Schalit
Recently, to...@aplawrence.com said...
|...
|For this to work, I'd say that either the server has to be
|aware that it's passing through NAT (so it packs its
|responses properly), or the NAT server has to do stateful
|inspection of packets from the server and modify data rather
|than just source addresses.
Ah yes, stateful packet inspection and manipulation of
protocol data. That is what I seek.
Which humorously leads me back to my original question
for this thread:
> Now that NAT has been released, I would like to know the
> capabilities of it to support passive inbound ftp from a
> remote client to a masq'd internal server.
> ...
> The GnatBox can manipulate that protocol data.
> The Linux Router Project can not.
> Can SCO's implementation of NAT do this?
> I'd try it, but there's no TLS for Uw7 yet.
Thanks for your time,
Matt
----------------------
Lose dablues.
Bill Vermillion
Matthew Schalit <msch...@pacbell.net.dablues> wrote:
>The GnatBox can manipulate that protocol data.
>The Linux Router Project can not.
>Can SCO's implementation of NAT do this?
Just one comment. The GnatBox is an ICSA certifed commercial
firewall. It's cost is in the range of a complete small SCO
system. That puts it in an entirely different category.
--
Bill Vermillion bv @ wjv.com
Tony Lawrence
>
> Ah yes, stateful packet inspection and manipulation of
> protocol data. That is what I seek.
>
> Which humorously leads me back to my original question
> for this thread:
But haven't we all enjoyed the journey? :-)
>
> > Now that NAT has been released, I would like to know the
> > capabilities of it to support passive inbound ftp from a
> > remote client to a masq'd internal server.
Well, I think we've had plenty enough exposure of this
question, and have kicked it around from enough different
directions that if anybody here knew yeah or nay, they would
have said so by now.
The source for ipfilter is easily found on the net, and
there are quite a few web pages that discuss it- perhaps you
could find your answer there.
Matthew Schalit
|> > capabilities of it to support passive inbound ftp from a
|> > remote client to a masq'd internal server.
|
|The source for ipfilter is easily found on the net, and
|there are quite a few web pages that discuss it- perhaps you
|could find your answer there.
Thank for the hint. I took a look there and read up a bit in
their mailing list archives. It turns out that data manipulation
has been talked about many times, but not implemented yet for ftp.
There are discussions about how to use proxies and other setups.
But the good news was a pointer to modifying wu-ftpd, not the firewall.
That's really where the problem is, the ftpd sends back a private address
and some port >1024.
So I searched the wu-ftpd archives and it turns out that this
is already supported in wu-ftpd 2.5.0 and up. One would just enter
the followig in their /etc/ftpaccess file:
passive address 63.194.213.179 0.0.0.0/0
passive ports 60000 65534
Which would send my external valid ip, 63.194.213.179, and some port
number in the range 60000 - 65534, instead of the private ip.
Unfortunately, SCO is only using wu-2.4.2-academ, not wu-2.5.0 nor wu-2.6.0,
for their operating systems. I can't complain. I got close!
Thanks,
Matthew
Jean-Pierre Radley
|
| Unfortunately, SCO is only using wu-2.4.2-academ, not wu-2.5.0 nor wu-2.6.0,
| for their operating systems. I can't complain. I got close!
Which does not prevent *you* from running wu-ftpd 2.6.0, which I highly
recommend you do!
--
JP
Matthew Schalit
Please don't follow up my post with a load of fragments. They make
it difficult to communicate. Why would you "highly recommend"
2.6.0? And what makes you qualified to make these recommendations?
Are you involved in the ongoing development of 2.4.2 and 2.6.0? Do you
have some sort of professional position in which you're working on
wu-ftpd and its security with respect to Uw7? You apparently didn't know
about the passive command that can be put in ftpaccess, didn't want to
tell us, or just didn't bother reading this one thread.
Thanks,
Matt
--------------
Lose dablues.
Tony Lawrence
>
> Recently, j...@jpr.com said...
> |Matthew Schalit propounded (on Mon, Jan 10, 2000 at 05:14:10PM -0800):
> ||
> || Unfortunately, SCO is only using wu-2.4.2-academ, not wu-2.5.0 nor wu-2.6.0,
> || for their operating systems. I can't complain. I got close!
> |
> |Which does not prevent *you* from running wu-ftpd 2.6.0, which I highly
> |recommend you do!
>
> Please don't follow up my post with a load of fragments. They make
> it difficult to communicate.
Excuse me? While I'm quite sure JPR is perfectly capable of
telling you where to stick it himself, let me say that there
was not a damn thing wrong with his reply and your
complaints are moronic.
> Why would you "highly recommend"
> 2.6.0? And what makes you qualified to make these recommendations?
> Are you involved in the ongoing development of 2.4.2 and 2.6.0? Do you
> have some sort of professional position in which you're working on
> wu-ftpd and its security with respect to Uw7? You apparently didn't know
> about the passive command that can be put in ftpaccess, didn't want to
> tell us, or just didn't bother reading this one thread.
Oh, sheesh. Another one for the list of people to remember
not to bother to try to help.
Matthew Schalit
|Matthew Schalit wrote:
|>
|> Recently, j...@jpr.com said...
|> |Matthew Schalit propounded (on Mon, Jan 10, 2000 at 05:14:10PM -0800):
|> ||
|> || Unfortunately, SCO is only using wu-2.4.2-academ, not wu-2.5.0 nor
|> || wu-2.6.0, for their operating systems. I can't complain.
|> || I got close!
|>
|> |Which does not prevent *you* from running wu-ftpd 2.6.0, which I highly
|> |recommend you do!
|>
|> Please don't follow up my post with a load of fragments. They make
|> it difficult to communicate.
|
|Excuse me?
Please don't take offense, Tony. My comments were a follow up to JP's.
They were not directed towards you, as you've always been a gentleman.
JP, on the other hand, has lambasted people to no end about irrelevant
issues such as spelling and grammar, and he was plenty quick to unload
on me after my first post here, years ago. I said "Please," and I argue
with logic. I have not jumped in on any number of his threads that I
thought were childish or sophomoric. I will not, however, stand by while
he tries to patronize me with ** exclamations! about what he recommends
I do for my system, as if I didn't know that I could compile programs
myself.
|While I'm quite sure JPR is perfectly capable of
|telling you where to stick it himself, let me say that there
|was not a damn thing wrong with his reply and your
|complaints are moronic.
I'll not argue with your opinions regarding my post.
It should suffice to say that fragments are errors just as
non-sequitors are errors, which make comprehension difficult.
|
|> Why would you "highly recommend"
|> 2.6.0? And what makes you qualified to make these recommendations?
|> Are you involved in the ongoing development of 2.4.2 and 2.6.0? Do you
|> have some sort of professional position in which you're working on
|> wu-ftpd and its security with respect to Uw7? You apparently didn't know
|> about the passive command that can be put in ftpaccess, didn't want to
|> tell us, or just didn't bother reading this one thread.
|
|
|Oh, sheesh. Another one for the list of people to remember
|not to bother to try to help.
Here I follow the time honored method of questioning someone's
professional ability to render opinions on a highly technical subject.
This was an opinion offered without qualifying reasons nor sufficient
knowledge of mitigating circumstances. I happen to participate in several
firewall and router discussion groups to which I've posted several packet
filter scripts that are being used worldwide on people's firewalls. Doing
so has opened me up to increased hacker attempts at the rate of several per
day and night. When I run something on my Uw7 system, I am counting on
SCO to provide me with timely security SSE's that help me to defend my
network against the latest threats and CERT advisory issues that cover
daemons like wu-ftpd. What about compatibility or stability? Why 2.6.0?
Why not 2.5.0? Why not recommend waiting until some specific issue is
resolved. Does he know of any issues? Does he have the capacity to
render judgements because he knows of or works on some issues? Has he
even compiled and run it on Uw7? I have no idea whatsoever about his
ability to make such a judgement call, based on what knowledge I have
so far. I see no other recourse but to question the entire post.
Also, recently in the cuum ng, JP posted another questionable
followup to one of my posts based on insufficient data, and I've had
enough of that. I was trained by some of the brightest professors of our
time to question the opinion, the person rendering the opinion, their
reasons and their capacity to do so.
I was trying to find out if ipfilter on OS5 supported passive inbound ftp
to a masq'd server. We had a nice conversation about that. Then someone
jumped in and made an abrupt statement that I can't decipher about me and
my situation, and I called them on it.
Don't get too bent out of shape. One day I thought we'd go fishing.
If not, well, I understand how this could bug you, and I apologize
for that. I'm saddened if this thread has caused you stress. Sorry.
Take care,
Matt