Dumb AP with WAN

Hi,

I have an AR300M that I want to use as a "dumb AP" for my NanoPi, as the NanoPi doesn't have build in WiFi and many recommendations in this forum point away from using USB WiFi adapters.

I started playing around and followed the guide in the wiki (https://openwrt.org/docs/guide-user/network/wifi/wifiextenders/bridgedap#configuration_via_luci) to set up AR300M as a dumb access point.

AR300M and NanoPi now are connected via each others LAN ports and DHCP is working.

However, the NanoPi does not know how to route properly yet, as the wiki guide is assuming, NanoPi would provide internet via its WAN port which is not the case in my setup, as this is handled by AR300M's radio as well. I do not know how to configure this properly, also in perspective of security. I don't know the consequences of bridging br-lan and wan how it is described in the wiki article.

My configs currently look like this:

AR300M (its was a bit preconfigured by the official firmware from glinet):

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

config globals 'globals'
        option ula_prefix 'fd4f:4612:88ea::/48'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'eth0'
        list ports 'eth1'

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option isolate '0'
        option ipaddr '192.168.8.2'
        option gateway '192.168.8.1'
        list dns '192.168.8.1'

config interface 'wan'
        option device 'eth0'
        option proto 'dhcp'
        option force_link '0'
        option ipv6 '0'
        option classlessroute '0'

config interface 'wan6'
        option proto 'dhcpv6'
        option disabled '1'
        option device '@wan'

config rule 'policy_relay_lo_rt_lan'
        option lookup '16800'
        option in 'loopback'
        option priority '1'

config interface 'tethering6'
        option proto 'dhcpv6'
        option disabled '1'
        option device '@tethering'

config interface 'wwan6'
        option proto 'dhcpv6'
        option disabled '1'
        option device '@wwan'

config interface 'guest'
        option force_link '1'
        option type 'bridge'
        option proto 'static'
        option ipaddr '192.168.9.1'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option multicast_querier '1'
        option igmp_snooping '0'
        option isolate '0'
        option bridge_empty '1'
        option disabled '1'

config interface 'wwan'
        option proto 'dhcp'
        option classlessroute '0'
        option metric '20'

config interface 'modem_1_1_2_6'
        option proto 'dhcpv6'
        option disabled '1'
        option device '@modem_1_1_2'

config rule 'policy_direct_rt'
        option lookup 'main'
        option suppress_prefixlength '0'
        option priority '1100'

config rule 'policy_default_rt_vpn'
        option mark '0x8000/0xc000'
        option lookup '8000'
        option priority '1101'
        option invert '1'

config rule6 'policy_direct_rt6'
        option lookup 'main'
        option suppress_prefixlength '0'
        option priority '1100'

config rule6 'policy_default_rt_vpn6'
        option mark '0x8000/0xc000'
        option lookup '8000'
        option priority '1101'
        option invert '1'

NanoPi:

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

config globals 'globals'
        option ula_prefix 'fd04:c2c0:b3a2::/48'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'eth1'

config device
        option name 'eth1'
        option macaddr '82:34:28:78:c6:79'

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option ipaddr '192.168.8.1'
        option netmask '255.255.255.0'
        option ip6assign '60'

config device
        option name 'eth0'
        option macaddr '80:34:28:78:c6:79'

config interface 'wan'
        option device 'eth0'
        option proto 'dhcp'

config interface 'wan6'
        option device 'eth0'
        option proto 'dhcpv6'

Unfortunatly its last version that shows up is EOL

But since it is just going to be dumb you can flash it to official OpenWrt and, maybe, add packages for WPA3.

Ups, that is a bit confusing, the AR300M which I am talking about is an entirely different device (https://openwrt.org/toh/gl.inet/gl-ar300m), it has OpenWrt 22.03.4 running. I just fixed it in the post.

I also tried to play around with the configuration a bit and had some success when setting the gateway on the NanoPi back to the AR300M. However, with that configuration I could not get the DNS up running, not sure if that is the right way tho.

What is it running?

ubus call system board

I see this

But I'm confused.

{
        "kernel": "5.10.176",
        "hostname": "GL-AR300M",
        "system": "Qualcomm Atheros QCA9533 ver 2 rev 0",
        "model": "GL.iNet GL-AR300M (NOR)",
        "board_name": "glinet,gl-ar300m-nor",
        "rootfs_type": "squashfs",
        "release": {
                "distribution": "OpenWrt",
                "version": "22.03.4",
                "revision": "r20123-38ccc47687",
                "target": "ath79/nand",
                "description": "OpenWrt 22.03.4 r20123-38ccc47687"
        }
}

I use the officially (most recent) distributed Firmware from glinet, they build kind of another handy UI in addition to luci that makes it easy and quick to sign into captive portals and stuff. I kinda like that, but if it is getting into the way I will consider to go with the official and most recent OpenWrt build.

Dumb AP Setup:

Device 1: br-wan (wan logical interface)
eth0.vlan
eth1.vlan
(whatever vlan you want or your ISP requires).

Device 2: eth1 (lan logical interface)
(no vlan required)

Physical connections:
Connect eth0 to your modem or whatever device your ISP provides/you use.
Connect eth1 to NanoPi R4S eth0/wan port.

NanoPi Setup:

Device 1: eth0.vlan (wan logical interface)
Same vlan as you're using in the Dumb AP
Device 2: eth0 (lan logical interface)

eth0.vlan will be your logical wan interface.
eth0 will be your logical lan interface.

Make sure to set proper firewall zones for lan and wan.

NanoPi R4S eth1 will be free in this setup, you'll use dumb ap to bypass wan connection from ISP to NanoPi through a VLAN.

You have choices:

Update to the most recent, offical, OpenWrt build and learn Travelmate (not one click like GL.iNet) or ask GL.iNet for support.

Or, if @RHBH wants to try to wander through GL.iNet's firmware...

Well they just put an UI on top of standard openwrt to make standard use cases of a travel router more convenient. Under the hood there is running a normal OpenWrt installation.

@RHBH thanks! I will try to figure out how to do VLAN configurations and give this a try.

Just a note, if your ISP doesn't allow VLAN connections in the wan link (dhcp, pppoe..)

You can instead use VLAN for your LAN interfaces and leave WAN interfaces without VLAN.

You just need to set VLAN in one of them to make sure they are isolated at the link layer as they'll be using the same physical cable between the AP and NanoPi.

I plan to use the router while traveling, so i can not rely on consistent ISP scenarios.

I enabled VLAN using vlan_filtering='1' on br-lan, for some reasons the other devices look disabled/greyed out for some reasons. The AR300M is connected to the internet via WiFi which should be the WWAN interface. I checked with the diagnostic tools and confirmed I can ping the internet and resolve names.

But I still think the NanoPi doesn't know where to route outgoing connections to.

Edit:

I checked the routing tables on the NanoPi and found out there was no rule besides the local subnet. Since I only use LAN I tried to configure routing things back using 0.0.0.0 to the AR300M but without success...

No one has a problem with you and anyone else having a go at it with OEM GL.iNet firmware; we may learn something about it.

But that statement cannot stand, in a thread; it will cause confusion and must be challenged.

We don't work on it because we do not know what they did to it; they run a closed fork of OpenWrt.
Since OpenWrt has nothing to do with GL.iNet's fork, do not complain about any deficiencies you may find or vulnerabilities already patched.

Do not be surprised if you are told to get a room (go PM) or any other push back.

1 Like

Based on your topology, your AR300M must do the routing for the internet connection. The wwan connection cannot be bridged through to the Ethernet port for the routing to occur on the NanoPi.

So with that in mind, what is the NanoPi for? What purpose does it serve in this topology?

I often travel around and used the AR300M to connect to various public hotspots like hotels/cafes. Then I would tunnel all traffic through a Wireguard VPN (mainly for privacy) directly with the AR300M. So my connected devices (phone/notebook) are instantly protected without additional apps/configurations.

However the AR300M is pretty limited processor wise, which is becoming a bottleneck for VPN encryption. So I got the NanoPi (which has a powerful processor + 4GB of ram) pretty cheap from eBay, and got the idea to offload Wireguard on this device + eventually make use of the docker capabilities to make some docker services available to my local network.

@LilRedDog Thank you for the explanation. I get it. I had the naive idea in front of my eyes it would be just a small config to set somewhere, since the "dumb AP" wiki guide already seemed to put me far in progress. I understand now that the GL.iNet firmware probably contains unknown code.

Based on that, your AR300M has a wwan and a lan. Since the NanoPi is just a mini server in your environment, just make it another host on the lan. That means that you'll simply configure the NanoPi's lan interface to be part of the AR300M's lan subnet (if necessary, complete with the gateway and DNS which will be the address of the AR300M) and connect the AR300M's lan port to the NanoPi's lan port. Done... simple. No other configs necessary.

Aha okay, thank you! I get it. So the only thing that will be a bit tricky (for me) then is to route the traffic through the NanoPi.

I did reset both devices to factory and did the following changes:

NanoPi:
lan:

  • IP to 192.168.8.2 (to match subnet of ARM300M)
  • Disable DHCP
  • DNS to 192.168.8.1
  • Gateway to 192.168.8.1

(Diagnostics OK, can ping test domain)

AR300M:
lan:

  • Gateway to 192.168.8.2 (to route traffic over NanoPi for VPN) ???

Now NanoPi is part of AR300M's subnet and I can access luci through my notebook conencted to AR300M. NanoPi can also reach internet. However, the traffic from my notebook is not routed through the NanoPi, where the VPN encryption will later happen.

The routing table on AR300M looks like this:

How do I need to configure the routing through NanoPi, so I can apply my VPN?

The configuration to achieve what you want will be quite complicated, and because you are using the gl-inet firmware, you need to either ask for help on their support channels or install official openwrt.

The fact is that this is a bad architecture. Instead, you should get a new travel router with wifi. An excellent option is the gl-mt3000 which will do everything you want.

1 Like

It's a pain too if the picture is correct because if the internet is provided by wifi there's no simple way to bridge it through to the nano pi. The wifi standard/linux implementation just doesn't allow you to bridge a client connection.

Also i'm not sure exactly how the dual use of the wifi will work for you there (feel free to correct me someone) , I'm not sure how it's going to work if you connect via the 5ghz band and also want to provide a AP on the 5ghz band on one radio.

And all on top of the router being out of scope of support here :smile:

Honestly I think the first thing I probably would do, if your internet is provided via standard wifi is to get a usb adapter if you can afford it. Still use the router you have as an AP but don't use it to tunnel the internet.

I see what you are trying to do with the devices you have, at hand, but it is backwards

as has been put:

The NanoPi should be up front and a client for internet.
(what NanoPi do you have? This? And you need to figure out the radio issue (because as @hebert points out) one radio, one service.)
Then set the AR300M up as a dumb ap.

I'm going to be honest, even if you went official it would take effort to run it the way you have it, physically, set up.