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:10.1.1.1 tcp smtp -
216.236.142.81:10.1.1.200
> ACCEPT loc loc:10.1.1.252 tcp www -
216.236.142.82:10.1.1.200
> ACCEPT loc loc:10.1.1.253 tcp www -
216.236.142.83:10.1.1.200
> ACCEPT loc loc:10.1.1.254 tcp www -
216.236.142.84:10.1.1.200
> (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 10.1.1.0/24!10.1.1.252,10.1.1.253,10.1.1.254,10.1.1.63,10.1.1.1
>
> 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
connection.
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,
HOW COULD THERE POSSIBLY BE ANYTHING IN THE MESSAGES? YOU HAVE THE
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=216.194.21.212 dst=216.236.142.81
sport=1656
> dport=21 src=10.1.1.1 dst=216.194.21.212 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 [216.194.21.212], 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
--
Tom Eastep \ Shorewall - iptables made easy
AIM: tmeastep \ http://www.shorewall.net
ICQ: #60745924 \ teastep@shorewall.net