ppooe state RELATED,ESTABLISHED issue

ppooe state RELATED,ESTABLISHED issue

[Ted Kaczmarek]

Today I was testing a Centos 4.1(RH ES4 clone) with  2.6.9-11.EL and a
Verizon dsl connection. I couldn't get any connection tracking related
rules working on the pppoe interface.

-A INPUT -i ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT

The only way I could get it to forward traffic 
was to allow all INPUT and FORWARD traffic for ppp0.

The pppoe is using eth0 and the inside interface is eth1.

Googling uncovered a thread with respect to connection tracking being
broken 
with bridging.

http://www.uwsg.iu.edu/hypermail/linux/kernel/0506.2/0422.html

Is this really the same issue? If packets are coming in eth1 and leaving
ppp0(using eth0)
are they not just being routed? If eth0 is up the I can see packets
being bridged from ppp0e to eth0, but with eth0 down I am at a loss as
to why this is happening.

Also is this issue specific to 2.6? A 2.4 based machine would likely
suffice in this application.


Regards,
Ted

Re: ppooe state RELATED,ESTABLISHED issue

[Grant Taylor]

Just a stab in the dark.

I don't know if this is the issue or not but something that comes to 
mind is what did you set your INPUT / FORWARD / OUTPUT chains default 
policy to?  If you set it to DENY then you will have to explicitly allow 
traffic that is coming in and out the respective interfaces to set up 
the PPPoE connection / tunnel.  I don't know enough about this (PPPoE) 
to help.

Ted Kaczmarek wrote:

>Today I was testing a Centos 4.1(RH ES4 clone) with  2.6.9-11.EL and a
>Verizon dsl connection. I couldn't get any connection tracking related
>rules working on the pppoe interface.
>
>-A INPUT -i ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT
>-A FORWARD -i ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT
>
>The only way I could get it to forward traffic 
>was to allow all INPUT and FORWARD traffic for ppp0.
>
>The pppoe is using eth0 and the inside interface is eth1.
>
>Googling uncovered a thread with respect to connection tracking being
>broken 
>with bridging.
>
>http://www.uwsg.iu.edu/hypermail/linux/kernel/0506.2/0422.html
>
>Is this really the same issue? If packets are coming in eth1 and leaving
>ppp0(using eth0)
>are they not just being routed? If eth0 is up the I can see packets
>being bridged from ppp0e to eth0, but with eth0 down I am at a loss as
>to why this is happening.
>
>Also is this issue specific to 2.6? A 2.4 based machine would likely
>suffice in this application.
>
>
>Regards,
>Ted
>

Re: ppooe state RELATED,ESTABLISHED issue

[Jan Engelhardt]

>Today I was testing a Centos 4.1(RH ES4 clone) with  2.6.9-11.EL and a
>Verizon dsl connection. I couldn't get any connection tracking related
>rules working on the pppoe interface.
>
>-A INPUT -i ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT
>-A FORWARD -i ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT

Where's the handling for NEW connections? Otherwise you won't succeed if your 
default policy is !ACCEPT.


>Googling uncovered a thread with respect to connection tracking being
>broken with bridging.

You got a bridge in there?



Jan Engelhardt
-- 

Re: ppooe state RELATED,ESTABLISHED issue

[Jörg Harmuth]

Ted Kaczmarek schrieb:
> Today I was testing a Centos 4.1(RH ES4 clone) with  2.6.9-11.EL and a
> Verizon dsl connection. I couldn't get any connection tracking related
> rules working on the pppoe interface.
> 
> -A INPUT -i ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT
> -A FORWARD -i ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT
> 
> The only way I could get it to forward traffic 
> was to allow all INPUT and FORWARD traffic for ppp0.

Definitely not what you want :)

> The pppoe is using eth0 and the inside interface is eth1.
> 
> Googling uncovered a thread with respect to connection tracking being
> broken 
> with bridging.
> 
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0506.2/0422.html
> 
> Is this really the same issue? If packets are coming in eth1 and leaving
> ppp0(using eth0) are they not just being routed?

With policies set to ACCEPT and no other rules in place: Yes.

> If eth0 is up the I can see packets
> being bridged from ppp0e to eth0, but with eth0 down I am at a loss as
> to why this is happening.

Ofcourse, if eth0 is down no ppp traffic is possible.

> Also is this issue specific to 2.6? A 2.4 based machine would likely
> suffice in this application.

Probably not, but I don't know.

Well to start off, ppp0 is a logical interface, encapsulating the
physical interface (here: eth0). So, all your rules - as you did - must
be applied to eth1 and ppp0. You are forwarding packets, so must
MASQUERADE all outgoing traffic through ppp0. In most cases you can't
use SNAT, except your ISP gives you allways the same IP when you go
online (in Germany DSL connections are disconnected by the ISP once a day).

So, a basic rule-set could look like this:

echo 1 > /proc/sys/net/ipv4/ip_forward

-P INPUT DROP
-P FORWARD DROP

-A INPUT[FORWARD] -m state --state RELATED,ESTABLISHED -j ACCEPT

-t nat -A POSTROUTING -o ppp0 -j MASQUERADE

From now on, all you have to do is allowing the connections you want on
the respective interface like this:

-A INPUT -i ppp0 -p tcp --dport 80 --syn -j ACCEPT

Same goes for eth1. Forwarding looks just the same:

-A FORWARD -i eth1 -p tcp --dport 119 --syn -j ACCEPT

if you are DNATing connetions to your router, you must SNAT them too:

-t nat -A PREROUTING -i eth1 -p tcp --dport 119 \
   -j DNAT --to $NNTP_IP
-t nat -A POSTROUTIMG -o eth1 -p tcp --sport 119 \
   -j SNAT --to $NAT_BOX_IP_ON_ETH1

Always assuming, that all policies not mentioned yet, are set to ACCEPT.
Additionally, I'm a friend of this (last rule):

-A INPUT[FORWARD] -p tcp -j REJECT --reject-with tcp-reset

HTH and have a nice time,

Joerg

Re: ppooe state RELATED,ESTABLISHED issue

[Ted Kaczmarek]

On Fri, 2005-08-05 at 10:55 +0200, Jörg Harmuth wrote:
> Ted Kaczmarek schrieb:
> > Today I was testing a Centos 4.1(RH ES4 clone) with  2.6.9-11.EL and a
> > Verizon dsl connection. I couldn't get any connection tracking related
> > rules working on the pppoe interface.
> > 
> > -A INPUT -i ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT
> > -A FORWARD -i ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT
> > 
> > The only way I could get it to forward traffic 
> > was to allow all INPUT and FORWARD traffic for ppp0.
> 
> Definitely not what you want :)
> 
> > The pppoe is using eth0 and the inside interface is eth1.
> > 
> > Googling uncovered a thread with respect to connection tracking being
> > broken 
> > with bridging.
> > 
> > http://www.uwsg.iu.edu/hypermail/linux/kernel/0506.2/0422.html
> > 
> > Is this really the same issue? If packets are coming in eth1 and leaving
> > ppp0(using eth0) are they not just being routed?
> 
> With policies set to ACCEPT and no other rules in place: Yes.
> 
> > If eth0 is up the I can see packets
> > being bridged from ppp0e to eth0, but with eth0 down I am at a loss as
> > to why this is happening.
> 
> Ofcourse, if eth0 is down no ppp traffic is possible.
> 
> > Also is this issue specific to 2.6? A 2.4 based machine would likely
> > suffice in this application.
> 
> Probably not, but I don't know.
> 
> Well to start off, ppp0 is a logical interface, encapsulating the
> physical interface (here: eth0). So, all your rules - as you did - must
> be applied to eth1 and ppp0. You are forwarding packets, so must
> MASQUERADE all outgoing traffic through ppp0. In most cases you can't
> use SNAT, except your ISP gives you allways the same IP when you go
> online (in Germany DSL connections are disconnected by the ISP once a day).
> 
> So, a basic rule-set could look like this:
> 
> echo 1 > /proc/sys/net/ipv4/ip_forward
> 
> -P INPUT DROP
> -P FORWARD DROP
> 
> -A INPUT[FORWARD] -m state --state RELATED,ESTABLISHED -j ACCEPT
> 
> -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
> 
> >From now on, all you have to do is allowing the connections you want on
> the respective interface like this:
> 
> -A INPUT -i ppp0 -p tcp --dport 80 --syn -j ACCEPT
> 
> Same goes for eth1. Forwarding looks just the same:
> 
> -A FORWARD -i eth1 -p tcp --dport 119 --syn -j ACCEPT
> 
> if you are DNATing connetions to your router, you must SNAT them too:
> 
> -t nat -A PREROUTING -i eth1 -p tcp --dport 119 \
>    -j DNAT --to $NNTP_IP
> -t nat -A POSTROUTIMG -o eth1 -p tcp --sport 119 \
>    -j SNAT --to $NAT_BOX_IP_ON_ETH1
> 
> Always assuming, that all policies not mentioned yet, are set to ACCEPT.
> Additionally, I'm a friend of this (last rule):
> 
> -A INPUT[FORWARD] -p tcp -j REJECT --reject-with tcp-reset
> 
> HTH and have a nice time,
> 
> Joerg

With 2.4 Kernel Centos 3.5 it works fine, but I didn't bring up eth0 ip
interface. Need to retest this without an ip interface on eth0 and 2.6
kernel, the previous case I had an ip on eth0 as well.


Ted

Re: ppooe state RELATED,ESTABLISHED issue

[Jan Engelhardt]

>With 2.4 Kernel Centos 3.5 it works fine, but I didn't bring up eth0 ip
>interface. Need to retest this without an ip interface on eth0 and 2.6
>kernel, the previous case I had an ip on eth0 as well.

The "up" and "down" states of interfaces seems to be the hardware switch. 
Dunno how it is implemented with NICs, but I have seen that in snd-cs46xx.c, 
the card is totally shutdown on module unload. So I guess, it's the same on 
"ip l s dev eth0 down"

To have a bridge `a la ebtables work, the ports need to be up. And preferably, 
have no IP. This is really cool - I've got a br0 with eth2 linked to a WLAN 
router. With just one command, "ip l s dev eth2 down", all wlan traffic 
(through the server) can be disabled.


Jan Engelhardt
-- 
| Alphagate Systems, http://alphagate.hopto.org/