Opened 10 years ago

Closed 9 years ago

#2515 closed defect (fixed)

wrong firewall / packet filter rules if using PPPoE

Reported by: G.Ohrner@… Owned by: developers
Priority: high Milestone:
Component: packages Version:
Keywords: Cc:


The iptables firewall.init script retrieves its WAN interface name using

config_get WAN wan ifname

which will return something like eth0.1 (on a WRT54G) instead of ppp0.

As a consequence, all WAN related rules will be wrong, as no packets will ever arrive on eth0.1 and ppp0 stays completely unfiltered.
Especially, in the default configuration, the LAN_ACCEPT rule will allow all packets from ppp0 if the input_rule does not deny them. In addition to fixing the ifname problem, I'd also opt for changing the rule structure to a "better safe than sorry" approach, only allowing packages KNOWN to be from LAN into rules like LAN_ACCEPT, instead of only blocking it for packets which are considered to come from the WAN.

Attachments (0)

Change History (6)

comment:1 Changed 10 years ago by florian

  • Resolution set to worksforme
  • Status changed from new to closed

If you have configured your WAN interface to match the PPPoE connection, the variable will contain your pppX interface name and firewall rules will apply.

comment:2 Changed 10 years ago by anonymous

  • Resolution worksforme deleted
  • Status changed from closed to reopened

I second this problem.

here are my settings :
Firmware OpenWrt Kamikaze - With X-Wrt Extensions 7.09
Kernel Linux 2.6.22 #10 Tue Jan 15 15:51:50 CST 2008
MAC 00:1C:10:BC:XX:XX
Device Linksys WRT54G/GS/GL
Board Broadcom BCM47xx

The descirption of the problem is absolutely perferct. I got the feeling that there is a bug in kamikaze default config between ifname and wan_device
To illustrate this I will also provide /var/state/network

config_set 'loopback' 'ifname' 'lo'
config_set 'loopback' 'up' '1'
config_set 'lan' 'ifname' 'br-lan'
config_set 'lan' 'up' '1'
config_set 'wan' 'ifname' 'eth0.1'
config_set 'wan' 'ifname' 'ppp0'
config_set 'wan' 'ifname' 'eth0.1'
config_set 'wan' 'ifname' 'ppp0'
config_set 'wan' 'up' '1'
config_set 'wan' 'ipaddr' 'good ip'
config_set 'wan' 'gateway' 'good ip'

comment:3 Changed 10 years ago by stephane

I wrote the previous comment to reopen the ticket.

I forgot to mention that although I use a broadcom WRT54 GL v1.1, I decided to use the 2.6 kernel (as I got a lot of netfilter to do on this box) even if the wireless card won't work with this versio0n (I don't need it) for my board on this openwrt kernel version.
I don't know if this info is relevant to you.

To my mind, this is a pretty urgent bug...


comment:4 Changed 10 years ago by stephane


I think I got it. Need some more testing (and it s still difficult for me before night time) but here is what I understand of

in /etc/config/network
we should have something like
#### WAN configuration
config interface wan

option ifname 'ppp0'
option device 'eth0.1'
option proto 'pppoe'
option username 'xxxx'
option password 'xxxx'

as the pppd daemon is gonna change the name of interfaces (ifname) at run time.
We should put the ifname to ppp0 and the device name must point to the physical interface, in our case vlan 1 : eth0.1

Maybe here, we could also have something like
option dns "<dns ip address>"

What convinces me this is the right config is this little script suggested by
. /etc/ # common functions
include /lib/network # include /lib/network/*.sh
scan_interfaces # read and parse the network config
echo "wan ifname is $(config_get wan ifname)"
echo "wan device is $(config_get wan device)"

chmod +x it and run it...

I forgot to mention that openwrt is the dream of all linux net admins !
Thanks guys, you are blowing my mind.

PS : I will post tonight after I test everything.

comment:5 Changed 10 years ago by anonymous


(I am stephane but can t login)

I found the problem
during the boot sequence, the start function of /etc/init.d/network is NOT called.
Only boot is called. So the pppoe interface is never up at boot time, and especially not when /etc/init.d/firewall is called.

If you check at the code of /etc/rc.common, you will see that rc.common defines the boot function as a call to start. But as /etc/init.d/network "overrides" the boot function, start is not executed anymore.

(indeed you can also check this forum thread as it explains the boot process a bit deeper. Anyway, even the hotplug script disgards ppp interfaces and doesn't wake them up.

So the solution is simple, elegant, just call start at the end of boot in /etc/init.d/network

boot() {
        setup_switch() { return 0; }

        include /lib/network
        [ -s /etc/config/wireless ] || \
                /sbin/wifi detect > /etc/config/wireless
       /sbin/wifi up

That's it.

I would also recommand that the kamikaze doc about the WRT config on kamikaze explains that you have to /etc/init.d/firewall start after you ifup the pppoe interface so that dynamic interface names are taken into account.

I think the bug is closed.

Thanks for all your work,


comment:6 Changed 9 years ago by florian

  • Resolution set to fixed
  • Status changed from reopened to closed

Should be fixed now.

Add Comment

Modify Ticket

as closed .
The resolution will be deleted. Next status will be 'reopened'.

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.