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 \ [EMAIL PROTECTED] ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Caffeinated soap. No kidding. http://thinkgeek.com/sf ------------------------------------------------------------------------ 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
