[Shorewall-users] Re: [leaf-user] 3 Bering problems

Tom Eastep teastep@shorewall.net
Thu, 4 Jul 2002 07:00:21 -0700 (PDT)

On Wed, 3 Jul 2002, Nachman Yaakov Ziskind wrote:

> policy:   everything ACCEPT

Nachman -- I and others have tried to point out why this isn't a good
idea, even when you are just trying to make something work. Apparently you
aren't listening. See more below.

> Rules:
> ACCEPT  loc     loc:    tcp     smtp    -
> ACCEPT  loc     loc:  tcp     www     -
> ACCEPT  loc     loc:  tcp     www     -
> ACCEPT  loc     loc:  tcp     www     -
> (the above four rules put in per Tom Eastep in order to allow inside boxes to 
> use the NAT'ed servers)
> REJECT          net     loc             tcp     1433
> REJECT          net     loc             udp     137
> REJECT          net     loc             udp     138
> REJECT          net     loc             udp     139
> (the rest as in the original)
> NAT:
> eth0!,,,,
> I have three problems (should I post them separately?)
> 1) Incoming connections to the servers are identified as coming from the
> router, not the original IP address. This makes life difficult for several
> reasons. How do I address this?

The "rules" above do exactly that.

On my web site and in my posts on mailing lists, I have consistently
recommended that people use a DNS solution rather than an IP solution to
the problem that you sere trying to solve (basically the problem
described in Shorewall FAQ #2). When I made that recommendation to you, 
you replied:

"I have no clue what Bind 9 views is, or how to set it up. But I suspect
it involves doing things through DNS. I further suspect it will be like
pulling teeth with every w/s pointing to my ISP's DNS servers. I suppose I
*could* just load a hosts file on every workstation. Ouch."

Given your response, I made the recommendation that resulted in the rules
that you have above. One of the features of that solution is that all
redirected connections look to the server as if they were initiated by the
firewall. That is absolutely necessary since the server MUST reply back
through the firewall so that the firewall can "de-NAT" the reply packets.

If having the connections appear to come from the firewall is a problem 
for you then you need to switch to a DNS solution.

> 2) FTP connections do not work. That is, web based ftp does not work, but
> command line seems to be fine. This mysifies me as I thought ftp encapsulated
> in the browser would stress the router less(?)

The FTP 101 class is now in session.

There are two ways in which FTP can send data:

a) Active Mode. The client issues a PORT command indicating that is is
listening on a given IP address and transient port. The Server connects to
that IP/port and the data is sent over this secondary connection.

b) Passive Mode. The client issues a PASV command and the server replies
with the IP address and transient port number that it is listening on. The
client connects to that IP/port and the data is sent over this secondary 

Browsers normally default to passive mode whereas command line clients 
default to active mode. Given that active mode works but passive mode does 
not, the problem is probably at the server end. 
> Nothing in messages, 

FIREWALL WIDE OPEN!!!!!!!!!! I'll repeat what I and others have told you
before -- setting all of your policies to ACCEPT robs you of one of your
most valuable diagnostic tools, namely the messages that Netfilter 
generates when you get a connection request that is not covered by your 
rules and is against policy.

> but this in `shorewall status`:
> tcp      6 431875 ESTABLISHED src= dst= sport=1656
> dport=21 src= dst= sport=21 dport=1656 [ASSURED] use=1
> On the server side:
> Jul  3 21:33:57 egps ftpd[28601]: FTP LOGIN FROM as5300-6.216-194-21-
> 212.nyc.ny.metconnect.net [], awacs
> So I assume a connection has been established, and it just sits there.
> after breaking out:
> Jul  3 21:39:35 egps ftpd[28601]: FTP session closed
> I have loaded:
> ip_conntrack_ft p/ ip_conntrack_irc / ip_nat_ftp /ip_nat_irc

In general, if you have the modules loaded that you mention (does "lsmod" 
show that they are really loaded?), you shouldn't have any problems like 
this. If you have Masquerading/NATing Bering firewalls at both ends of 
the connection then you need the ip_conntrack_ftp and ip_nat_ftp modules 
loaded in both firewalls.

Tom Eastep    \ Shorewall - iptables made easy
AIM: tmeastep  \ http://www.shorewall.net
ICQ: #60745924  \ teastep@shorewall.net