thr3ads.net - Shorewall users - maclist problem on a firewall/bridge/router system with masquerading [Sep 2005]

If this information is useful, please help other people find it:
Share via:

Paulo Cunha

2005-Sep-29 08:31 UTC

maclist problem on a firewall/bridge/router system with masquerading

Hy,


sorry for my poor english

i think i''m having a very unusual problem and very dificult to track, 
but i''ll try to explain it as best as i can.

here is my scenario:

a firewall/bridge composed of 3 ethernet devices and 1 virtual one.

my bridge (br0 ) is composed of eth0, eth1 and tap0

br0:eth0 is my connection to my router (200.244.92.1)
br0:eth1 is my connection to my local network and my dmz servers ( 
200.244.92.0/25)
br0:tap0 is the bridged connection of my home via openvpn, so i can 
participate of my work network from home.

until here it''s all ok and working , the bridge, the firewall , 
everything fine.

so yesterday i just activated eth2 and migrated my access clients to 
this firewall and here the hystory begins.

eth2 is connected to many cient''s networks ex: 10.10.1.0/24
10.10.2.0/24
... and every client network can connect to internet via the firewall.

a client from the network 10.10.1.0/24 user the ip 200.244.92.66 as the 
outgoing ip ( masq rule ), a client from 10.10.2.0/24 user ip 
200.244.92.69, and so on ...


until here it''s ok, so i had to activate the mac filter. and bum .. it 
stoped working.

i added all my client mac addresses on the mac file like

eth2   mac:delimited:address   10.10.1.2

and all packages just get rejected by the eth2_mac chain

i tryed addind just the mac address without the ip and not worked too ...

then in the meantime, i recompiled the kernel, checked everything and 
just realized it''s one of two, a shorewall problem or my configuration 
of shorewall :)

i added the mac addresses of the bridge''s eth0 and eth1 to the eth2 
maclist and it works ! weird it works, but everybody can access the 
internet, including clients that dont have macs listed ...

here is what i think:

1 the package comes throuth eth2  going to eth0.
2 the firewall sees it is going to internet and do an snat on lt to 
mascarade my internal net and changes its source address and 
consequently its mac.
3 the package passes throuth the forward chain that checks its mac 
address to see if it comes from a valid mac from eth2 and bang ! the mac 
is not the original mac anymore, it''s now my local mac.


i think it is what is happening.


what can i do now ?

it is too late here, a''m so tired and starting to type so bad in
english
that i can''t post my config today. by the mourning i ll send my entire 
configuration to see if anyone can help-me.

ps i''m just saw now that my shorewall version is 2.4.1 , hummm strange,
i''ve just emerged-it ..forget ...


thanks ,

Paulo Cunha

Interlize Internet
pcunha@interlize.com.br









-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

Tom Eastep

2005-Sep-29 14:05 UTC

head link

Re: maclist problem on a firewall/bridge/router system with masquerading

Paulo Cunha wrote:
> 
> and all packages just get rejected by the eth2_mac chain
Ok -- Look at one of these messages; what MAC address is reported in the
message?

> i added the mac addresses of the bridge''s eth0 and eth1 to the
eth2
> maclist and it works ! weird it works, but everybody can access the
> internet, including clients that dont have macs listed ...
Something isn''t adding up here.
> 
> here is what i think:
> 
> 1 the package comes throuth eth2  going to eth0.
> 2 the firewall sees it is going to internet and do an snat on lt to
> mascarade my internal net and changes its source address and
> consequently its mac.
> 3 the package passes throuth the forward chain that checks its mac
> address to see if it comes from a valid mac from eth2 and bang ! the mac
> is not the original mac anymore, it''s now my local mac.
> 
That analysis is wrong -- SNAT occurs in the POSTROUTING chain which is
traversed AFTER the FORWARD chain. Please submit a real problem report
as described at http://www.shorewall.net/support.htm.

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

Paulo Cunha

2005-Oct-05 21:00 UTC

head link

Re: maclist problem on a firewall/bridge/router system with masquerading

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear tom,

Thanks for your reply, and for all your efforts on shorewall.

i''ve ran some tests today and i''ll try to explain the problem
in
another form. this time a real problem report as beast as i can.

as you asked i''m anexing the status.txt.

i''ve changed my setup a bit so i can ran more tests without disturbing
my clients:


eth0 (connected to my router)            \
eth1 (connected to my lan)                   |  >> br0
tap0 (connected to my lan at home)   /

eth2 is connected with my clients networks.
eth3 is connected to my notebook for testing this problem only, and is
configured equal to eth2 with a different net.
ppp devices are connected by eth2 to my clents who connects by pptd

~                                              Tap0 - Bridge to my home
~                                                  |
~         Clients network - eth2 -- | --  eth3 - Test network
~                                                  |

|---------------------------------------------|
(internet) eth-0 -| SHOREWALL FIRREWALL | - eth1 - Local Network
~                            |____________________________|
~                                                 |
~                                               ppp+ - clients over
pptp connection


i only use maclist on eth2(and 3 for testing).

shorewall starts and stops without any error.

my local network talks to everyone with no problems. as the openvpnand
the pptp.


now the problem is that i''m trying to make connections from any
network in my interface eth2 to the internet or the dmz(allowed in the
hosts) using maclists. The problem only exists with maclist. if i
remove the maclist everything works fine.

when i try a ping for example the log error shows me this line:

Sep 29 15:03:14 [kernel] Shorewall:eth3_mac:REJECT:IN=eth3 OUT=br0
PHYSOUT=eth1 SRC=10.50.0.2 DST=200.244.92.8 LEN=84 TOS=0x00 PREC=0x00
TTL=63 ID=3989 DF PROTO=ICMP TYPE=8 CODE=0 ID=7955 SEQ=3990

how can you see unfortunetly there is no mac on the log :(

i ran a tcpdump to see if the mac arrives ok on the machine and its
all ok.

now the curious

if i add the mac of my bridge interface''s port1(eth1) to the maclist
on eth3 ( or 2 ) the package passes suceffuly and when i see on the
iptables -L eth3_mac -v -n i see that all the traffic on tha chain
exits by the wrong mac, the mac of eth1 not  by the mac of the machine
connected to eth3 how it is supposed to be.

i dont know where but i think the mac changes on the middle of the way
before checking...

the maclist works for connections going to the firewall itself but
rejects all traffic that shoud be passing trhouth it.

i could not send the attachments on the same last mail because of the
size of the attachments, so this time i ll host them in my server.

http://w3.interlize.com.br/downloads/status.txt.bz2
http://w3.interlize.com.br/downloads/shorewall.tar.bz2

some information you may consider useful:

sol / # shorewall version
2.4.4

sol / # ip addr show
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
~    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
~    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
2: eth0: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc htb qlen 1000
~    link/ether 00:e0:7d:77:00:e3 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc htb qlen 1000
~    link/ether 00:08:54:25:62:67 brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
~    link/ether 00:08:54:25:62:71 brd ff:ff:ff:ff:ff:ff
~    inet 10.10.2.1/24 brd 10.10.2.255 scope global eth2
~    inet 10.10.3.1/24 brd 10.10.3.255 scope global eth2
~    inet 10.10.4.1/24 brd 10.10.4.255 scope global eth2
~    inet 10.10.5.1/24 brd 10.10.5.255 scope global eth2
~    inet 10.10.6.1/24 brd 10.10.6.255 scope global eth2
~    inet 10.10.7.1/24 brd 10.10.7.255 scope global eth2
~    inet 10.10.8.1/24 brd 10.10.8.255 scope global eth2
~    inet 10.10.20.1/24 brd 10.10.20.255 scope global eth2
~    inet 10.10.22.1/24 brd 10.10.22.255 scope global eth2
~    inet 10.11.0.1/26 brd 10.11.0.63 scope global eth2
~    inet 10.12.1.1/24 brd 10.12.1.255 scope global eth2
~    inet 10.12.2.1/24 brd 10.12.2.255 scope global eth2
~    inet 10.12.3.1/24 brd 10.12.3.255 scope global eth2
~    inet 10.12.4.1/24 brd 10.12.4.255 scope global eth2
~    inet 10.14.0.1/30 brd 10.14.0.3 scope global eth2
~    inet 10.14.0.5/30 brd 10.14.0.7 scope global eth2
~    inet 10.14.0.9/30 brd 10.14.0.11 scope global eth2
~    inet 10.14.0.13/30 brd 10.14.0.15 scope global eth2
~    inet 10.14.0.17/30 brd 10.14.0.19 scope global eth2
~    inet 10.14.1.1/30 brd 10.14.1.3 scope global eth2
~    inet 10.14.1.5/30 brd 10.14.1.7 scope global eth2
~    inet 10.14.1.9/30 brd 10.14.1.11 scope global eth2
~    inet 10.14.1.13/30 brd 10.14.1.15 scope global eth2
5: eth3: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
~    link/ether 00:c0:df:09:72:c8 brd ff:ff:ff:ff:ff:ff
~    inet 10.50.0.1/24 brd 10.255.255.255 scope global eth3
6: tap0: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc noqueue qlen 100
~    link/ether 00:ff:13:41:e1:7e brd ff:ff:ff:ff:ff:ff
10: br0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
~    link/ether 00:08:54:25:62:67 brd ff:ff:ff:ff:ff:ff
~    inet 200.244.92.6/25 brd 200.244.92.127 scope global br0
~    inet 200.244.92.66/25 brd 200.244.92.127 scope global secondary br0
~    inet 200.244.92.67/25 brd 200.244.92.127 scope global secondary br0
~    inet 200.244.92.68/25 brd 200.244.92.127 scope global secondary br0
~    inet 200.244.92.69/25 brd 200.244.92.127 scope global secondary br0
~    inet 200.244.92.70/25 brd 200.244.92.127 scope global secondary br0
~    inet 200.244.92.71/25 brd 200.244.92.127 scope global secondary br0
~    inet 200.244.92.72/25 brd 200.244.92.127 scope global secondary br0
~    inet 200.244.92.73/25 brd 200.244.92.127 scope global secondary br0
~    inet 200.244.92.74/25 brd 200.244.92.127 scope global secondary br0
~    inet 200.244.92.75/25 brd 200.244.92.127 scope global secondary br0
~    inet 200.244.92.76/25 brd 200.244.92.127 scope global secondary br0
~    inet 200.244.92.77/25 brd 200.244.92.127 scope global secondary br0
~    inet 200.244.92.78/25 brd 200.244.92.127 scope global secondary br0
~    inet 200.244.92.79/25 brd 200.244.92.127 scope global secondary br0
~    inet 200.244.92.80/25 brd 200.244.92.127 scope global secondary br0
~    inet 200.244.92.81/25 brd 200.244.92.127 scope global secondary br0
~    inet 200.244.92.82/25 brd 200.244.92.127 scope global secondary br0
~    inet 200.244.92.83/25 brd 200.244.92.127 scope global secondary br0
~    inet 200.244.92.84/25 brd 200.244.92.127 scope global secondary br0
~    inet 200.244.92.85/25 brd 200.244.92.127 scope global secondary br0
11: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1400 qdisc pfifo_fast
qlen 3
~    link/ppp
~    inet 10.16.0.1 peer 10.18.0.5/32 scope global ppp0


sol / # ip route show
10.18.0.5 dev ppp0  proto kernel  scope link  src 10.16.0.1
10.14.0.16/30 dev eth2  proto kernel  scope link  src 10.14.0.17
10.14.1.0/30 dev eth2  proto kernel  scope link  src 10.14.1.1
10.14.0.8/30 dev eth2  proto kernel  scope link  src 10.14.0.9
10.14.1.4/30 dev eth2  proto kernel  scope link  src 10.14.1.5
10.14.0.12/30 dev eth2  proto kernel  scope link  src 10.14.0.13
10.14.1.8/30 dev eth2  proto kernel  scope link  src 10.14.1.9
10.14.0.0/30 dev eth2  proto kernel  scope link  src 10.14.0.1
10.14.1.12/30 dev eth2  proto kernel  scope link  src 10.14.1.13
10.14.0.4/30 dev eth2  proto kernel  scope link  src 10.14.0.5
10.11.0.0/26 dev eth2  proto kernel  scope link  src 10.11.0.1
200.244.92.0/25 dev br0  proto kernel  scope link  src 200.244.92.6
10.10.22.0/24 dev eth2  proto kernel  scope link  src 10.10.22.1
10.10.6.0/24 dev eth2  proto kernel  scope link  src 10.10.6.1
10.10.7.0/24 dev eth2  proto kernel  scope link  src 10.10.7.1
10.10.20.0/24 dev eth2  proto kernel  scope link  src 10.10.20.1
10.10.4.0/24 dev eth2  proto kernel  scope link  src 10.10.4.1
10.12.4.0/24 dev eth2  proto kernel  scope link  src 10.12.4.1
10.10.5.0/24 dev eth2  proto kernel  scope link  src 10.10.5.1
10.12.3.0/24 dev eth2  proto kernel  scope link  src 10.12.3.1
10.10.2.0/24 dev eth2  proto kernel  scope link  src 10.10.2.1
10.12.2.0/24 dev eth2  proto kernel  scope link  src 10.12.2.1
10.10.3.0/24 dev eth2  proto kernel  scope link  src 10.10.3.1
10.12.1.0/24 dev eth2  proto kernel  scope link  src 10.12.1.1
10.50.0.0/24 dev eth3  proto kernel  scope link  src 10.50.0.1
10.10.8.0/24 dev eth2  proto kernel  scope link  src 10.10.8.1
127.0.0.0/8 dev lo  scope link
default via 200.244.92.1 dev br0

sol ~ # uname -a
Linux sol 2.6.10-gentoo-r4 #3 Thu Sep 29 20:11:34 BRT 2005 i586
AMD-K6(tm) 3D processor AuthenticAMD GNU/Linux

the kernel has layer 7 support.

i hope you can help-me, and sorry aboult my last mail.

best brazillian regards,

Paulo Cunha
Interlize Internet
pcunha@interlize.com.br




Tom Eastep wrote:

| Paulo Cunha wrote:
|
|
|
|> and all packages just get rejected by the eth2_mac chain
|>
|>
|
| Ok -- Look at one of these messages; what MAC address is reported
| in the message?
|
|
|
|
|> i added the mac addresses of the bridge''s eth0 and eth1 to the
|> eth2 maclist and it works ! weird it works, but everybody can
|> access the internet, including clients that dont have macs listed
|> ...
|>
|>
|
| Something isn''t adding up here.
|
|
|
|> here is what i think:
|>
|> 1 the package comes throuth eth2  going to eth0. 2 the firewall
|> sees it is going to internet and do an snat on lt to mascarade my
|> internal net and changes its source address and consequently its
|> mac. 3 the package passes throuth the forward chain that checks
|> its mac address to see if it comes from a valid mac from eth2 and
|> bang ! the mac is not the original mac anymore, it''s now my local
|> mac.
|>
|>
|>
|
| That analysis is wrong -- SNAT occurs in the POSTROUTING chain
| which is traversed AFTER the FORWARD chain. Please submit a real
| problem report as described at
| http://www.shorewall.net/support.htm.
|
| -Tom
|
|

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDRD70gwLgjZASvYURAmQSAJ47xMG6MfuMG3nIoFK6lvrDt9DyXACgz5LQ
Pa+fCJNPGiaVzLJ8KQjY6lU=j+23
-----END PGP SIGNATURE-----




-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

Tom Eastep

2005-Oct-05 22:26 UTC

head link

Re: maclist problem on a firewall/bridge/router system with masquerading

Paulo Cunha wrote:
> 
> as you asked i''m anexing the status.txt.
I downloaded it from the URL later in your post.
> 
> i''ve changed my setup a bit so i can ran more tests without
disturbing
> my clients:
> 
> 
> eth0 (connected to my router)            \
> eth1 (connected to my lan)                   |  >> br0
> tap0 (connected to my lan at home)   /
> 
> eth2 is connected with my clients networks.
> eth3 is connected to my notebook for testing this problem only, and is
> configured equal to eth2 with a different net.
> ppp devices are connected by eth2 to my clents who connects by pptd
> 
...Folded (and hence useless) ASCII Art deleted...
> 
> i only use maclist on eth2(and 3 for testing).
> 
> shorewall starts and stops without any error.
> 
> my local network talks to everyone with no problems. as the openvpnand
> the pptp.
> 
> 
> now the problem is that i''m trying to make connections from any
> network in my interface eth2 to the internet or the dmz(allowed in the
> hosts) using maclists. The problem only exists with maclist. if i
> remove the maclist everything works fine.
> 
> when i try a ping for example the log error shows me this line:
> 
> Sep 29 15:03:14 [kernel] Shorewall:eth3_mac:REJECT:IN=eth3 OUT=br0
> PHYSOUT=eth1 SRC=10.50.0.2 DST=200.244.92.8 LEN=84 TOS=0x00 PREC=0x00
> TTL=63 ID=3989 DF PROTO=ICMP TYPE=8 CODE=0 ID=7955 SEQ=3990
> 
> how can you see unfortunetly there is no mac on the log :(
Two things:

a) From the "shorewall status", you have configured no maclist entries
for eth3!
b) You cannot use "shorewall show log" to look at MAC addresses in the
log; "shorewall show log" removes some information from log messages
(including the MAC) to reduce them to 128 characters or less in length
(which is as wide a window as is supported by some terminal emulators).
Also, I don''t know if ULOG supports logging of the MAC address.
> 
> i ran a tcpdump to see if the mac arrives ok on the machine and its
> all ok.
> 
> now the curious
> 
> if i add the mac of my bridge interface''s port1(eth1) to the
maclist
> on eth3 ( or 2 ) the package passes suceffuly and when i see on the
> iptables -L eth3_mac -v -n i see that all the traffic on tha chain
> exits by the wrong mac, the mac of eth1 not  by the mac of the machine
> connected to eth3 how it is supposed to be.
> 
> i dont know where but i think the mac changes on the middle of the way
> before checking...
If so, it''s not a Shorewall problem -- Shorewall can''t change
the
incoming MAC if it wanted to (for that, you need ebtables which
Shorewall doesn''t support).
> 
> the maclist works for connections going to the firewall itself but
> rejects all traffic that shoud be passing trhouth it.
> 
If that''s true then it must be a yet one more Netfilter/Bridge bug.
Since I have nothing but your garbled second-hand report however,
there''s not much I can do about it.

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

Paulo Cunha

2005-Oct-06 04:35 UTC

head link

Re: maclist problem on a firewall/bridge/router system with masquerading

-----Original Message-----
From: Tom Eastep <teastep@shorewall.net>
To: shorewall-users@lists.sourceforge.net
Date: Wed, 05 Oct 2005 15:26:55 -0700
Subject: Re: [Shorewall-users] maclist problem on a firewall/bridge/router
system with masquerading
> Paulo Cunha wrote:
> 
> > 
> > as you asked i''m anexing the status.txt.
> 
> I downloaded it from the URL later in your post.
> 
> > 
> > i''ve changed my setup a bit so i can ran more tests without
> disturbing
> > my clients:
> > 
> > 
> > eth0 (connected to my router)            \
> > eth1 (connected to my lan)                   |  >> br0
> > tap0 (connected to my lan at home)   /
> > 
> > eth2 is connected with my clients networks.
> > eth3 is connected to my notebook for testing this problem only, and
> is
> > configured equal to eth2 with a different net.
> > ppp devices are connected by eth2 to my clents who connects by pptd
> > 
> 
> ...Folded (and hence useless) ASCII Art deleted...
just trying to help
> 
> > 
> > i only use maclist on eth2(and 3 for testing).
> > 
> > shorewall starts and stops without any error.
> > 
> > my local network talks to everyone with no problems. as the
> openvpnand
> > the pptp.
> > 
> > 
> > now the problem is that i''m trying to make connections from
any
> > network in my interface eth2 to the internet or the dmz(allowed in
> the
> > hosts) using maclists. The problem only exists with maclist. if i
> > remove the maclist everything works fine.
> > 
> > when i try a ping for example the log error shows me this line:
> > 
> > Sep 29 15:03:14 [kernel] Shorewall:eth3_mac:REJECT:IN=eth3 OUT=br0
> > PHYSOUT=eth1 SRC=10.50.0.2 DST=200.244.92.8 LEN=84 TOS=0x00 PREC=0x00
> > TTL=63 ID=3989 DF PROTO=ICMP TYPE=8 CODE=0 ID=7955 SEQ=3990
> > 
> > how can you see unfortunetly there is no mac on the log :(
> 
> Two things:
> 
> a) From the "shorewall status", you have configured no maclist
entries
> for eth3!
> b) You cannot use "shorewall show log" to look at MAC addresses
in the
> log; "shorewall show log" removes some information from log
messages
> (including the MAC) to reduce them to 128 characters or less in length
> (which is as wide a window as is supported by some terminal emulators).
> Also, I don''t know if ULOG supports logging of the MAC address.
a) Yes i have configured no maclist for eth3 its true eth3 is the
interface i installed to test this problem at the time i grabbed the files
i have disconfigured them

b) i´m seeing the log directly from the kernel log by metalog.
> 
> > 
> > i ran a tcpdump to see if the mac arrives ok on the machine and its
> > all ok.
> > 
> > now the curious
> > 
> > if i add the mac of my bridge interface''s port1(eth1) to the
maclist
> > on eth3 ( or 2 ) the package passes suceffuly and when i see on the
> > iptables -L eth3_mac -v -n i see that all the traffic on tha chain
> > exits by the wrong mac, the mac of eth1 not  by the mac of the
> machine
> > connected to eth3 how it is supposed to be.
> 
> 
> > 
> > i dont know where but i think the mac changes on the middle of the
> way
> > before checking...
> 
> If so, it''s not a Shorewall problem -- Shorewall can''t
change the
> incoming MAC if it wanted to (for that, you need ebtables which
> Shorewall doesn''t support).
> 
i dont know if the packages are being modified its just my guess ...

one thing its for shure, packages are being dropped by wrong mac.

i`ve cleared the iptables, and inserted some rules to verify maclist and
all of them works very well, including my own old firewall script. it was
not 1 % of shorewall security, it was just maclist, but always worked
> > 
> > the maclist works for connections going to the firewall itself but
> > rejects all traffic that shoud be passing trhouth it.
> > 
> 
> If that''s true then it must be a yet one more Netfilter/Bridge
bug.
> Since I have nothing but your garbled second-hand report however,
what else you need ? my report is inapropriate ? im i wrong or are the
configuration files wrong ? 
> there''s not much I can do about it.
there isn`t ? Well i understand perfectly, anyway thank you very much for
your assistance, i think i´ll have to go look for the source of the
problem myself.

as soon as i find an answer to the problem i´ll post it here.

if someone else has any suggestions please !


Paulo Cunha
pcunha@interlize.com.br
> 
> -Tom
> -- 
> Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
> Shoreline,     \ http://shorewall.net
> Washington USA  \ teastep@shorewall.net
> PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key
> 



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

Cristian Rodriguez

2005-Oct-06 05:05 UTC

head link

Re: maclist problem on a firewall/bridge/router system with masquerading

Paulo Cunha escribió:
> if someone else has any suggestions please !
> 
>
yes. check your distribution kernel and iptables and other utils
updates, current bridge code  has been reported broken several times
here(check the archives), on the netfilter lists, and redhat ''s
bugzilla.




-- 
Cristian Rodriguez R.
perl -e
''$_=pack(c5,0105,0107,0123,0132,(1<<3)+2);y[A-Z][N-ZA-M];print;''

Tom Eastep

2005-Oct-06 14:11 UTC

head link

Re: maclist problem on a firewall/bridge/router system with masquerading

Paulo Cunha wrote:
> 
> what else you need ? my report is inapropriate ? im i wrong or are the
> configuration files wrong ? 
If what you are reporting is in fact happening, there is nothing in the
Shorewall configuration that could possibly cause it.
> 
>> there''s not much I can do about it.
> 
> there isn`t ? 
What I''m saying is that when I submit bug reports to the Netfilter
team,
the reported bugs are meticulously documented. All I have in this case
is second-hand anticdotal evidence that there might be a bug.

If I have the time this weekend, I will build a bridge/firewall and see
if I can reproduce the problem. In the mean time, which kernel and
iptables versions are you running?

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

Tom Eastep

2005-Oct-06 15:59 UTC

head link

Re: maclist problem on a firewall/bridge/router system with masquerading

Tom Eastep wrote:
> 
> All I have in this case
> is second-hand anticdotal evidence that there might be a bug.
> 
The above sentence admittedly undervalues the evidence at hand. From the
"shorewall status", it is very suggestive that packets coming from the
eth2_fwd chain and being sent to the "eth2_mac" chain are matching the
second rule in that chain (the one that specifies the MAC of br0 -- note
that the packet counts are identical). That is very odd and I''m
hard-pressed to think of any type of configuration error that would
cause that to happen.

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

Paulo Cunha

2005-Oct-06 17:58 UTC

head link

Re: maclist problem on a firewall/bridge/router system with masquerading

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tom Eastep wrote:

| Paulo Cunha wrote:
|
|> what else you need ? my report is inapropriate ? im i wrong or
|> are the configuration files wrong ?
|
|
| If what you are reporting is in fact happening, there is nothing in
| the Shorewall configuration that could possibly cause it.
|
|>> there''s not much I can do about it.
|>
|> there isn`t ?
|
|
| What I''m saying is that when I submit bug reports to the Netfilter
| team, the reported bugs are meticulously documented. All I have in
| this case is second-hand anticdotal evidence that there might be a
| bug.
|
| If I have the time this weekend, I will build a bridge/firewall and
| see if I can reproduce the problem. In the mean time, which kernel
| and iptables versions are you running?
|
| -Tom

Many thanks tom, i'' ll do it too this weekend on a new machine and
i''ll try other kernels/configurations .

Paulo Cunha
pcunha@interlize.com.br




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDRWXMgwLgjZASvYURAqokAJ0TDlldelqL2Ro8HUuJW2h+N/w4rQCgmXFt
8zU5kQqBU/BoiuXWdujTXiM=b+KY
-----END PGP SIGNATURE-----




-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

Paulo Cunha

2005-Oct-06 18:10 UTC

head link

Re: maclist problem on a firewall/bridge/router system with masquerading

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cristian Rodriguez wrote:
Cristian,

Thank you, i'' ll try to duplicate the entire setup on a second
forewall for testing this weekend and test some kernel versions,
iptables releases and thingz like that to see if the problem only
occurs with this particular setup.

as soon as i make the tests i'' ll post them here

thank you one more time,

Paulo Cunha
pcunha@interlize.com.br

| Paulo Cunha escribió:
|
|> if someone else has any suggestions please !
|>
|>
|
| yes. check your distribution kernel and iptables and other utils
| updates, current bridge code  has been reported broken several
| times here(check the archives), on the netfilter lists, and redhat
| ''s bugzilla.
|
|
|
|

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDRWiIgwLgjZASvYURAstfAJwMuHydFKOzmbAk2MrKY1763YckUQCg1IsR
6fxR35tEPcu2QTf50fEgd3g=pp4c
-----END PGP SIGNATURE-----




-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

Tom Eastep

2005-Oct-06 20:48 UTC

head link

Re: maclist problem on a firewall/bridge/router system with masquerading

Paulo Cunha wrote:
> 
> Many thanks tom, i'' ll do it too this weekend on a new machine and
> i''ll try other kernels/configurations .
> 
I did a little hacking over the lunch hour.

In CVS (branch SHOREWALL-2_4) are updated shorewall.conf and firewall
files that implement a MACLIST_TABLE option in shorewall.conf. From the
related release notes:

1)  Normally MAC verification triggered by the ''maclist''
interface and
    host options is done out of the INPUT and FORWARD chains of the
    filter table. Users have reported that under some circumstances, MAC
    verification is failing for forwarded packets when the packets are
    being forwarded out of a bridge.

    To work around this problem, a MACLIST_TABLE option has been added
    to shorewall.conf. The default value is MACLIST_TABLE=filter which
    results in the current behavior. If MACLIST_TABLE=mangle then
    filtering will take place out of the PREROUTING chain of the mangle
    table. Because the REJECT target may not be used in the PREROUTING
    chain, the settings MACLIST_DISPOSITION=REJECT and
    MACLIST_TABLE=mangle are incompatible.

If you don''t find another solution to your problem, this option might
provide at least a workaround.

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

Tom Eastep

2005-Oct-06 21:01 UTC

head link

Re: maclist problem on a firewall/bridge/router system with masquerading

Tom Eastep wrote:> Paulo Cunha wrote:
> 
>> Many thanks tom, i'' ll do it too this weekend on a new machine
and
>> i''ll try other kernels/configurations .
>>
> 
> I did a little hacking over the lunch hour.
> 
> In CVS (branch SHOREWALL-2_4) are updated shorewall.conf and firewall
> files that implement a MACLIST_TABLE option in shorewall.conf. From the
> related release notes:
> 
> 1)  Normally MAC verification triggered by the ''maclist''
interface and
>     host options is done out of the INPUT and FORWARD chains of the
>     filter table. Users have reported that under some circumstances, MAC
>     verification is failing for forwarded packets when the packets are
>     being forwarded out of a bridge.
> 
>     To work around this problem, a MACLIST_TABLE option has been added
>     to shorewall.conf. The default value is MACLIST_TABLE=filter which
>     results in the current behavior. If MACLIST_TABLE=mangle then
>     filtering will take place out of the PREROUTING chain of the mangle
>     table. Because the REJECT target may not be used in the PREROUTING
>     chain, the settings MACLIST_DISPOSITION=REJECT and
>     MACLIST_TABLE=mangle are incompatible.
> 
This code is also in the Development branch for those who might be
interested.

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

M Lu

2005-Oct-07 04:22 UTC

head link

Speed up shorewall

I help a friend to run ''shorewall'' on a Linksys''s
OpenWRT. It uses ''ash'' so
it is very slow (around 7 minutes for a restart). I already use
''shorewall
save'' and then run the ''restore'' file. Normally
shorewall will have to be
restarted only when the IP changes. My friend''s IP does change from
time to
time and I would like to speed it even in this case.

I wonder if it is possible to change the ''restore'' file
directly and then
run ''restore'' file. If so, are there any hints on how to
proceed, i.e. how
to capture the data related to the new IP, netmask etc in that
''restore''
file?

Thank you.


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

Paulo Cunha

2005-Oct-07 16:04 UTC

head link

Re: maclist problem on a firewall/bridge/router system with masquerading

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tom Eastep wrote:

| Paulo Cunha wrote:
|
|> Many thanks tom, i'' ll do it too this weekend on a new machine
|> and i''ll try other kernels/configurations .
|>
|
| I did a little hacking over the lunch hour.
|
| In CVS (branch SHOREWALL-2_4) are updated shorewall.conf and
| firewall files that implement a MACLIST_TABLE option in
| shorewall.conf. From the related release notes:
|
| 1)  Normally MAC verification triggered by the ''maclist''
interface
| and host options is done out of the INPUT and FORWARD chains of the
|  filter table. Users have reported that under some circumstances,
| MAC verification is failing for forwarded packets when the packets
| are being forwarded out of a bridge.
|
| To work around this problem, a MACLIST_TABLE option has been added
| to shorewall.conf. The default value is MACLIST_TABLE=filter which
| results in the current behavior. If MACLIST_TABLE=mangle then
| filtering will take place out of the PREROUTING chain of the mangle
|  table. Because the REJECT target may not be used in the PREROUTING
|  chain, the settings MACLIST_DISPOSITION=REJECT and
| MACLIST_TABLE=mangle are incompatible.
|
| If you don''t find another solution to your problem, this option
| might provide at least a workaround.
|
| -Tom

Hum, Good !

i'' ll try it right now and post the results,

DROP is valid on the prerouting chain, is''nt it ?

thank you very much

Paulo Cunha
Pcunha@interlize.com.br


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDRpyOgwLgjZASvYURAvgRAJ92qPJhOX7OnJG0DNvOpDG4h7ecrACfZUrg
Ns+yMJCYyLvQrQCMhCHaKTs=F8ti
-----END PGP SIGNATURE-----




-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

Tom Eastep

2005-Oct-07 16:15 UTC

head link

Re: maclist problem on a firewall/bridge/router system with masquerading

Paulo Cunha wrote:> Tom Eastep wrote:
> 
> i'' ll try it right now and post the results,
> 
> DROP is valid on the prerouting chain, is''nt it ?
> 
Yes.

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

Tom Eastep

2005-Oct-10 15:10 UTC

head link

Re: maclist problem on a firewall/bridge/router system with masquerading

Paulo Cunha wrote:
> 
> Hum, Good !
> 
> i'' ll try it right now and post the results,
> 
Any results to report?

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

Paulo Cunha

2005-Oct-10 20:15 UTC

head link

Re: maclist problem on a firewall/bridge/router system with masquerading

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yeah,

i tryed the cvs version last day but  ... same thing.

i searched the shorewall'' entire code for the string
"MAC_TABLE" but
it was only found on the shorewall.conf

i thot it strange then i stopd trying. on the last night i was looking
in the shorewall code and i find the MACLIST_TABLE variable.

i think that with so many maclist variables the name in shorewall.conf
just got lost in the middle of the way :)

am i correct ?

if so i will try to change it at the end of the day and report to you
tomorrow, ok !


thank you one one time,

Paulo Cunha
pcunha@interlize.com.br



Tom Eastep wrote:

| Paulo Cunha wrote:
|
|> Hum, Good !
|>
|> i'' ll try it right now and post the results,
|>
|
| Any results to report?
|
| -Tom


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDSsvIgwLgjZASvYURAoa5AKCGeHia/wwZekcgGXjG3B8jKwBTqwCffcCD
rx5buPFySSnO9PxwOKKcIbU=Qikc
-----END PGP SIGNATURE-----




-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

Tom Eastep

2005-Oct-10 21:32 UTC

head link

Re: maclist problem on a firewall/bridge/router system with masquerading

Paulo Cunha wrote:> Yeah,
> 
> i tryed the cvs version last day but  ... same thing.
> 
> i searched the shorewall'' entire code for the string
"MAC_TABLE" but
> it was only found on the shorewall.conf
> 
> i thot it strange then i stopd trying. on the last night i was looking
> in the shorewall code and i find the MACLIST_TABLE variable.
> 
> i think that with so many maclist variables the name in shorewall.conf
> just got lost in the middle of the way :)
> 
> am i correct ?
Yes, sorry -- the documentation and code used MACLIST_TABLE but
shorewall.conf had MAC_TABLE. MACLIST_TABLE is correct.

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

Tom Eastep

2005-Oct-10 21:45 UTC

head link

Re: maclist problem on a firewall/bridge/router system with masquerading

Tom Eastep wrote:
> 
> Yes, sorry -- the documentation and code used MACLIST_TABLE but
> shorewall.conf had MAC_TABLE. MACLIST_TABLE is correct.
> 
I should mention that this problem also exists in 3.0.0 Beta 1. I''ve
uploaded a corrected shorewall.conf to:

http://www1.shorewall.net/pub/shorewall/3.0/shorewall-3.0.0-Beta1/errata/
ftp://ftp1.shorewall.net/pub/shorewall/3.0/shorewall-3.0.0-Beta1/errata/

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

Tom Eastep

2005-Oct-11 16:40 UTC

head link

Re: maclist problem on a firewall/bridge/router system with masquerading

On Friday 07 October 2005 09:04, Paulo Cunha wrote:
> |
> | To work around this problem, a MACLIST_TABLE option has been added
> | to shorewall.conf. The default value is MACLIST_TABLE=filter which
> | results in the current behavior. If MACLIST_TABLE=mangle then
> | filtering will take place out of the PREROUTING chain of the mangle
> |  table. Because the REJECT target may not be used in the PREROUTING
> |  chain, the settings MACLIST_DISPOSITION=REJECT and
> | MACLIST_TABLE=mangle are incompatible.
> |
> | If you don''t find another solution to your problem, this option
> | might provide at least a workaround.
> |
> | -Tom
>
> Hum, Good !
>
> i'' ll try it right now and post the results,
>
> DROP is valid on the prerouting chain, is''nt it ?
>
I have reproduced this problem and I have verified that MACLIST_TABLE=mangle 
is able to work around it.

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

Paulo Cunha

2005-Oct-13 17:35 UTC

head link

Re: maclist problem on a firewall/bridge/router system with masquerading

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tom Eastep wrote:

| On Friday 07 October 2005 09:04, Paulo Cunha wrote:
|
|> | | To work around this problem, a MACLIST_TABLE option has been
|> added | to shorewall.conf. The default value is
|> MACLIST_TABLE=filter which | results in the current behavior. If
|> MACLIST_TABLE=mangle then | filtering will take place out of the
|> PREROUTING chain of the mangle |  table. Because the REJECT
|> target may not be used in the PREROUTING |  chain, the settings
|> MACLIST_DISPOSITION=REJECT and | MACLIST_TABLE=mangle are
|> incompatible. | | If you don''t find another solution to your
|> problem, this option | might provide at least a workaround. | |
|> -Tom
|>
|> Hum, Good !
|>
|> i'' ll try it right now and post the results,
|>
|> DROP is valid on the prerouting chain, is''nt it ?
|>
|
| I have reproduced this problem and I have verified that
| MACLIST_TABLE=mangle is able to work around it.
|
| -Tom

Hi Tom,

i ''ve finally had time last day and tested it and it worked !

now the counters on the mangle table are incrementing :)

i''m in hurry now but later i ll post a more detailed test result for
you

i would like to thank you very very much for your efforts to solve my
problem, and thank you again for your efforts to make shorewall day
after day only better.

i''m at your disposal, if there are anything that you need, maybe a
good php programmer, a brazillian mirror, an internet service,  a
translation to brazillian-portuguese just tell'' me and i ll be glad to
help you.

Paulo Cunha
Administrador de Redes

*Interlize*
Tecnologia Gerando Receita
Telefone: +55 21 2421-1750 / Fax: +55 21 2421-9190
internet@interlize.com.br <mailto:internet@interlize.com.br>
www.interlize.com.br <http://www.interlize.com.br>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDTprygwLgjZASvYURAlG3AKCIpKHFyrrkxp8kVWnjMG4+zPJXmACfcvC8
N6bZPqTzCpvtt2rT8P/zVw0=Ne+x
-----END PGP SIGNATURE-----




-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

Possibly Parallel Threads

Search for more apparently analagous threads

Shorewall users - Sep 2005 - maclist problem on a firewall/bridge/router system with masquerading

maclist problem on a firewall/bridge/router system with masquerading

Re: maclist problem on a firewall/bridge/router system with masquerading

Re: maclist problem on a firewall/bridge/router system with masquerading

Re: maclist problem on a firewall/bridge/router system with masquerading

Re: maclist problem on a firewall/bridge/router system with masquerading

Re: maclist problem on a firewall/bridge/router system with masquerading

Re: maclist problem on a firewall/bridge/router system with masquerading

Re: maclist problem on a firewall/bridge/router system with masquerading

Re: maclist problem on a firewall/bridge/router system with masquerading

Re: maclist problem on a firewall/bridge/router system with masquerading

Re: maclist problem on a firewall/bridge/router system with masquerading

Re: maclist problem on a firewall/bridge/router system with masquerading

Speed up shorewall

Re: maclist problem on a firewall/bridge/router system with masquerading

Re: maclist problem on a firewall/bridge/router system with masquerading

Re: maclist problem on a firewall/bridge/router system with masquerading

Re: maclist problem on a firewall/bridge/router system with masquerading

Re: maclist problem on a firewall/bridge/router system with masquerading

Re: maclist problem on a firewall/bridge/router system with masquerading

Re: maclist problem on a firewall/bridge/router system with masquerading

Re: maclist problem on a firewall/bridge/router system with masquerading

Possibly Parallel Threads