Shorewall users - Oct 2003 - Blocking a port but not showing the effect(s) in the log file?

(This is probably going to get me flamed but .. so be it..)
 
<shields>
 
Im running Shorewall with a DMZ. In the DMZ I have a tomcat server. I
have the following rules set up to allow traffic to / from the DMZ:
 
(rules)
# rules (including entry in ''nat'') for making DMZ server
accessible
ACCEPT          net     dmz:192.168.100.10      tcp 80,443,8080
DNAT            loc     dmz:192.168.100.10      tcp 80,443,8080 -
155.229.27.54
 
 
(nat)
#EXTERNAL       INTERFACE       INTERNAL        ALL INTERFACES
LOCAL
155.229.27.54   eth0:0          192.168.100.10  no
no
 
 
 
So far so good. Works fine for serving pages. I have an applet that I
would like to have correspond with my tomcat process. When this applet
is run against an identical tomcat server running inside the "local
zone" (IE doesn''t interact with the firewall) it works ok. When
this
applet is directed at the tomcat server in the DMZ I get 

java.net.ConnectException: Connection refused:

The stack trace shows that the offending line is a call to
URLConnection::getOutputStream();

 

My question: (finally) - I look at /var/log/syslog expecting to see some
report of blocked traffic and I see - nothing. No information about
packets being stopped. This tells me that the firewall didn''t get
involved. Are there any cases where the firewall would have blocked
traffic and *not* reported it? Have I failed to forward some crucial
piece of information / socket traffic over the DMZ barrier? I was hoping
to see a REJECT in the log telling me what port was blocked so I could
open it.

I would try to run without the firewall but it is the only thing
connecting my DMZ machine to the free world.

</shields>

 

PS let me help the process along:

"NOT ALL CONNECTION PROBLEMS ARE SHOREWALL PROBLEMS!!"

Yes. I agree. Im sure its something Im missing I just can''t tell what.
The only difference I can see between the "working" and
"blocked"
machines is that one is in the DMZ.

On Thu, 2003-10-09 at 11:40, jon yeargers wrote:
> (This is probably going to get me flamed but .. so be it..)
>  
> <shields>
:-)
>  
> Im running Shorewall with a DMZ. In the DMZ I have a tomcat server. I
> have the following rules set up to allow traffic to / from the DMZ:
>  
> (rules)
> # rules (including entry in ''nat'') for making DMZ server
accessible
> ACCEPT          net     dmz:192.168.100.10      tcp 80,443,8080
> DNAT            loc     dmz:192.168.100.10      tcp 80,443,8080 -
> 155.229.27.54
>  
> 
> (nat)
> #EXTERNAL       INTERFACE       INTERNAL        ALL INTERFACES
> LOCAL
> 155.229.27.54   eth0:0          192.168.100.10  no
> no
Looks fine.
> 
> So far so good. Works fine for serving pages. I have an applet that I
> would like to have correspond with my tomcat process. When this applet
> is run against an identical tomcat server running inside the "local
> zone" (IE doesn''t interact with the firewall) it works ok.
When this
> applet is directed at the tomcat server in the DMZ I get 
> 
> java.net.ConnectException: Connection refused:
> 
> The stack trace shows that the offending line is a call to
> URLConnection::getOutputStream(); 
> 
> My question: (finally) - I look at /var/log/syslog expecting to see some
> report of blocked traffic and I see - nothing. No information about
> packets being stopped. This tells me that the firewall didn''t get
> involved. Are there any cases where the firewall would have blocked
> traffic and *not* reported it? Have I failed to forward some crucial
> piece of information / socket traffic over the DMZ barrier? I was hoping
> to see a REJECT in the log telling me what port was blocked so I could
> open it.
What does your /etc/shorewall/policy file look like?
> 
> I would try to run without the firewall but it is the only thing
> connecting my DMZ machine to the free world.
> 
> </shields>
> 
>  
> 
> PS let me help the process along:
> 
> "NOT ALL CONNECTION PROBLEMS ARE SHOREWALL PROBLEMS!!"
> 
> Yes. I agree. Im sure its something Im missing I just can''t tell
what.
> The only difference I can see between the "working" and
"blocked"
> machines is that one is in the DMZ.
Assuming that the Java client is connecting to 155.229.27.54 on port
80,443 or 8080 there shouldn''t be any way for Shorewall to silently
reject the connection. That of course assumes that:

a) Your effective loc->dmz policy has a log level associated with it.
b) You aren''t rate limiting logging with entries in
/etc/shorewall/shorewall.conf.
c) Your logging actually works.

Assuming all of the above, the ways that traffic might still be silently
dropped or rejected are:

1. A rule in /etc/shorewall/common (if you have that file) or in 
   /etc/shorewall/common.def.

2. A silent DROP in /etc/shorewall/rfc1918.

3. The source IP is blacklisted silently.

tcpdump or ethereal might help here...

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net

On Thu, 2003-10-09 at 12:48, Tom Eastep wrote:
> 
> tcpdump or ethereal might help here...
Also, do a "shorewall reset" then try your Java applet. Then look at
the
output of "shorewall status" and try to determine what path the SYN
packet took.

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net