James,

On Fri, 17 Jan 2003 08:56:27 GMT James wrote:

> I've recently had a cable modem installed at my house, shared between
> 3 users.
> I've got it all working nicely with the default policies of
> 
> Net loc REJECT
> Loc net ACCEPT

A lot of people use DROP rather than REJECT for net->loc .  Both
block incoming traffic.  The difference is that DROP doesn't send
any reply to the incoming traffic while REJECT sends and ICMP
packet saying essentially "nothing is listening on this port".


> And I have added the following rules to allow my pc (192.168.1.1) to
> use Direct Connect in Active mode behind the firewall.
> 
> ACCEPT        net        loc:192.168.1.1:412     tcp
> ACCEPT        net        loc:192.168.1.1:412     udp
> DNAT          net        loc:192.168.1.1:412     tcp
> DNAT          net        loc:192.168.1.1:412     udp

You appear to be missing the DEST PORT column.  From the examples
in /etc/shorewall/rules:

  # Example: Forward all ssh and http connection requests from the
  # internet to local system 192.168.1.3
  #
  # #ACTION SOURCE  DEST            PROTO   DEST    SOURCE  ORIGINAL
  #                                         PORT    PORT(S) DEST
  # DNAT    net     loc:192.168.1.3 tcp     ssh,http

So you probably want:

  DNAT      net     loc:192.168.1.1:412  tcp   412

or

  DNAT      net     loc:192.168.1.1      tcp   412

I am not sure what the behavior is without the dest port, but
there is a chance the hole you created is bigger than intended.

The ACCEPT rules are redundant since the DNATs imply ACCEPT.


> It works fine, but is this the correct way of doing this?
> And is it fairly secure?

It's only as secure as the software listening on port 412.  I am
not familiar with "Direct Connect" so I don't know how (in)secure
it is.  If there is a vulnerability in it, the DNAT rule could
expose your entire "loc" zone via the vulnerability.  Hosts that
accept inbound connections from untrusted hosts are often placed
into a screened subnet (often called a DMZ) so if they are
compromised there is still a layer of protection between them and
the private LAN machines.  If all your sensitive data is on
192.168.1.1 anyway, then a screened subnet wouldn't offer much
additional protection.
 

> Will I have to use 2 other different ports on the firewalls external
> interface, e.g., 413 and 414, to enable this on the other two machines
> in the house?

That would work as long as you can route connecting hosts to the
correct external port for the machine they wish to connect to.


> Is there any way to just say OPEN PORT 412?

I'm not sure I understand you question, but you already opened it
with the DNAT rule.  If you're asking if <your ext. addr>:412
can point to *all of* :

  <int host 1>:412
  <int host 2>:412
  <int host 3>:412

the answer is no.  Not unless you have three public external
addresses available to you.

> Next question..
> 
> MSN Messanger file sharing and H323
> 
> I have to open a range of ports for MSNM's file sharing. Do I have to
> ACCEPT  and DNAT all of these ports for all of the 3 machines (using 3
> different ranges)?
> 
> I have glanced at the "Netfilter helper modules", but these just confuse
> the hell out of me, I'm afraid my Linux knowledge is very limited.

I am not very familiar with H323 or MSN file sharing, so I can't
help here.  I believe that topic has been covered before though.
You may want to search the leaf-user archives for more info:

  http://www.mail-archive.com/leaf-user@lists.sourceforge.net/


--Brad



-------------------------------------------------------
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your 
clients even if they use browsers that are limited to 40 bit encryption. 
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
------------------------------------------------------------------------
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Reply via email to