See below,
----- Original Message -----
From: "Jerry Vonau" <jvonau@shaw.ca>
To: "Mailing List for Shorewall Users"
<shorewall-users@lists.shorewall.net>
Sent: Thursday, June 23, 2005 11:46 PM
Subject: Re: [Shorewall-users] DNS issues - FC4 - Shorewall - Bridge
>
>
> Hey folks;
>
> I have been happily using shorewall for quite some time so this problem
> _may_ not be easy to resolve but I am interested in any information
> regarding your experience with the same setup.
>
> I was using FC3 with shorewall 2.2.3 and two NICs setup as a bridge
without> any issue until I upgraded to FC4. My production system would pass traffic
> through the bridge but local usage would not work (i.e. dns lookups). I
> couldn''t even connect using ssh? I rebuilt the firewall using the
same
> kickstart script and was able to connect with ssh but I now notice that
DNS> doesn''t work. Has anyone encountered this issue with FC4 yet and
if so is
> it
> resolved? I have tried some additional options but none of them seem to
> resolve the issue.
>
> After issuing a ''shorewall stop'' local dns lookups work
fine. Since so
many> commands require dns lookups this gives the appearance that the system is
> very slow. My aim is to resolve this issue without reverting back to FC3.
> Let me know if I missed any info...
>
> I have attached some of my setup for anyone to help troubleshoot (if
> interested).
> I will continue to attempt to find the specific issue with this setup but
I> would appreciate any help you could share.
>
> TIA
>
> Jeff
>
> This is strange, shorewall doesn''t block lo:
> Jun 23 05:45:29 all2all:REJECT:IN= OUT=lo SRC=127.0.0.1 DST=127.0.0.1
> LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=46143 DF PROTO=TCP SPT=50126 DPT=25
> WINDOW=32767 RES=0x00 SYN URGP=0
>
> What is $INT_OPTIONS in interfaces
> What is with the tun device?
>
> #ZONE HOST(S) OPTIONS
> net br0:eth0 routeback
> loc br0:eth1
> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
>
> What is the reasoning on using routeback on net in the hosts file?
>
> Jun 19 15:44:23 net2all:DROP:IN=br0 OUT= PHYSIN=eth0 SRC=192.168.1.5
> DST=192.168.1.127 LEN=76 TOS=0x00 PREC=0x00 TTL=128 ID=25194 PROTO=UDP
> SPT=123 DPT=123 LEN=56
>
> Well, if eth1 is the loc interface, and the traffic is comming in on eth0,
> are these reversed maybe?
>
> Jerry
<snip>
Thanks for the reply Jerry - looks like you are on a fast track to replace
Tom ;-)
In order to resolve this issue I had to turn on the ''info''
line in the
policy file to see all the accept log entries. This helped me track down the
issue but first, to answer some of your questions Jerry...
$INT_OPTIONS was simply ''tcpflags,routefilter,dhcp'' - I use
it from the
params file.
tun device is an encrypted tunnel for syslog so I can monitor all the
systems that I put out there (the Internet) as part of my services. It was
inactive in my setup but I neglected to remove it from the rules and tunnel
files. Sorry for the confusion.
I decided to try anything (but the obvious) so ''routeback'' was
used on the
net device since I wasn''t actually using the loc device yet.
I am sure that I wasn''t using the wrong etherent port but thanks for
the
heads up Jerry.
Now to explain my solution:
It appears that something has changed in this new version of Fedora that
required the addition of a ''two way policy'' using the same
bridge setup as
FC3 and only seems to affect the bridge. For instance I also noticed that I
couldn''t ping my own bridge interface unless I added a rule allowing it
both
ways (ACCEPT fw fw icmp and not just ACCEPT all all icmp) In FC3 I had used
a ''fw net ACCEPT'' policy setup and it worked fine (and did in
every previous
version using both Fedora and shorewall) but after the update to FC4 I began
to see the request and reply packets generated from the bridge to my dns
server on another box using tcpdump I wondered why;
a. I wasn''t seeing any mention of these (dropped OR rejected dns reply)
packets being logged by shorewall?
b. Why the dns reply packets were not being accepted by shorewall and logged
As I stated in my earlier post (incorrectly I might add) these replies did
indeed work after I issued a ''shorewall clear'' (and not a
shorewall stop as
I mentioned earlier) and NOT when shorewall was running using
''shorewall
start''. My solution was to add an implicit policy allowing the
returning
''net fw ACCEPT'' policy which allowed the dns traffic back in
and it then
worked.
It was interesting to note that by substituting the policy for a similar dns
specific rule rather than the policy, that dns still did NOT work but since
all of the communication necessary for my production bridge will be from the
trusted (INSIDE the firewall) interface, I don''t see this as a
show-stopper.
Yum updates come from a repository inside my networks and dns queries are
answered by a dns server inside as well so there is no need to create a
net> fw policy although this would not be wise for anyone as it would allow any
traffic to the bridge.
It maybe a setup error OR it may be a change in the way iptables conntrack
works OR more likely a change in the Fedora networking (although it works as
expected when shorewall clear is issued.
So for now, it appears I have resolved this problem by using an open policy
of ''loc fw ACCEPT'' as well as ''fw loc
ACCEPT'' but I still consider this a
fix rather than a solution. Two questions that come to mind is;
1. Why doesn''t the related,established rule allow the inbound request
from
the dns query?
2. Why doesn''t the local bridge traffic get logged?
I would welcome any requests for additional info, files, etc. by anyone
interested in helping to trace the problem but for now I don''t consider
this
a problem that requires any help from the list as I have a temp fix in
place.
Thanks again for the help.
Jeff
DISCLAIMER:
This message was sent from The-Techy.com.