At 07:13 PM 11/13/2003 -0800, Victor McAllister wrote:
Kory Krofft wrote:
Victor, Ray,
I added the route on the win machine and I can now browse the weblet in the 192.168.10.1 ip. and once I removed routefilter I could access the weblet intermittently on the external IP but when I tested from a friends machine over the internet it reports "connection refused".
Hmmm ... this is your real problem.
First, how are you actually doing this test? Here, I can't get either IE or Netscape to issue a "Connection Refused" message, even when connecting to a LAN server that runs nothing on port 80 and has no on-host firewall. I can get that message, right away, from "telnet 192.168.1.2 80", where that is the LAN address of a host that does not run a Web server, though.
Second, how quickly does the "Connection Refused" message pop up? Since the router's default policy for net-source traffic is DROP, a browser hitting it would take a long time, and even then probably return its version of the "There is no response fro host ..." popup box. OTOH, if the attempt is being successfully DNAT'd, then refused by the DMZ host, you would probably get a "Connection Refused" promptly.
Oh, and one other possibility to consider -- your ISP might be blocking incoming port-80 traffic, and it would probably provide the ICMP reject that triggers the "Connection Refused" result. In this case, the problem is not with your configuration, and you have to work around your ISP (typically by using port 8000 or 8080, or even sometimes 81, for the external Web server).
Best guess: your DMZ host is not configured correctly to respond through the router and DNAT. Since you've said almost nothing about the details of that host, I can't be more specific about where on it an error might be.
By intermittently I mean that I can load pages from the dmz but not images located out on the net referenced on those pages. Additionally I can no longer reach the firewall weblet on the internal ip. Instead I get the dmz weblet.How does your dmz boxen resolve names? Can you ping by name the machines on the net with the images? Does it go back to the firewall and dnscache? If so you might want to add the other interface card in the leaf box in the first section (# 1 in lrcfg dnscache configuration.)
Close, but I think not *quite* the right question. The DMZ host does not need to resolve these external references; the LAN host that runs the browser does need to. So apply Victor's questions above to the LAN host, not the DMZ host. Also check the html source that is being provided, to make sure it is delivering the correct URLs for these images. And easier and better than ping'ing these hosts (some high-volume hosts are set not to reply to pings) ... see if your browser can load the images when the URLs are entered directly into it.
As to the second part ... I'm hampered here by knowing iptables but not all the details of Shorewall. When I replied before, I assumed that Shorewall uses the interface parameter when setting DNAT rules. As I read iptables ... and I have to note that I have not tried this, just read about it ... it should be possible to DNAT *only* port-80 traffic that comes in on eth0, or on the external IP address, while handling on the router port-80 traffic that comes in on eth1, or on the router's LAN IP address. But someone with better Shorewall knmowledge than I have might want to check what actual ipchains rule(s) the configuration setting you employ actually produces.
should look like this if this if eth2 is 192.168.10.245 192.168.1.254 192.168.10.245
setup as it is currently:
routes on the win machine: Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 192.168.1.254 192.168.1.1 1 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 192.168.1.0 255.255.255.0 192.168.1.1 192.168.1.1 1 192.168.1.1 255.255.255.255 127.0.0.1 127.0.0.1 1 192.168.1.255 255.255.255.255 192.168.1.1 192.168.1.1 1 192.168.10.1 255.255.255.255 192.168.1.254 192.168.1.1 1 224.0.0.0 224.0.0.0 192.168.1.1 192.168.1.1 1 255.255.255.255 255.255.255.255 192.168.1.1 192.168.1.1 1 Default Gateway: 192.168.1.254
routes on the dmz: 192.168.1.0 via 192.168.10.254 dev eth0 192.168.10.0/24 dev eth0 proto kernel scope link src 192.168.10.1 default via 192.168.10.245 dev eth0
I assume the last line is a typo (245 for 254) only in the e-mail. If not (if it is a typo in the actual routing table), then it is the source of much of your problems.
shorewall rulesloc cannot send port 80 to two different places. It sounds like your dmz machine is also a leaf box. You will need to reconfigure weblet on one of the boxes to use another port such as 8080. You can then access it from your browser like http://192.168.10.1:8080
.........
DNAT net dmz:192.168.10.1 tcp 80 DNAT net dmz:192.168.10.1 tcp 25 DNAT net dmz:192.168.10.1 udp 25 DNAT loc dmz:192.168.10.1:80 tcp 80 - $ETH0_IP
It is hard to read this from a fragment, but I too doubt the suitability of the last DNAT rule. You should be accessing the DMZ Web server, from the LAN, using its own IP address, not the router's external IP address. But if you do that, then you should be able to have loc port-80 traffic handled on the router, while net port-80 traffic gets DNAT'd to the DMZ server.
........
shorewall policy
#SOURCE DEST POLICY LOG LEVEL LIMIT:BURST loc net ACCEPT # If you want open access to the Internet from your Firewall # remove the comment from the following line. #fw net ACCEPT net all DROP ULOG all all REJECT ULOG dmz net ACCEPT
I think I need to specify the gateway on the dmz. It also does not seem to be able to resolve dns queries. What is the proper way to provide the default gateway and dns resolution.
What do you mean by "on the dmz" in the above? You specify a gateway in a routing table on a host, not on a dmz as such. Your routing table on the DMZ host, reported above, has an entry for the default gateway (though that entry contains what I believe is a typo, as I noted above).
There is no one "proper way" to provide DNS resolution for DMZ hosts. There are several options.
1. If you run a DNS resolver on the router, let the DMZ host use it.
2. If you run a DNS resolver on the LAN, let the DMZ host use it (this is a bit risky, but only a bit).
3. Run a DMZ resolver on the DMZ host itself.
4. If the DMZ host does not need to resolve LAN hostnames (or can do it through /etc/hosts), have it use some external DNS resolver, like the ones your ISP undoubtedly provides.
These solutions do have one thing in common -- they require that the DMZ host be able to initiate connections to UDP (and maybe TCP) port 53 somewhere. Since DMZ hosts are, usually, behind firewall rules that allow them only to respond to established connections, the router needs a rule that specifically ALLOWs this traffic. Your general ALLOW policy for dmz to net traffic (is this *really* the Shorewall default???) should permit the needed connections, unless you have a specific iptables rule that blocks them. (You reported more about your ruleset in your prior message, but I no longer have it at hand to refer to. Hence my uncertainty here.)
I also need to sort out shorewall rules and policy to get DNAT to work.sounds like its working to me.
I have initrd.lrp root.lrp etc.lrp local.lrp modules.lrp sftp.lrp weblet.lrp loaded on the dmz.
Thanks guys,
------------------------------------------------------- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ------------------------------------------------------------------------ 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
