On 05/31/2011 02:38 AM, Farkas Levente wrote: > On 05/30/2011 04:56 PM, Tom Eastep wrote: >> On 05/30/2011 12:05 AM, Farkas Levente wrote: >> >>> before this setup i've this in the rules: >>> SSH(ACCEPT) net:$ADMIN_NET fw >>> which was working, but after that i'm no longer able to access to the >>> host:-( >>> so in this case what is the right rule? net should have to be world or? >> >> '...no longer able to access..' isn't enough to go on. I would at least > > this means i got "Connection refused" when i try to ssh. > but if i replace: > SSH(ACCEPT) net:$ADMIN_NET fw > with > SSH(ACCEPT) world:$ADMIN_NET fw > than i can connect, but in this case i can connect from everywhere not > just from $ADMIN_NET. > so what does the net and world means in this case? of course $ADMIN_NET > is the public ip's of the host from the net where i'd like to access ssh. > >> need to see what log message is generated when you try to access (the >> output of 'shorewall dump' collected right after you tried to access >> would be better) in order to tell you what's wrong. > > attached.
What does 'cat /proc/sys/net/bridge/bridge-nf-call-iptables' show? If it
shows '0', then you need to change your /etc/sysctl.conf to set it to 1.
If it shows '1', then there is something wrong with physdev match on
your system because the following rules don't seem to be matched:
0 0 net2fw all -- br0 * 0.0.0.0/0
0.0.0.0/0 PHYSDEV match --physdev-in eth0
0 0 hird2fw all -- br0 * 0.0.0.0/0
0.0.0.0/0 PHYSDEV match --physdev-in vnet3
0 0 dmz2fw all -- br0 * 0.0.0.0/0
0.0.0.0/0 PHYSDEV match --physdev-in vnet+
Any incoming traffic should match one of those three rules, yet it is
falling through to this rule.
787 96669 world2fw all -- br0 * 0.0.0.0/0
0.0.0.0/0
Contrast that behavior with bridge rules on my own firewall:
60274 3869K lan-fw all -- * * 0.0.0.0/0
0.0.0.0/0 PHYSDEV match --physdev-in eth1 policy match dir in
pol none
7175 596K wlan-fw all -- * * 0.0.0.0/0
0.0.0.0/0 PHYSDEV match --physdev-in eth2 policy match dir in
pol none
0 0 loc-fw all -- * * 0.0.0.0/0
0.0.0.0/0 policy match dir in pol none
Here, 'lan' and 'wlan' are zones associated with br1 ports eth1 and eth2
respectively. Both 'lan' and 'wlan' are sub-zones of 'loc', but no
packets are falling through to the 'loc_fw' chain.
>
>>> and what's the reason of the:
>>> net all DROP info
>>> in the middle of the policy file when there is a reject at the end?
>>
>> So the box and it's VMs are stealth from the net.
>
> all other guest has it's own shorewall and win guest has rules on the
> host. so why is it needed? and anyway there is a
> all all REJECT
> at the end of policy file
>
Fine -- if you want the net->fw policy to be REJECT rather than DROP
then remove the net->all policy. I'm not going to argue with you about
it; it's your configuration, not mine. But under DOS conditions, I
prefer to simply drop incoming packets rather than generate a second
storm of outgoing reply packets in response.
-Tom
--
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
