NATD and Quake1

NATD and Quake1

Post by Marc Si » Fri, 02 Apr 1999 04:00:00




Quote:>>is a TCP connection to port 43 btw). It does special-case certain other
>>connections, primarily incoming FTP data connections (which can reasonably

>Besides the obvious NATd problem with mIRC's identd...I also have trouble
>with FTP servers on ports other than.  Trying to connect to an FTP Server
>Port 30, for example, by a Win box from the subnet.  The connection is made,
>but upon listing any directory it hangs and then finally gives the error
>msg, control connection closed.

>Why is this?

That's what I meant by special-case - NAT (which for FreeBSD means libalias)
"understands" the FTP protocol, including the port numbers it uses and the
pattern of communication in a normal (active) FTP request. Since the only way
it can really know an FTP control connection from a popular garden tool is by
the port number, changing the port number turns off all the special-casing,
and the FTP control connection becomes just another TCP connection (as far as
natd is concerned). The result is that natd won't store the extra state or
jump through the extra hoops to make incoming FTP data connections work, so
they bounce off the NAT host. Using passive FTP will fix this, since NAT is
just fine with any outgoing TCP connection.

Again, this is also why some UDP services can work - inbuilt understanding
of the application protocol in question. It's not (by far) the most elegant
way to solve these problems, but it's currently the only one.

--

If you can't play with words, what good are they?

 
 
 

NATD and Quake1

Post by CyberCa » Fri, 02 Apr 1999 04:00:00


<SNIP>

Quote:>That's what I meant by special-case - NAT (which for FreeBSD means
libalias)
>"understands" the FTP protocol, including the port numbers it uses and the
>pattern of communication in a normal (active) FTP request. Since the only
way
>it can really know an FTP control connection from a popular garden tool is
by
>the port number, changing the port number turns off all the special-casing,
>and the FTP control connection becomes just another TCP connection (as far
as
>natd is concerned). The result is that natd won't store the extra state or
>jump through the extra hoops to make incoming FTP data connections work, so
>they bounce off the NAT host. Using passive FTP will fix this, since NAT is
>just fine with any outgoing TCP connection.

Ok, I'm understanding protocals better now...two people have mentioned using
passive mode.  Is this something I enable for NATd, or is it enabled for the
FTP client (i.e CuteFTP)

Thanks...

 
 
 

NATD and Quake1

Post by Fast Eddi » Sat, 03 Apr 1999 04:00:00


Quote:>Ok, I'm understanding protocals better now...two people have mentioned
using
>passive mode.  Is this something I enable for NATd, or is it enabled for
the
>FTP client (i.e CuteFTP)

>Thanks...

*cat,

You set that in your FTP Client, for example, I use LeapFTP (best Windows
FTP Client IMHO) and I set PASV/Passive mode under Preferences->General. So
whatever client you use, look under the Client's options or preferences tab.
And if you can't find it still, resort to the Client's Helpfile :)

Have a good one,
FastEddie

 
 
 

NATD and Quake1

Post by Fast Eddi » Sat, 03 Apr 1999 04:00:00


Ok, After talking to manydifferent people on here, in #freebsd on EFNET, and
to some friends that run FreeBSD, I have been told that I am out of luck as
to playing Quake1 through plain old NATD, so they pointed me to
http://www.finnish.allied.quakers.org/proxy/dl_nq.html
That will do the job :)  Just wanted to close out this chat topic and thank
all of you for all of your help, responses, and info :)  I hope I can give
1/4 of the help back that I just received the past few days.

Thanks again and have a good one,
FastEddie

 
 
 

NATD and Quake1

Post by Pascal Gieng » Sat, 03 Apr 1999 04:00:00



>That's what I meant by special-case - NAT (which for FreeBSD means libalias)
>"understands" the FTP protocol, including the port numbers it uses and the
>pattern of communication in a normal (active) FTP request. Since the only way

Hmm there are also implementations of NAT daemons which are protocol-aware
and are sniffing protocol data to be able to handle things differently
(and to leave another security hole open.. ;-) ) (I don't know any of them
which are free, however).

NAT on Bintec Brick Routers can do active FTP and IRC DCC in incoming
direction. The PORT resp. DCC commands are recognized and the ports are put
temporarily in the incoming NAT table...
If you don't know this it is a security hole... Theoretically you have
the possibility of to alter the NAT table without knowledge of the people
inside.

So I prefer a daemon not doing this and restricting all to outgoing
connections (and a few statical entries for a mail and www server).
DCC on IRC isn't so important for business....

Pascal
--
Unix,   Pascal Gienger, Moosstr. 7 /\ 7 .rtssooM ,regneiG lacsaP    xinU

& WWW       http://pascal.znet.de/    \ed.tenz.lacsap\\:ptth       WWW &
        http://echo.znet.de:8888/ echo \8888:ed.tenz.ohce\\:ptth

 
 
 

NATD and Quake1

Post by Marc Si » Sat, 03 Apr 1999 04:00:00



Quote:>NAT on Bintec Brick Routers can do active FTP and IRC DCC in incoming
>direction. The PORT resp. DCC commands are recognized and the ports are put
>temporarily in the incoming NAT table...
>If you don't know this it is a security hole... Theoretically you have
>the possibility of to alter the NAT table without knowledge of the people
>inside.

The FTP hole isn't all that large; the NAT server doing that should be smart
enough not to respect (or even look for) PORT commands unless there's an
established FTP control connection from the same client to the same server.
That may make some of the weirder uses of proxy FTP fail, but the main use of
that these days is to try and circumvent FTP restrictions. :)  The IRC DCC
hole is a bit bigger, but IRC DCC is a pretty big hole in the first place, so
restricting it on a firewall wouldn't be entirely unreasonable.

Looking at the libalias source on a 2.2.8 system, it does have code to
handle both these cases (incoming FTP PORT and IRC CTCP DCC), as well as most
uses of ICMP and simple timer-based state for two-way UDP relationships.  It's
a *really* nice implementation (though it could stand to be further divorced
from the kernel firewall code).

--

If you can't play with words, what good are they?

 
 
 

NATD and Quake1

Post by Brian Some » Tue, 06 Apr 1999 04:00:00




Quote:> Welp, I recently received cable access from mediaone.net, and setup a nice
> FreeBSD server.   It's running 3.1-032699-Stable, snap, I got it from
> releng22.freebsd.org.  ANYWAYS, I  have played several games from my Win98
> box, over natd successfully.  Quake1 CTF however is a different story.

> /sbin/ipfw -f flush
> /sbin/ipfw add divert natd all from any to any via xl1
> /sbin/ipfw add pass all from any to any

> that is my rc.firewall.    If there is anything any of you could suggest,
> I'd greatly appreciate it.

Wow, what a thread !

You *can* get Quake running through natd, but I'm afraid I can't tell you
what the magic port numbers are off the top of my head.  You can figure
them out though.

If you run tcpdump on your outgoing interface, you should see the packets
that come back - there's a range of port numbers that you need to grab...
something in the 6000 range AFAIR.

Using the latest version of natd (in -current & -stable) you can use
port ranges with the -redirect_port command.

If you figure out the ports, I promise to add an entry to the FAQ this
time ;-)

Quote:> Thanks in advance,
> FastEddie

--

      <http://www.Awfulhak.org>
Don't _EVER_ lose your sense of humour !
 
 
 

NATD and Quake1

Post by CyberCa » Wed, 07 Apr 1999 04:00:00


Thanks, it worked like a charm.


>>Ok, I'm understanding protocals better now...two people have mentioned
>using
>>passive mode.  Is this something I enable for NATd, or is it enabled for
>the
>>FTP client (i.e CuteFTP)

>>Thanks...

>*cat,

>You set that in your FTP Client, for example, I use LeapFTP (best Windows
>FTP Client IMHO) and I set PASV/Passive mode under Preferences->General. So
>whatever client you use, look under the Client's options or preferences
tab.
>And if you can't find it still, resort to the Client's Helpfile :)

>Have a good one,
>FastEddie

 
 
 

NATD and Quake1

Post by Fast Eddi » Thu, 08 Apr 1999 04:00:00


Brian,

    I resorted to using "faqproxy."  This is what many on the #FreeBSD
channel on EFNET suggested and it works great.  I will try TCPDUMP in the
near future though.  Thanks for the advice :)

Have a good one,
FastEddie

 
 
 

NATD and Quake1

Post by Brian Some » Mon, 12 Apr 1999 04:00:00




Quote:> Brian,

>     I resorted to using "faqproxy."  This is what many on the #FreeBSD
> channel on EFNET suggested and it works great.  I will try TCPDUMP in the
> near future though.  Thanks for the advice :)

I've extended the FAQ entry for ppp at

  http://www.FreeBSD.org/FAQ/userppp.html

to cover this stuff (it includes the apparently `correct' port).
The same info should apply for natd.

Quote:> Have a good one,
> FastEddie

--