OpenWrt as a Subnet

I'm trying to configure an OpenWRT router to isolate a cluster of minicomputers from my home network: Access beyond the firewall is to be on a need to have basis. I know about rejecting packets by default, but I can't find where to punch pinpoint holes in a firewall configured using firewall zones.

I don't even think I've gotten my router pointed at my default gateway. (Pi 4, community build)

Which firewall (this depends on where the OpenWrt device is in relation to the home network)?

Traffic Rules

???

So you have no Internet connection?

2 Likes

The zones are a convenient way of allowing traffic in bulk. The default configuration is this:

  • Everything behind the firewall is allowed outbound
  • Nothing is allowed inbound.

If you want to allow specific inbound traffic, set it up as a port forward. If you leave the port and protocol empty, then all traffic which matches the source and/or destination IP address will be permitted. If you populate the port and protocol, the rule will also limit traffic by that port and protocol.

1 Like

This depends on how the OP configured the device, otherwise:

2 Likes

Barring getting a second Ethernet socket working (USB3), OpenWRT will be connecting to the home router over Wi-Fi (and Internet access when allowed). I want to whitelist what IP's these subnetted computers can access.

And no, I don't have an Internet connection. I've connected to my Wi-Fi, but the only IP's ip a is giving me are either loopback or self-assigned as router.

@iplaywithtoys

If you populate the port and protocol, the rule will also limit traffic by that port and protocol.

I think I followed you until that last bit there. I've twisted Raspian into a similar project before, but firewall configuration eluded me then as it does now.

By default, OpenWRT bridges the LAN and WiFi interfaces to share the same layer 2 domain. If your WAN connection is WiFi and you want to set it up as a router (segregating two separate subnets), you'll need to sever the LAN/WiFi bridge and remove the default WiFi access point configuration before attempting to set OpenWRT up as a WiFi client.

For example, here's the default configuration from a VoCore VoCore2 (single NIC + WiFi + USB, not dissimilar to a Raspberry Pi in terms of connectivity):

root@OpenWrt:/etc/config# cat network

config interface 'loopback'
        option ifname 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fd2b:30ee:54cb::/48'

config interface 'lan'
        option type 'bridge'
        option ifname 'eth0.1'
        option proto 'static'
        option ipaddr '192.168.1.1'
        option netmask '255.255.255.0'
        option ip6assign '60'

config device 'lan_eth0_1_dev'
        option name 'eth0.1'
        option macaddr 'b8:d8:12:67:1f:57'

config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '1'

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option ports '0 2 6t'

And here's the default wireless configuration:

root@OpenWrt:/etc/config# cat wireless

config wifi-device 'radio0'
        option type 'mac80211'
        option channel '11'
        option hwmode '11g'
        option path 'platform/10300000.wmac'
        option htmode 'HT20'
        option disabled '1'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option ssid 'OpenWrt'
        option encryption 'none'

As you can see, there's no WAN connection defined... yet.

Here's what it looks like with the bridge severed and the WiFi repurposed as a WiFi client for the WAN interface.

First, the network:

root@OpenWrt:/etc/config# cat network

config interface 'loopback'
        option ifname 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fd2b:30ee:54cb::/48'

config interface 'lan'
        option ifname 'eth0.1'
        option proto 'static'
        option ipaddr '192.168.1.1'
        option netmask '255.255.255.0'
        option ip6assign '60'

config device 'lan_eth0_1_dev'
        option name 'eth0.1'
        option macaddr 'b8:d8:12:67:1f:57'

config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '1'

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option ports '0 2 6t'

config interface 'wwan'
        option proto 'dhcp'

See the removal of the "bridge" directive. Also see the new "wwan" entry at the bottom. In this instance, it's set as a DHCP client.

Next the wireless:

root@OpenWrt:/etc/config# cat wireless

config wifi-device 'radio0'
        option type 'mac80211'
        option channel '11'
        option hwmode '11g'
        option path 'platform/10300000.wmac'
        option htmode 'HT20'

config wifi-iface 'wifinet0'
        option ssid '<insert ssid here>'
        option device 'radio0'
        option mode 'sta'
        option key '<insert passphrase here>'
        option network 'wwan'
        option encryption 'psk2'

During the creation of the WiFi client interface "wwan", it was assigned to the "wan" firewall zone, turning the device into a two-subnet router with a firewall.

2 Likes

I've already done a bunch of poking about. I found a check box under Network > Interfaces > LAN called Brige interfaces and disabled it. Interface is set to Eth0.

...ip a isn't showing br-lan anymore. Instead, Eth1 is showing up now, so that's working as expected.

WWAN is set up as a different Interface, but it appears to be down. ip a and a red name bar in LuCi.
Restarting the interface doesn't appear to do anything.

See my previous - now edited - reply for examples of default configuration versus modified configuration.

If I'm understanding what I'm looking at correctly, I need to remove and not just disable the entry configured as Master? (SSID: ap101)

I don't know, but my standard approach is to remove stuff if it isn't needed; it helps to keep the configuration tidy. And if you're not using the Pi as an access point, then any configuration relating to an access point is superfluous.

The best test is to suck it and see. Does it work if you disable that bit of the configuration? Does it work if you remove that bit of the configuration?

1 Like

Doesn't look like removing did anything different. Should WWAN be using Protocol: DHCP client?

FYI... there may or may not be a bug at the moment with wifi persistence on this device... (and others -> flyspray)

I was messing with something else and iwinfo kept dumping old config / wifi interfaces that had been totally removed from config...

1 Like

That depends entirely on your network configuration. In my case, the AP that I used dishes out IP addresses via DHCP; I didn't need to configure OpenWRT with static details for that example.

Wouldn't be the first time I came across an upstream bug.

I'll be connecting directly to an otherwise unremarcable wireless router in my case.

yeah I agree with @iplaywithtoys ... just comment out the 'ap' section... ( on these devices especially you only really want one logic section on the radio )...

fwiw... I tried travelmate once on this device and failed... ( had succeeded before on ipq806x 6 months ago )... so imho... you really have to break everything down into tiny clear config sections to get anything done... as the wifi on these can be really fussy...

( even better test the 'config' on a spare device so that you know you understand the basics before attempting on the pi )

I haven't set so many settings I'd be in trouble with myself for needing to start over with a fresh install, and if need be, I can fall back to my Pi 3B+ for this project or scrap the cluster idea again until a more stable build comes out.

At the moment though, I'd call it a win for the day to log into the web UI/SSH from the home network.

I've now set Wi-Fi to US instead of World. Network still unreachable...

Looking at my generated config files, they appear very similar to the second set you provided. I don't have a few interfaces you have, but option path is a lot longer.


root@QChrysalisOpenWRT /44# cat /etc/config/network

config interface 'loopback'
        option ifname 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fd1e:6fc5:1266::/48'

config interface 'lan'
        option ifname 'eth0'
        option proto 'static'
        option ipaddr '192.168.1.1'
        option netmask '255.255.255.0'
        option ip6assign '60'

config interface 'wwan'
        option proto 'dhcp'

root@QChrysalisOpenWRT /43# cat /etc/config/wireless 

config wifi-device 'radio0'
        option type 'mac80211'
        option channel '36'
        option hwmode '11a'
        option path 'platform/soc/fe300000.mmcnr/mmc_host/mmc1/mmc1:0001/mmc1:0001:1'
        option htmode 'VHT40'
        option noscan '1'
        option cell_density '0'
        option country 'US'

config wifi-iface 'wifinet1'
        option device 'radio0'
        option mode 'sta'
        option network 'wwan'
        option ssid '<SSID>'
        option encryption 'psk2'
        option key '<PASSKEY>'
        option wds '1'

Does anything look terribly off?

comment those out...

set that to 20 in the gui... ( initially... 40 should probably be ok for sta... but 20 is a safer bet starting out )

you probably want channel auto... also...

not too sure why you want wds... ? but i've only skimmed the thread...