Hi guys... I had a problem, with the SuSE Firewall on a SuSE 8.x box... the problem is that the internal PC's are having problems reaching the Web Server that it's installed on the same NAT box... I set up the firewall using YAST, and put the 80 from the allowed services... also the firewall didn't had the protect internal services check box enabled... any clue ? Thanks bye --ed
On Fri, 2003-07-25 at 03:30, Eduardo J. Vega A wrote:
Hi guys... I had a problem, with the SuSE Firewall on a SuSE 8.x box... the problem is that the internal PC's are having problems reaching the Web Server that it's installed on the same NAT box... I set up the firewall using YAST, and put the 80 from the allowed services... also the firewall didn't had the protect internal services check box enabled... any clue ?
Use the internal IP to connect to it, by default NATed clients are blocked from using the external IP. If you are using the internal IP and you're still having problems, check that the web server is really listening on the internal interface (if it's apache, look at the Listen option in httpd.conf)
Hi !! thanks for your answer... but.. the Apache srv it's configured to listen on booth interfaces... but the clients seems to be blocked.... and also when the clients request the IP to the DNS the dns response the public IP of that box.... =( as I think that it should be... but then didn't get any answer from the srv
Hi guys... I had a problem, with the SuSE Firewall on a SuSE 8.x box...
On Fri, 2003-07-25 at 03:30, Eduardo J. Vega A wrote: the
problem is that the internal PC's are having problems reaching the Web Server that it's installed on the same NAT box... I set up the firewall using YAST, and put the 80 from the allowed services... also the firewall didn't had the protect internal services check box enabled... any clue ?
Use the internal IP to connect to it, by default NATed clients are blocked from using the external IP.
If you are using the internal IP and you're still having problems, check that the web server is really listening on the internal interface (if it's apache, look at the Listen option in httpd.conf)
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
--ed Inside your PC is a daemon waiting to be unleashed. Free it with FreeBSD.
is there any way on which I could enable the internal clients to be hear by the NAT box ?
Hi guys... I had a problem, with the SuSE Firewall on a SuSE 8.x box...
On Fri, 2003-07-25 at 03:30, Eduardo J. Vega A wrote: the
problem is that the internal PC's are having problems reaching the Web Server that it's installed on the same NAT box... I set up the firewall using YAST, and put the 80 from the allowed services... also the firewall didn't had the protect internal services check box enabled... any clue ?
Use the internal IP to connect to it, by default NATed clients are blocked from using the external IP.
If you are using the internal IP and you're still having problems, check that the web server is really listening on the internal interface (if it's apache, look at the Listen option in httpd.conf)
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
--ed Inside your PC is a daemon waiting to be unleashed. Free it with FreeBSD.
On Fri, 2003-07-25 at 04:12, Eduardo J. Vega A wrote:
is there any way on which I could enable the internal clients to be hear by the NAT box ?
Look for these lines in /sbin/SuSEfirewall2 ############################################################### # Anti Spoofing/Cirumvention protection - interface dependent # ############################################################### for DEV in $FW_DEV_INT; do for IP in $DEV_EXT; do $IPTABLES -A INPUT -j LOG ${LOG}"-ACCESS_DENIED_INT " -i $DEV -d $IP $IPTABLES -A INPUT -i $DEV -d $IP -j "$DROP" done done and comment them out and restart the firewall. Note that I'm not sure if those lines were put in there for a reason. It could be a security risk to remove them. Having said that, it looks pretty risk free to remove them, since they only test for the internal NIC, packets coming on the external NIC are blocked elsewhere. If the above lines are really useful, it strikes me as a kernel bug, but then I'm no security expert Another alternative would be to set up something so the internal machines get the internal IP when they look up the name of the server
participants (2)
-
Anders Johansson
-
Eduardo J. Vega A