Concept for port reconfiguration

[neocturne]

We currently have some limited features to reconfigure the ports used by Gluon: "mesh-on-wan" is supported for some time, and there are conflicting pull requests for "mesh-on-lan" (freifunk-gluon/packages#63) and "lan+wan bridged" (freifunk-gluon/packages#71).

I propose a more generic approach:

• There are two ports: WAN and LAN. This might be extended to individual LAN ports in the future.
• There are three functions: uplink, mesh, client

It should be possible to assign any combination of functions to any port (with the limitation that the "client" function can't be enabled together with other functions). Enabling the uplink function on two ports will connect these ports with a bridge.

This could also be combined with the WLAN configuration as the three functions mesh, client and uplink directly correspond to the mesh WLAN, client WLAN and private WLAN.

[flokli]

I would go even further:

There are four networks:

• uplink: The existing users' network through which the node should try to connect via fastd
• mesh: Network used for meshing. For each assignment, multiple interfaces would be needed
• client: The freifunk client network
• private-net: a network on which the node runs a dns and dhcp server and masquerades packages to the uplink network. Probably it would also make sense to do some routing into the freifunk network, this needs to be further discussed

Available ports:

• wan: the wan port
• lan: the lan port(s)
• wifi-mesh: the wifi interface used for meshing
• wifi-client: the wifi interface used for client accessing the freifunk network
• wifi-private: the wifi interface used for a private network

It would probably make sense to create these as lists, as on some routers, you could have multiple physical wifi interfaces or are able to address each lan port on its own.

When "connecting" ports and networks together in a "mapping", you can also select a vlan which should be used on the specific port. On the initial boot, the node would create a "default mapping", which would be something like this:

• uplink -> wan, untagged
• mesh -> wifi-mesh, untagged
• client -> lan, untagged
• client -> wifi-client, untagged

Different functions would now look like this:

Mesh on wan: remove uplink -> wan, untagged add mesh -> wan, untagged

Mesh on lan: remove client -> lan, untagged add mesh -> lan, untagged

Mesh on wan (different vlan): remove uplink -> wan, untagged add mesh -> wan, vlan x

lan+wan bridged: remove client -> lan, untagged add uplink -> LAN, untagged

private wifi, bridged with wan: add uplink -> wifi-client, untagged

private network on lan and wifi, natting through uplink: remove client -> lan, untagged add private-net -> lan, untagged add private-net -> wifi-private, untagged

[christf]

it would be great if vlans could be considered as well. in frankfurt there is a quick hack available that makes vlan on wan configurable: https://github.com/freifunk-ffm/packages/tree/master/gluon/gluon-luci-switchconfig

[flokli]

@christf: My suggestion includes vlans ;-)

[christf]

On Sunday 01 March 2015 03:48:01 Florian Klink wrote:

@christf: My suggestion includes vlans ;-) Hatte ich gesehen und finde ich gut. Mir ging es darum, die ersten Schritte, die in dem Paket gemacht wurden zu erwähnen - allerdings ist das Paket ein wilder hack, der abgesehen von vlans nichts von Deinem Konzept umsetzt.

[smoe]

@flokli - I would feel tempted to add a port to allow private WLANs to connect ad hoc as well - "wifi-private-mesh". This would allow the Freifunk routers to act as repeaters of both the Freifunk network ad the private WLAN, which I expect to reduce the Freifunk bandwidth considerably.

[govindadas]

private-net: a network on which the node runs a dns and dhcp server and masquerades packages to the uplink network. Probably it would also make sense to do some routing into the freifunk network, this needs to be further discussed

We could really use this feature, for both WLAN an LAN we need a NATed private Network.

[g3ntleman]

Most needed feature here is "uplink on lan ports" as default as this will prevent any private devices suddenly becoming available to the freifunk network (plugged into lan ports). This happened here with private printers, video streaming boxes (nooo!), etc.

The 2nd most needed scenario is connecting freifunk routers via their lan ports.

The more options, the better. But we'd be happy with the two for now.

[imp1sh]

I would love such a feature. Can I help in some way? I have a sample configuration here which implements such approach. This config is tested with Archer C7 v2. https://github.com/imp1sh/freifunkcp/blob/c7_generic/files/etc/config/network

port 1 (wan): untagged 3 -> WAN port 2 (lan1): untagged 5 -> private port 3 (lan2) -> untagged 11 -> mesh port 4 (lan3) -> untagged 11 -> mesh port 5 (lan4) -> tagged 3,5,11,12 -> WAN, private, mesh, guest

port 4 could easily set e.g. on vlan 12 for guests

[Adorfer]

@flokli i would like to add to the scenario: "private network on lan and wifi, natting through uplink:" "private network on lan and wifi, natting through freifunk"

This may sound silly at first, but since lots of users have embedded devices that can not used with encryption, even on login (webradios, home automation devices, printers, scanners) they can not connected into the wild of the freifunk-layer2 switch. But users want to be inside freifunk with their devices, but having access to their devices too.

Today, by consesquence these users are not in Freifunk but their private Wifi. This is a backdraw for "internal services" in the ICVPN, since lots of sophisticated users don't use Freifunk systematically.

(Next step would be some kind of ssl-proxy tunneling/forwarding for those devices, to make units available at minimim via ICVPN, but certainly not possible for the 4MBflash images.)

[flokli]

@Adorfer I don't think that insecure devices is something that gluon can (or should) try to solve.

Additionally, NAT and firewalling should be treated completely separate.

Missing transport encryption is not fixed by using NAT. Somebody inside the Freifunk Network will still be able to read traffic from and to the device, if it goes over it.

Additionally, this approach won't work with IPv6, which is the future™.

[Adorfer]

@flokli 1) gluon should not solve it insecure device. it should just allow a nat subnet with freifunk-uplink 2) missing transport encryption is fixed by ssh/ssl tunnels, not by NAT (please read my post again) 3) i can not breach SSH. If you and other Freifunkas can, good for you. But then we are all doomed 4) my ssh tunnels work with ipv6. 5) you miss the point. i do not ask for ssh tunnel support on gluon by default, because ssl is not what fits inside 4MB images. I ask for NAT network on Freifunk. In order to able to be in the same Network as unsecure devices, but have still access to freifunk and internal services in ICVPN. Without difficult routing statement:

[tcatm]

For such a private network feature to make any sense it must be a distinct layer 2 segment (=another, smaller subnet) that is part of the larger mesh network with proper layer 3 routing (e.g. OSPF or RIP, no NAT). We do employ such setups in Freifunk Lübeck and it works rather well. This works even if only the default gateways support layer 3 routing as they'll send ICMP redirects to optimize routes. Naturally, this will blend perfectly with future layer 3 mesh protocols.

As far as Freifunk Uplink is concerned (assuming this means internet access) NAT may be employed on the default gateway if necessary.

[Adorfer]

@tcatm the point with unsecure devices is, that you don't want to have them in open networks (open APs). so even a small layer 2 segment "locally" on the node would not help, if the network is public (which "Freifunk" should be by definition). What i would like to have is private network, natting to Freifunk. Or (if somebody does not like the load) natting to br-wan, but having additional a routing (IPv6) and NAT to the networks of bat0. Just in order to be able to access icvpn freifunk-services from the private (Wifi) Network.

[jplitza]

@Adorfer You are missing the point that @tcatm was talking about: NAT is not necessary to do precisely that. If your node acts as a proper Layer 3 router between Freifunk (br-client) and your private network (br-wan), and by some means tells the gateways about your private network being accessible through it, you do not need NAT to access Freifunk services from every device in your private network.

To put it in simple terms, NAT is a hack. Always. There are always cleaner solutions than NAT, and we only want clean solutions in Gluon. If we cannot do it right, we don't do it at all.

[tcatm]

@Adorfer Well, both layer 2 segments (Freifunk and private lan) would be connected by the freifunk router. This router can (and probably should) have a sensible firewall configuration. E.g. no incoming traffic by default if it's not part of an established connection, just like most Fritzboxes handle it. There really is no need for NAT in this case.

[maurerle]

Fixed by #2688