dan wrote:
more info

Tom: again, I went through that part of the FAQ. I noticed that my OUT= in the logs is blank. shouldnt that be my interface for 'loc' since the route is set for a destination of loc:10.223.8.10?
here:

    Shorewall:net2fw:DROP:IN=eth1 _/*OUT=*/_ MAC=00:e0:81:75:54:8f:00

Without any context, I can't answer your question. But that request came from the net and was destined for an IP address on your firewall. Therefore, OUT is empty. If that message includes "DST=10.223.8.10", then your DNAT rule has the wrong server IP address in the DEST column.



here is my interfaces:

From http://www.shorewall.net/support.htm#Guidelines:

Please do not include Shorewall configuration files unless you have been specifically asked to do so. The output of *shorewall dump* collected as described above is much more useful.


    #ZONE   INTERFACE       BROADCAST       OPTIONS
    loc     eth0    auto    routeback
    net     eth1    auto
    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE


and my rules:

        SECTION NEW
        Telnet/DNAT:info        net     loc:10.223.8.10
        FTP/DNAT:info           net     loc:10.223.8.10
        DROP:info               net     all                     tcp     3128
        DROP:info               net     all                     udp     3128
        #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE


The above assumes that the IP address of the ALPHA is 10.223.8.10 and that it is connected through eth0. It also assumes that the ALPHA's default gateway is configured with the IP address of eth0.


and my policy:

        fw      loc     ACCEPT
        fw      net     ACCEPT
        loc     fw      ACCEPT
        loc     net     ACCEPT
        net     loc     ACCEPT
        net     fw      ACCEPT
        #LAST LINE -- DO NOT REMOVE

i know, policy is not an acceptable default but i didnt want the REJECT on net -> fw and net -> loc to get in the way during my trouble shooting.

From http://www.shorewall.net/troubleshoot.htm:

I also recommend against setting all of your policies to ACCEPT in an effort to make something work. That robs you of one of your best diagnostic tools - the “Shorewall” messages that Netfilter will generate when you try to connect in a way that isn't permitted by your rule set.

If the above doesn't help, then please:

a) Set up your system the way that you believe it should be. No logging of ACCEPT and with the appropriate policies.

b) Try to connect from the net using telnet.

c) "shorewall dump" > dump.txt

Send the dump.txt as an attachment to [EMAIL PROTECTED] Include:

a) The IP address of the system that you tried to connect from.
b) The IP address that you tried to connect to (don't use DNS names).
c) Describe what happened (connection refused? timeout? firewall exploded in flames? Other?).

Thanks,
-Tom
--
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ [EMAIL PROTECTED]
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key

Attachment: signature.asc
Description: OpenPGP digital signature

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Reply via email to