weird iptables behaviour

weird iptables behaviour

[Gabriel]

I'm connecting to an openvpn box from a remote location. I
can access the box I'm connecting to (I'm getting ping
replies), but nothing that's beyond it (the box serves as a
gateway for other clients). I'm using openvpn's --dev tap0
because i need to pass non-ip packets through the tunnel.
On the openvpn box, FORWARD policy is DROP, so I did
"iptables -I FORWARD -i tap0 -j ACCEPT" and thought this
should do the trick. But I was wrong. The only solutions I
found were either set FORWARD policy to ACCEPT (not happy
with that) or insert an iptables rule in the FORWARD chain
that gives access based on the MAC address. I'm probably
going to use the latter, but I can't really understand why
"iptables -I FORWARD -i tap0 -j ACCEPT" won't work. Isn't
this supposed to let ALL packets (not just ip packets) pass
through? I'm thinking that it has something to do with the
fact that i'm using --dev tap0 (tap0 is bridged with eth1 -
the LAN facing interface - and they form br0) which is
layer2 but, as I said before, -i tap0 -j ACCEPT should work
as well...

Thanks

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: weird iptables behaviour

[Grant Taylor]

Gabriel wrote:
> I'm connecting to an openvpn box from a remote location. I
> can access the box I'm connecting to (I'm getting ping
> replies), but nothing that's beyond it (the box serves as a
> gateway for other clients). I'm using openvpn's --dev tap0
> because i need to pass non-ip packets through the tunnel.
> On the openvpn box, FORWARD policy is DROP, so I did
> "iptables -I FORWARD -i tap0 -j ACCEPT" and thought this
> should do the trick. But I was wrong. The only solutions I
> found were either set FORWARD policy to ACCEPT (not happy
> with that) or insert an iptables rule in the FORWARD chain
> that gives access based on the MAC address. I'm probably
> going to use the latter, but I can't really understand why
> "iptables -I FORWARD -i tap0 -j ACCEPT" won't work. Isn't
> this supposed to let ALL packets (not just ip packets) pass
> through? I'm thinking that it has something to do with the
> fact that i'm using --dev tap0 (tap0 is bridged with eth1 -
> the LAN facing interface - and they form br0) which is
> layer2 but, as I said before, -i tap0 -j ACCEPT should work
> as well...

First of all you will need to have a corresponding rule:

iptables -I FORWARD -o tap0 -j ACCEPT

To allow traffic in the reverse direction too.

Did you compile your bridging support with bridge-nf support?  If you did you will need to do some more work to allow your traffic to pass through.  This is because the bridge-nf code allows IPTables to see the traffic that is passing on layer 2 as if it was on layer 3.  Thus you will probably need a rule like this:

iptables -I FORWARD -i br0 -o br0 -j ACCEPT



Grant. . . .

Re: weird iptables behaviour

[/dev/rob0]

On Friday 2005-September-16 00:45, Grant Taylor wrote:
> > On the openvpn box, FORWARD policy is DROP, so I did
> > "iptables -I FORWARD -i tap0 -j ACCEPT" and thought this
> > should do the trick. But I was wrong. The only solutions I
>
> First of all you will need to have a corresponding rule:
>
> iptables -I FORWARD -o tap0 -j ACCEPT
>
> To allow traffic in the reverse direction too.

Better yet, the usual stateful rule:
iptables -I FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header

Re: weird iptables behaviour

[Gabriel]

> --- /dev/rob0 <rob0@gmx.co.uk> wrote:
> 
> On Friday 2005-September-16 00:45, Grant Taylor wrote:
> > > On the openvpn box, FORWARD policy is DROP, so I
> did
> > > "iptables -I FORWARD -i tap0 -j ACCEPT" and thought
> > this
> > > should do the trick. But I was wrong. The only
> solutions I
> >
> > First of all you will need to have a corresponding
> rule:
>
> iptables -I FORWARD -o tap0 -j ACCEPT
>
> To allow traffic in the reverse direction too.
> 
> Better yet, the usual stateful rule:
> iptables -I FORWARD -m state --state RELATED,ESTABLISHED
> -j ACCEPT

I'm sorry, I forgot to mention I already have the stateful
rule in the chain. It's not in the first position, but I
don't think that matters because I issued a few consecutive
"iptables -L FORWARD -v" and, from what I could tell, all
the ping packets hit the default (DROP) policy, so this
means the packets did not match either the first (-i tap0
-j ACCEPT) rule (which is normal, since only the first ping
packet matches that), or the stateful rule (which is
somewhere down in the chain and _should_ have been matched
by the other ping packets).
 
> Did you compile your bridging support with bridge-nf 
> support?  If you did you will need to do some more work
to > allow your traffic to pass through.  This is because
> the bridge-nf code allows IPTables to see the traffic
that
> is passing on layer 2 as if it was on layer 3. 
 
Yeah, apparently I have CONFIG_BRIDGE_NETFILTER=y. But
still, from what I know, the "-i tap0 -j ACCEPT" and the
stateful rule should be enough. The packet comes in on
tap0, should get through and the reply should match the
stateful rule.
 
> Thus you will> probably need a rule like this:
>
> iptables -I FORWARD -i br0 -o br0 -j ACCEPT
 
I don't understand this rule. Does it mean that what comes
on any of the bridged interfaces can go to any (other)
bridged interface(s)?

P.S.: Sorry for the private reply, /dev/rob0. I didn't look
at the "To:" field...


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com