VLAN Configuration Mislabled WAN

Router: WRT54GS v1.1
X-WRT version: r3978
Problem Part 1:
The webif indicates the following default configuration

       eNet0  eNet1  eNet2  eNet3  WAN  Internal
VLAN 0          *      *      *     *      *
VLAN 1   *                                 *

Presumably, the WAN port should probably not be on the same VLAN as the LAN
ports. Even though they are on different IP subnets and even though the LAN
devices probably have non-routable addresses in most configurations, having
LAN ports connected to the Internet would seem to present a major security
problem. Especially if they are not protected by firewalls because it was
not known that they were so connected. Also, it seems to me that all the
LAN ports should probably be on the same VLAN in a default configuration,
as shown below:

       eNet0  eNet1  eNet2  eNet3  WAN  Internal
VLAN 0   *      *      *      *            *
VLAN 1                              *      *

Problem Part 2:
However, making that change in the webif (Save Changes, Apply Changes)
makes no difference in the router's operation. Checking the configuration
page though shows the changes applied.

If though at some later time the router is for some reason rebooted it will
then cease routing IP traffic to the WAN port. To get it working again the
VLAN page can be used to put the WAN port back on VLAN 0 along with eNet1~3
and eNet0 back on VLAN 1. Again, although the webif will indicate that the
change has been applied IP traffic will still not be routed to the WAN
port. At this point rebooting will cause IP traffic to once again be routed
to the WAN port but now DNS will be broken. Applying bogus DNS settings and
then reapplying proper DNS settings will now finally get the router working
again. 

03/15/08 10:58:28 changed by thepeople  ¶

Part1: The problem looks like the labeling of the wan port is incorrect for
your model of router. eNet0 looks to be the wan port and wan is port on the
lan switch.

Part2: this is a problem in OpenWrt? which was recently fixed in trunk
(https://dev.openwrt.org/changeset/10540)
(in reply to: ↑ 1 ) 03/15/08 13:16:37 changed by box919+xwrt@gmail.com ¶

Replying to thepeople:

    Part1: The problem looks like the labeling of the wan port is incorrect
for your model of router. eNet0 looks to be the wan port and wan is port on
the lan switch.

This is still a problem then. It could lead someone who saw this:

        eNet0  eNet1  eNet2  eNet3  WAN  Internal
 VLAN 0          *      *      *     *      *
 VLAN 1   *                                 *

to try to correct the situation by doing this:

        eNet0  eNet1  eNet2  eNet3  WAN  Internal
 VLAN 0                              *      *
 VLAN 1   *      *      *      *            *

and thus inadvertently move some LAN ports to the same VLAN as the WAN (in
effect putting those ports in a kind of DMZ). I'm sure you can see the
security implications of that. This would seem to me to warrant an urgent fix.

    Part2: this is a problem in OpenWrt?? which was recently fixed in trunk
(https://dev.openwrt.org/changeset/10540)

Part 2 also involves inaccurate representation of the current VLAN
configuration. It's just bad for security when the webif says the VLANs are
configured one way but in reality they are configured differently (besides
breaking routing).
03/15/08 17:32:21 changed by box919+xwrt@gmail.com ¶

Here's an example of what of could happen.

An owner sees the default VLAN configuration and thinks to himself, "What
the heck? How could this have been working?". So he then decides to apply
what would be appear to be a correct configuration to see what happens.
Nothing changes. "Ah, I see" he thinks. "The setting on this page don't
seem to do anything. Well, I'll just leave them set so that they at least
appear to be correct. That way if a future firmware fix enables them
they'll at least be right when it does." He goes about his way thinking
everything is at least secure.

Then some days, weeks, or even months later there is a power failure. When
power is restored the router reboots, reconfigures the switch and the
connected computers begin booting and broadcasting DHCP requests. However
and unknown to the owner, 3 of them are now actually on the same VLAN and
broadcast domain as the real WAN. The cable/DSL modem then dutifully
provides one or more of them with routable global IP addresses and connects
them directly to the Internet, Windows file sharing and all. To the owner,
since these computers still have Internet connectivity, they appear to
working normally. Windows file sharing even works between them. However,
these computers were intended to be used with the protection of NAT and a
router firewall on a private network and are not hardened for the Internet.
It is not long before they are thoroughly infected and the owner is owned.
(follow-up: ↓ 5 ) 03/17/08 10:11:25 changed by lubek ¶

    * owner changed from developers to lubek.
    * status changed from new to assigned.
    * version set to whiterussian.

No matter how many disaster scenarios you describe, the issue is still the
same.

    * the WAN port is the port 0 of the switch for your device (the column
label is wrong)
    * the switch is not reset by the network init (only by reboot) 

1) There is not a 100% positive identification of the WAN port between
devices. OpenWrt? detects (the diag module) your device as WRT54G. webif2
tries to guess the wan port according to this information. I do not know
why the page assigns 4 to the wan port for WRT54G because probably only
SL54GS and 54GL have different port mappings. (Maybe the original developer
used one of these devices.)

The user can also remap ports then the labels will not reflect the state as
well.

There is no hw database of devices (only sources, this information
https://svn.berlios.de/svnroot/repos/xwrt/whiterussian/docs/hardware/ and
the forum, see http://forum.openwrt.org/viewtopic.php?pid=8127).

2) We can backport a similar solution to White Russian.
(in reply to: ↑ 4 ) 03/18/08 08:58:20 changed by box919+xwrt@gmail.com ¶

Replying to lubek:

    No matter how many disaster scenarios you describe, the issue is still
the same.

Yes, and who said anything otherwise? I don't know what your problem is but
you really shouldn't take security related bug reports personally and then
personally attack the person reporting them. Your approach to security
vulnerabilities is interesting, to say the least, and doesn't exactly
inspire confidence. In fact, it raises a big red flag about safety and
quality. Thanks for the warning.

Replying to lubek:

    1) There is not a 100% positive identification of the WAN port between
devices. OpenWrt?? detects (the diag module) your device as WRT54G. webif2
tries to guess the wan port according to this information.

That's a pretty lame excuse. Like if you can't detect the hardware version
it would be real hard to ask the user? Or create proper firmware versions
for specific hardware? Those are just a couple of possibilities that pop
into my mind. As if though you care.
03/18/08 15:01:22 changed by lubek ¶

Well, thanks for your report. Although there are many owners of the WRT54G
group of devices, no one has reported this mistake. Notice that it is more
than a year old.

I summarized issues because your two new comments did not add anything new
to the original report except possible consequences. I also tried to
explain the reason of the mistake and the lack of information about WRT54G
variants.

I considered the report to be valid and I accepted the summarized issues.

I do not see anything personal in my steps except that I replied to your
report. But maybe I am wrong and I mistakenly used something which is
considered a personal invective in your area. So please forgive me for my
impertinence, my only excuse is that the used language is not my native
one. :-)

And please stop waving your big red flag about safety and quality. We all
are trying to make it better.

The White Russian branch is closed for any development or fixes in
OpenWrt?. I started to fix issues in both OpenWrt? branch and webif2 for
this branch due to the continuous interest of users more than a year ago.
My only lame excuse is that I am doing it in my free time and that I am alone.

I hope that it is enough for the explanation of "my personal attack,
security approach, lame excuses problem" in this ticket.

1) The switch port naming was fixed in r4054. Because I do not have enough
information and personal knowledge about WRT54g variants, I removed it from
the detection. If you know how to exactly detect all variants, do not
hesitate to contribute.

2) I have not fixed it yet but I am working on a solution. And that is why
I am not closing this ticket.
03/18/08 19:46:03 changed by box919+xwrt@gmail.com ¶

I seem to have mistaken your intentions and on that basis I apologize.

As for a possible solution for the WRT54GS v1.1 a simple solution would be
one I suggested above: Simply create a firmware variant for that particular
router that the user can download. Thus a WRT54GS v1.1 owner could down
firmware for that specific version and it would have the correct port
mappings. As far as I'm aware, all WRT54GS v1.1 routers have the same
hardware and port mappings so that should be workable.
03/19/08 13:09:17 changed by box919+xwrt@gmail.com ¶

Even just giving the ports generic labels like 1 through 5 would be better
than mislabeling them. Although that wouldn't tell the user which port
corresponded to the WAN port at least it wouldn't be giving them false
information.
Original issue reported on code.google.com by kemen04@gmail.com on 9 Jul 2008 at 8:51
micbat / x-wrt

VLAN Configuration Mislabled WAN #60
