I have a gateway computer running shorewall and an application-specific name server. Client programs on other computers are successfully querying the nameserver using a simple UDP protocol. But I can''t run those same client programs on the gateway computer. The log (dmesg) shows nothing but if I stop and clear shorewall the client program runs just fine. So I thought I must need some rules for the gateway (fw) computer itself. I tried these: ACCEPT fw fw udp 9091 ACCEPT fw fw udp - 9091 But when I restart shorewall, I get this message: fw -> fw rules are not supported; etc I''m running shorewall 1.4.1a with the default policy file and a very simple rules file. I''ve tried fiddling with the ''LOG LEVEL'' in the policy file, should I put a fw2fw entry in the policy file with a LOG LEVEL? Thanks, Bill -- Using M2, Opera''s revolutionary e-mail client: http://www.opera.com/m2/
On Tue, 29 Apr 2003, William Trenker wrote:> I''m running shorewall 1.4.1a with the default policy file and a very simple > rules file. I''ve tried fiddling with the ''LOG LEVEL'' in the policy file, > should I put a fw2fw entry in the policy file with a LOG LEVEL?Shorewall doesn''t restrict fw->fw traffic other than dropping state=invalid non-icmp packets. If you look at the INPUT or OUTPUT chain, does the first rule in either chain show matching packets? -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ teastep@shorewall.net
On Tue, 29 Apr 2003 16:58:27 -0700 (PDT), Tom Eastep <teastep@shorewall.net> wrote:> On Tue, 29 Apr 2003, William Trenker wrote: > >> I''m running shorewall 1.4.1a with the default policy file and a very >> simple rules file. I''ve tried fiddling with the ''LOG LEVEL'' in the >> policy file, should I put a fw2fw entry in the policy file with a LOG >> LEVEL? > > Shorewall doesn''t restrict fw->fw traffic other than dropping > state=invalid non-icmp packets. > > If you look at the INPUT or OUTPUT chain, does the first rule in either > chain show matching packets? >Tom, I must admit I''m not sure what you mean by "matching packets", but that is my ignorance. The first entry I see for OUTPUT is for target DROP and it shows 168 packets. But I expect you mean something else. I''ve been reading through the docs trying to educate myself, especially about how to best use the logs and interpret the log entries. For example, how do I log packets going from fw to fw? Thanks for helping, Bill -- Using M2, Opera''s revolutionary e-mail client: http://www.opera.com/m2/
yOn Tue, 29 Apr 2003, William Trenker wrote:> On Tue, 29 Apr 2003 16:58:27 -0700 (PDT), Tom Eastep > <teastep@shorewall.net> wrote: > > > On Tue, 29 Apr 2003, William Trenker wrote: > > > >> I''m running shorewall 1.4.1a with the default policy file and a very > >> simple rules file. I''ve tried fiddling with the ''LOG LEVEL'' in the > >> policy file, should I put a fw2fw entry in the policy file with a LOG > >> LEVEL? > > > > Shorewall doesn''t restrict fw->fw traffic other than dropping > > state=invalid non-icmp packets. > > > > If you look at the INPUT or OUTPUT chain, does the first rule in either > > chain show matching packets? > > > > Tom, I must admit I''m not sure what you mean by "matching packets", but > that is my ignorance. The first entry I see for OUTPUT is for target DROP > and it shows 168 packets. But I expect you mean something else. >No -- that''s exactly what I mean. For some reason, the application you are using is doing something that is confusing Netfilter connection tracking. For the time being, add the following to /etc/shorewall/start: run_iptables -D INPUT 1 run_iptables -D OUTPUT 1 Let me know if that fixes the problem. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ teastep@shorewall.net
On Tue, 29 Apr 2003 20:13:19 -0700 (Pacific Daylight Time), Tom Eastep <teastep@shorewall.net> wrote:> yOn Tue, 29 Apr 2003, William Trenker wrote: > >> >> Tom, I must admit I''m not sure what you mean by "matching packets", but >> that is my ignorance. The first entry I see for OUTPUT is for target >> DROP >> and it shows 168 packets. But I expect you mean something else. >> > > > No -- that''s exactly what I mean. > > For some reason, the application you are using is doing something that is > confusing Netfilter connection tracking. > > For the time being, add the following to /etc/shorewall/start: > > run_iptables -D INPUT 1 > run_iptables -D OUTPUT 1 > > Let me know if that fixes the problem. >Unfortunately that didn''t help. The funny thing is that everything works great when the application is running on a separate computer from shorewall. Here is the log for a typical session when the application runs on a separate computer and the name server is running on the same computer as shorewall: First, the application running on loc initiates a name server discovery broadcast on UDP port 9091: Shorewall:loc2fw:ACCEPT:IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:60:67:3a:4e:23:08:00 SRC=192.168.0.100 DST=255.255.255.255 LEN=36 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=1360 DPT=9091 LEN=16 Second, the name server, running on fw, sees the broadcast and returns its address info from UDP 9091: Shorewall:fw2loc:ACCEPT:IN= OUT=eth0 SRC=192.168.0.1 DST=192.168.0.100 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=9091 DPT=1360 LEN=64 Third, the application on loc, having received the address info from the name server, initiates a TCP handshake with the nameserver using the ip address and port (in this case 192.168.0.1:9090) that the name server gave it to use: Shorewall:loc2fw:ACCEPT:IN=eth0 OUT= MAC=00:01:02:72:dc:25:00:60:67:3a:4e:23:08:00 SRC=192.168.0.100 DST=192.168.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=54333 DF PROTO=TCP SPT=2542 DPT=9090 WINDOW=5840 RES=0x00 SYN URGP=0 But when I try to run application on the fw machine the application aborts indicating that the nameserver is not responding. At first I thought it might have something to do with a broadcast source and destination being on the same machine. But when I stop and clear shorewall everything works fine. One extra challenge is that I haven''t figured out how to get log info from shorewall in the fw->fw scenario. Can you help me get this log business straight? Thanks again, Bill -- Using M2, Opera''s revolutionary e-mail client: http://www.opera.com/m2/
On Tue, 29 Apr 2003 21:53:35 -0000, William Trenker <wdtrenker@yahoo.ca> wrote:>> > > Unfortunately that didn''t help. The funny thing is that everything works > great when the application is running on a separate computer from > shorewall. Here is the log for a typical session when the application > runs on a separate computer and the name server is running on the same > computer as shorewall:That doesn''t mean that the problem is with fw->fw. Please follow the instructions at http://www.shorewall.net/support.htm for capturing "shorewall status" (be sure that you "shorewall reset" first and that you include the status output as an attachment.> One extra challenge is that I haven''t figured out how to get log info > from shorewall in the fw->fw scenario. Can you help me get this log > business straight?Bill -- There is no builtin way to log fw->fw traffic since that traffic is all accepted (as I''ve already mentioned). If you want to log fw->fw traffic, point tcpdump at your ''lo'' interface. I suspect that the client needs access to other services besides the server and those services are being denied from the firewall whereas they aren''t being denied from a local host; just a guess.... -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ teastep@shorewall.net