B3 netwok configuration: is there any documentation?

[ingo2]

I'd like to setup network in a different way as described in the manual and as can be done via the web-interface.
I have got 3 network interfaces on my B3: WAN (eth0), LAN (eth1) and Wifi. My questions are:

How is topology by design, i.e. which traffic is separated by the firewall (iptables)?

Is there any service/application tied to a fixed interface, i.e. web-interface for configuration to LAN?
How are the device names assigned to a physiclal port, by udev-rules (that would allow to exchange them)?

Which are all the configuration files for the services, like /etc/network/interfaces, /etc/dnsmasq.d/bubba.conf, where are the iptables filter rules defined? And which of them are modified by the web-interface?

Unfortunately I could not find any documentation on this. One of my targets is to have the Wifi separated by the firewall from the ethernet ports (guest subnet). On the other hand I would appreciate to still make as much use as possible of the web-interface for configuration.

With best regards,
Ingo

Me just came up anotherquestion: the WAN-port usually uses TCP/IP, is it capable for PPPoE as well?
(background is, I have a modem here which just establishes the link/synchronisation to ISP's DSLAM)

[gonk]

+1 for that.
As my $0.02 worth of extra questions I add "... and which of the config files are affected by Excito software updates and which are safe to change knowing thet my changes will survive after an update?"

[Gordon]

It is stated that Excito does not touch any conf files during updates. They do however overwrite the apache conf files, but the good part here is that again they do not touch additional conf files you created there (i.e. for virtual/named hosts).

The firewall is a pretty straightforward two-interface firewall. This is no different on the B3 with wifi because they bridged the LAN port and the WLAN port to become a single logical interface. The initial concept is to allow everything that originates from the LAN side and deny everything that originates from the WAN side. The web interface allows you to simply expose standard services through a list of switches, but there's also a form where you can enter more advanced rules to include specific origins and/or destinations and also forward services to other hosts. The rules are maintained by the iptables-save and iptrables-restore commands and it is really a pity that they do all the rewriting of rules in the standard tables INPUT, OUTPUT and FORWARD. The rules are stored in /etc/network/firewall.conf

Do note that changing firewall rules manually can be very risky indeed because the B3 is set to save the active rules on shutdown (is this still true?). This means that if you make a mistake the only way you can recover is by either using a rescue stick or do something that you should never do: pull the powercord for an emergency shutdown. Check here for a more robust firewall script that allows you to control this behaviour.

Except for MySQL which is bound to localhost only, no services are limited to any specific interface.

To verify:

Code: Select all

netstat -an | grep  "LISTEN *$" | awk '{print $4}' | grep -v "^[0:]"

(Leave out the last grep to list all active services)

udev actually caches device hardware ID's and permanently binds the device names to them. It does not reassign device names if you exchange hardware but simply moves on to the next available one (i.e. your system could have eth2 and eth3 instead of eth0 and eth1).

If you need PPPoE simply install the package for it - it will guide you through the rest.

[ingo2]

Thanks Gordon,
your explanation makes things a lot easier. When I understand how things are working it is much easier to decide what can be done and what isn't worth the effort.

that already explains a lot. Didn't know that wlan0 is just bridged with eth1 (LAN port) if activated. I just confimed in /etc/network/interfaces.

Iptables rules as defined in /etc/network/firewall.conf however are applied to eth0 and eth1, independend of WLAN settings - they are not applied to the bridge.
So exchanging LAN and WAN ports (eth0/eth1) would be a significant security gain by exposing eth1+wlan0 to the internet and having the LAN on eth0 securely behind the firewall. This would allow to still make use of the configuration via web-interface and probably can be done very easily by changing configuration of corresponding udev-rule(s)?

The only thing (probaly, if used) remaining is to reconfigure dnsmasq and NAT to accomodate the situation.

Many thanks,
Ingo

[Gordon]

Actually if you have a Wifi version than the firewall should state br0 (Bridge #1) as the internal interface and not eth1. Also, if you want your WLAN to act as a guest network, which in my definition would be to allow them access to internet and not your internal network, would require you to "bounce off" this type of traffic if you were to keep the bridge. While this may in fact be possible, I'd say: don't!

Additionally: the firewall rules that are maintained through the web interface will look at one specific element to define its blocks: eth0. If you are to reverse the functionality of eth0 and eth1 than all this web interface will allow you to do is block access to services from your LAN environment.

Steps to do:
1) break the bridge to become eth1 and wlan0 with both their own IP address
2) change DNSmasq config to assign DHCP addresses to both these corresponding ranges
3) change br0 references in /etc/network/firewall.conf to eth1
4) add rules for wlan0 in /etc/network/firewall.conf

Do note that while doing this, eth0 (the WAN interface) is the only static element that you can use to keep access to your B3. You therefore do not want to have any active firewall not allowing you to SSH into the B3 from this side.

[ingo2]

Thanks Gordon!

I did play already a bit with reconfiguring, but it really is a weary and potentially dangerous thing. The situation would be much easier, if I were able to statically configure one interface (preferrable LAN) with an "auto" statement in interfaces as an "always available management port". However this is not possible, because it may be overwritten again by some tool in the B3.

So I will follow your hint and keep fingers off from trying to implement a "guest WLAN" and instead wait für B4. Feature request for "true guest WLAN" has a high score in the poll and hopefully gets implemented - as you said, sepatated completely from the internal LAN and only allowing access to the internet.

The minimum is a complete backup of the system partitition and disk-layout, i.e. with clonezilla, to easily restore a working system just in case.

Many thanks for your good advice and efforts,
Ingo

P.S.: is e-mail notification broken in the forum? I did not receive a single notification on this tread.

[gonk]

I used to have a D-link DIR-655 and then a OpenWRT based device.

Either of these had a feature for guest WLAN so what, technically, stops the B3 from being set up for that purpose?

Isn't it possible to
1) have dual WLAN SSIDs or passwords?
2) if so, based on which the user authenticates via have DHCP provide an IP address from separate range?
3) if so, treat these ranges differently in the firewall rules and routing?

[Gordon]

Yes, all of that is possible. However, from what I read the official ATH driver prohibits running multiple SSID's/vlan's on a single interface. Apparently you can patch the source to build a driver that will support this though.

Of course, using the bridge interface for eth1+wlan0 is to keep the firewall simple. Introducing a third and even fourth interface makes all of this a lot more complicated and that can get messy.

[DanielM]

However, from what I read the official ATH driver prohibits running multiple SSID's/vlan's on a single interface.

Why would they do such a thing?

/Daniel

[Gordon]

You can also not use the top two channels, which happen to be forbidden to use in some countries. My guess about the why for both these limits imposed by the driver software is politics.

[RandomUsername]

Yes, scrict regulatory compliance is also the policy of the developers of hostapd so as to avoid a lot of FUD over using wifi on Linux.