Unable to connect to outside internet with Dumb AP coniguration

Installing and Using OpenWrt Network and Wireless Configuration
1

Hey all, just got a pfSense router configured for my whole house, but as we already had a Belkin RT3200 with OpenWRT flashed I figured I'd reuse it as an AP. pfSense is configured on the LAN side with an Intel I350-T4 with all four ports in a network bridge (we have no switch currently, we're going to be getting one but for now we had no explicit need for one). The RT3200 is plugged into this card and therein the LAN Bridge, alongside all other LAN devices.

I followed the Dummy Access Point configuration guide. Connecting devices to the AP's LAN switch ports works fine, however, Wi-Fi devices will connect to the AP and be assigned an IP but be unable to connect to WAN. Pinging devices on the internal network works fine, but are unable to make connections outside of the LAN, e.g. pinging 8.8.8.8 or 1.1.1.1 or google.com. Also, notably, Wi-Fi devices are DHCP assigned IP's ranging upwards from 100 where pfSense has been assigning from its given range of 2-254 for LAN devices on this subnet. DHCP and Firewall are also disabled on boot.

Here's my /etc/config/network

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 'fdfe:4230:b79e::/48'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'lan1'
        list ports 'lan2'
        list ports 'lan3'
        list ports 'lan4'

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option ip6assign '60'
        option netmask '255.255.255.0'
        option gateway '192.168.200.1'
        list dns '1.1.1.1'
        list dns '8.8.8.8'
        option ipaddr '192.168.200.254/24'
        option broadcast '192.168.200.255'

and /etc/config/wireless, though you'll notice these are all set to defaults as nothing is working yet

config wifi-device 'radio0'
        option type 'mac80211'
        option path 'platform/18000000.wmac'
        option channel '1'
        option band '2g'
        option htmode 'HT20'

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

config wifi-device 'radio1'
        option type 'mac80211'
        option path '1a143000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0'
        option channel '36'
        option band '5g'
        option htmode 'HE80'
        option disabled '1'

config wifi-iface 'default_radio1'
        option device 'radio1'
        option network 'lan'
        option mode 'ap'
        option ssid 'OpenWrt'
        option encryption 'none'

Settings for devices plugged into the router's switch are identical to when it's connected wirelessly as far as I can tell, yet while wired is fine, wireless refuses to communicate with the outside internet. I cannot figure out what configuration step I'm missing here to make this work as plenty of other people with near identical network config files and devices have made it work. Android devices outright refuse to connect and rapidly connect and disconnect until you ask it to forget the AP. I'm new to pfSense so it may be a problem to instead bring to their forums but I'm just trying to cover my bases for the time being

2

Looks weird.

What default dns and gw IPs are the devices getting?

3

the default DNS and Gateways are both that of the pfSense router, 192.168.200.1 which is also consistent with how other devices interact on that LAN (hooked up directly on LAN, not on the AP)

4

First plug a laptop directly into the port on pfsense that you're going to use and confirm that it gets an IP as expected and can reach the Internet. If not, there is something wrong in the pfsense configuration.

Evidence suggests otherwise. Edit /etc/config/dhcp so the only thing set on lan is an option ignore 1 (like wan has). The firewall doesn't do anything in a dumb AP since there is only one network and it is a layer 2 bridge.

When you use CIDR notation (192.168.200.254/24) netmask and broadcast are set automatically, so remove those lines. Setting a DNS in the dumb AP only affects how the kernel does DNS for internal purposes like NTP-- the wifi clients will bypass that and use what the main router does. When a wifi client connects to the dumb AP, its DHCP request is passed to the main router and answered there, the client will use the gateway and DNS addresses that the main router pushes to it.

5

This combination doesn't look healthy, as you're already setting the netmask, stick to plain option ipaddr '192.168.200.254'.

It's an AP, not a router, so no own ULA to announce either, the same goes for ip6assign, just drop it for now (easier to leave out IPv6 in step 1, before you have confirmed that everything is working on IPv6, and then re-adding it in optimization step 2) and make very sure that DHCP/ dnsmasq and DHCPv6/ odhpcd are disabled in /etc/config/dhcp.

I know that there are different schools of static vs dynamic IP assignments for infrastructure devices, personally I prefer giving everything (really everything), apart from the router itself, only dynamic IP addresses (based on static DHCP leases assigned by the router).

Also check/ paste /etc/config/dhcp carefully.

6

I've tested this and all ports (especially one the AP is in) work as intended

Went ahead and made sure that was changed, OpenWRT had reverted to this already

Dropped those from my configuration

For the time being until I can create a separate VLAN for devices I want to be managed separately, everything is going to be dynamic, this isn't a problem for now.

I've disabled these services twice over, first by disabling them via /etc/init.d/[service] disable and disabling them in System -> Startup. I'm new to the configuration files here, so I'll paste the output of /etc/config/dhcp here, including the suggested change from mk24:

config dnsmasq
        option domainneeded '1'
        option boguspriv '1'
        option filterwin2k '0'
        option localise_queries '1'
        option rebind_protection '1'
        option rebind_localhost '1'
        option local '/lan/'
        option domain 'lan'
        option expandhosts '1'
        option nonegcache '0'
        option authoritative '1'
        option readethers '1'
        option leasefile '/tmp/dhcp.leases'
        option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
        option nonwildcard '1'
        option localservice '1'
        option ednspacket_max '1232'

config dhcp 'lan'
        option ignore '1'

config odhcpd 'odhcpd'
        option maindhcp '0'
        option leasefile '/tmp/hosts/odhcpd'
        option leasetrigger '/usr/sbin/odhcpd-update'
        option loglevel '4'

Also, to note, after making these changes and rebooting the router I still cannot get an internet connection over Wi-Fi

7

Since a dumb AP is nominally a very simple configuration, I would recommend that you reset this unit to defaults and then setup the dumb AP using the guide. It should take probably 5 minutes to do this and will ensure that you have what is nominally a valid and known good configuration as the starting point.

You should only need to do the following things:

  • Turn off the DHCP server on lan (set to ignore interface)
  • Set your LAN IP to an unused address in the same subnet as your main network (also avoiding the DHCP pool)
  • (optionally add the gateway and DNS to the lan interface... this isn't strictly necessary unless the dumb AP itself needs to have internet access)
  • set your SSID, password, and country in the wifi settings, and then enable the wifi.
  • connect a cable between the main network LAN and your dumb AP's LAN port.
1 Like
8

hey there, I linked that guide in the post here. I followed the text portion word for word (there were some inconsistencies in the configuration files via the command line route that I don't know enough to remedy, as apparent here) and was left with this result. I did it again just now and have achieved the same result, in fact I can't seem to connect to the AP at all so I'll have to perform a hardware reset and start over. Any advice you might have for the configurations I've posted would be greatly appreciated, thanks!

9

Well, take each step one at a time. You don’t have to follow the guide if there are inconsistencies or ti don’t understand the syntax or recommendations.

Instead, follow the billets I provided above. You can do this however is most comfortable for you: with the web interface, directly editing the config files, or using the uci syntax.

10

I did the steps step by step and ended up with the same results, in both the web interface, uci syntax, and editing the files directly. This time in particular I've gone the route of doing it via ssh. I'll put my new config files here:

[/etc/config/network]
config interface 'loopback'
        option device 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'lan1'
        list ports 'lan2'
        list ports 'lan3'
        list ports 'lan4'

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option ipaddr '192.168.200.254'
        option netmask '255.255.255.0'
        option gateway '192.168.200.1'
        option broadcast '192.168.200.255'
        list dns '8.8.8.8'

[/etc/config/wireless]
config wifi-device 'radio0'
        option type 'mac80211'
        option path 'platform/18000000.wmac'
        option channel '1'
        option band '2g'
        option htmode 'HT20'
        option disabled '0'
        option country 'US'
        option cell_density '0'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option ssid 'OpenWrt TEST'
        option encryption 'none'
[Radio 1 omitted as we're just testing on 2.4GHz until this works]

[/etc/config/dhcp]
config dnsmasq
        option domainneeded '1'
        option boguspriv '1'
        option filterwin2k '0'
        option localise_queries '1'
        option rebind_protection '1'
        option rebind_localhost '1'
        option local '/lan/'
        option domain 'lan'
        option expandhosts '1'
        option nonegcache '0'
        option authoritative '1'
        option readethers '1'
        option leasefile '/tmp/dhcp.leases'
        option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
        option nonwildcard '1'
        option localservice '1'
        option ednspacket_max '1232'

config dhcp 'lan'
        option interface 'lan'
        option start '100'
        option limit '150'
        option leasetime '12h'
        option dhcpv4 'server'
        option ra_slaac '1'
        list ra_flags 'managed-config'
        list ra_flags 'other-config'
        option ignore '1'
        option dhcpv6 'disabled'
        option ra 'disabled'

config dhcp 'wan'
        option interface 'wan'
        option ignore '1'

config odhcpd 'odhcpd'
        option maindhcp '0'
        option leasefile '/tmp/hosts/odhcpd'
        option leasetrigger '/usr/sbin/odhcpd-update'
        option loglevel '4'

[Commands run]
[Yes, there is redundancy here, I just wanted to cover all of my bases]

uci set dhcp.lan.ignore=1
uci commit dhcp
/etc/init.d/dnsmasq disable

uci set dhcp.lan.dhcpv6=disabled
uci set dhcp.lan.ra=disabled
uci commit
/etc/init.d/odhcpd disable

/etc/init.d/firewall disable

[Rebooted AP]

Still, Wi-Fi devices will not connect to the internet. They do get DHCP leases from the pfSense router and they do access other devices on the network yet do not access the internet. Also, devices plugged into the switch port on the router do (as expected) connect to the internet and grab their DHCP leases as expected.
To sanity check I configured my very old dd-wrt router in a similar access point configuration and plugged it into the LAN, and noticed that devices connected could connect to the internet and also still grabbed IP addresses in the 100+ range of this subnet.
Finally, DHCP has been modified to exclude a range of addresses to allow for static IPs of the routers temporarily, so no overlap conditions will exist.

Thank you all again for your help, I really do appreciate your time, patience, and feedback as I try to get this working, I'm learning a lot

11

Remove everything except ignore means ending up with this:

config dhcp 'lan'
    option interface 'lan'
    option ignore '1'

The option interface has to stay so it knows which interface to ignore. At least change dhcpv4 to disabled, since leaving it in is a conflict with ignore.

12

Try removing broadcast from the lan interface definition. It is not required and is actually auto generated based on the IP address and subnet mask. (the value you have is correct, and it shouldn't cause problems, but still not necessary and recommend removing just in case).

What do your wifi clients get as their router/gateway address via DHCP?

Have you tried an outbound ping test on the wifi clients?

  • 192.168.200.254 (AP)
  • 192.168.200.1 (router/gateway)
  • 8.8.8.8 (google DNS server by IP)
  • google.com (direct ping with a domain name)
13

Can confirm the same issue with the Belkin RT3200 on my side on a similar network setup.

I'm using an OPNSense firewall device with two dumb APs (Netgear WNDR3800 and ZyXEL NBG6817) without any issue so far. OpenWRT is up to date on all devices.

Adding the RT3200 as dumb AP to the setup, no wireless traffic is being forwarded to the lan bridge. Traffic via ethernet ports is working without any noticable issue.

I've noticed that the old devices make use of an ethernet switch, configurable in the network tab. Whereas the RT3200 is using dedicated LAN switch Ports (lan1-lan4) and has no such configuration tab in luci. I'm in the process of understanding the DSA approach regarding switch configuration and the DSA conversion guide

Maybe this hint helps to find a solution to this issue.

14

Glad I'm not going crazy, thank you for the sanity check! I did notice that when I'm connected to the RT3200 wirelessly I can still communicate with other devices on LAN that aren't connected to the RT3200 or the built-in switch/LANs. What would that imply for Wireless internet access?

15

So... I'm not insane. Seems to be the only thread about pfSense/OPNsense and Linksys E8450/Belkin RT3200 setup issues. This took me ~8 days to troubleshoot this issue - trying to set up a dumb AP on a recently bought Linksys E8450 router behind an OPNsense 21.1.9 firewall build with a bridged LAN setup (OPNsense firmware to be soon updated next month).

--

Symptoms:

  • Linksys E8450 directly connected to the OPNsense box would take over a minute to connect to the Internet. Though, the worst was ~10 minutes when connected to an older router served a Wireless Ethernet Bridge, lol. Cannot exactly install packages through the web, yet machines connected to the Linksys E8450 switch are perfectly fine. Bonus: even through the router served as a Wireless Ethernet Bridge.
    • unless I installed the ip-full package through opkg and manually added ip neigh replace 192.168.1.1 lladdr '00:11:22:33:44:55' nud permanent dev br-lan to /etc/rc.local!
  • Windows WLAN clients would authenticate, grab an IP address, but not connect to the Internet.
    • Manually added the OPNsense MAC address via Powershell to my main Windows laptop as a test. Now I have an Internet connection on that Windows laptop.
      • Get-NetAdapter
      • NewNetNeighbor -InterfaceIndex [num] -IPAddress '192.168.1.1' -LinkLayerAddress '001122334455' -State Permanent
      • Get-NetNeighbor -InterfaceIndex [num] -IPAddress 192.168.1.1
  • Linux WLAN clients would generally authenticate, but would take up to 5 minutes to connect to the Internet. Least problematic.
  • Android WLAN clients are odd.
    • My current phone (Motorola G Stylus 2022) would rapidly connect then disconnect, then it would eventually say Connected and stay there. After that, I have Internet access. This would go on for up to about 15 minutes, average.
    • Have an old Motorola Atrix HD phone that would authenticate (though I had to deselect Avoid poor connections to troubleshoot), but very rarely establish a connection to the Internet.
    • An RCA phone (cannot exactly remember the model, likely G2) was relatively fine, however, though it took up to a minute to connect to the Internet.
    • Mom's OnePlus 7 Pro would rapidly connect, disconnect, then fall back to the primary 5GHz WLAN SSID in the house.

I was originally running 22.03.2 when I first set it up, then 22.03.3, looked over my configuration multiple times, troubleshot the setup, then a snapshot version (Jan 6, Jan 7), then back to 22.03.3. More configuration checks. More troubleshooting.

--

Some notes:

  • Weird quirk when leaving DHCP on (ignore interface unchecked, Dynamic DHCP checked) eventually has DHCP WLAN clients grabbing the OpenWrt router's IP as gateway and DNS, despite the fact you set the gateway and DNS to your main firewall's IP address. Yes, the Internet works in that state for those WLAN clients as well.
    • Disabling DHCP and setting gateway and DNS to your pfSense/OPNsense firewall's IP address, however, results in practially non-functional Internet access for WLAN clients.
  • If you're wondering if static IP WLAN clients receive Internet access, then you would be wrong. My main Windows laptop is actually set as a static IP and even it needed the NetNeighbor workaround.
  • Hooked up my main Windows laptop to the Linksys E8450 via Ethernet and ran Wireshark. That's when I discovered the WLAN clients weren't exactly getting the OPNsense firewall's ARP responses, but the OPNsense firewall was getting theirs.

Then, I searched for the earliest version available on the OpenWrt downloads server... I installed OpenWrt 22.03.0-rc1 and everything worked well from there. Removed the workarounds from the OpenWrt router and my main Windows laptop after that. Wondering when it first stopped working for this setup, I installed 22.03.0-rc4 on the router... welp, dumb AP setup doesn't work on that version, either, so I rolled it back to rc1.

Running very well on 22.03.0-rc1 for 3.5 days now. Am planning to buy a second one, as I already deployed a third of the wireless network to the E8450 for a testing phase, so no further troubleshooting from me until then.

16

I return; this edge case (issue) actually seems to have been introduced in OpenWrt 22.03.0-rc2 rather than rc4 for this router and pfSense/OPNsense setup!

I had to compile that particular release candidate (for obvious reasons) just for testing purposes.

Eventually obtained a Belkin RT3200 router that is to serve as a wireless bridge to the Linksys E8450 I obtained even earlier. Converted to UBI layout, flashed 22.03.3, set it up just like the Linksys E8450 dumb AP setup that has been running for 12 days (would've been 16 days, but I relocated it to the main area). Of course, same issues persist as in my previous post. Then flashed 22.03.0-rc1 to the Belkin unit, and the dumb AP setup works as intended.

But...

Backstory of Linksys WRT54G-TM

I also have an old Linksys WRT54G-TM router that I got off eBay years ago that was specified to be in bricked condition due to a bad flash (thankfully the CFE was still present), and brought it back to life via JTAG. After that, I ran an old build of DD-WRT just for the SD card mod, then a custom build of TomatoUSB for the same reason. Eventually ran FreshTomato on it to have old Nintendo DS consoles connect to WAN because the SD card novelty wore off.

Back in December 2021, I flashed OpenWrt 21.02.1 on the router, went, "Yeah, that's a bit slow..." messed with it for a bit anyway, and set it aside until December 2022, for which I flashed 22.03.2 on it, then set it aside again. On January 2023, I finally flashed 22.03.3 on the ancient Linksys WRT54G-TM router... and set it aside again.

Today, I finally set it up as a dumb AP with the same settings as my Linksys E8450 and Belkin RT3200 routers, and it works flawlessly (though slow, shocker). Basically, the WRT54G-TM part pretty much adds to martinlauer's statement that other dumb AP setups are working fine with OPNsense.

I also have a somewhat older Netgear R7000 running as an AP, but-- that runs FreshTomato, and it was going to be replaced with the Linksys E8450... and repurposed as a backup router.

--

The configuration is as follows (not entirely cleaned up yet; WDS enabled for Linksys E8450 only):

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

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'lan1'
	list ports 'lan2'
	list ports 'lan3'
	list ports 'lan4'
	list ports 'wan'

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option netmask '255.255.255.0'
	option ipaddr '192.168.1.5'
	option gateway '192.168.1.1'
	list dns '192.168.1.1'
	option delegate '0'

config interface 'lan6'
	option proto 'dhcpv6'
	option force_link '1'
	option reqaddress 'try'
	option device '@lan'
	option reqprefix 'no'
/etc/config/wireless 
config wifi-device 'radio0'
	option type 'mac80211'
	option path 'platform/18000000.wmac'
	option band '2g'
	option cell_density '0'
	option country 'US'
	option htmode 'HT40'
	option channel 'auto'

config wifi-iface 'default_radio0'
	option device 'radio0'
	option network 'lan'
	option mode 'ap'
	option ssid 'OpenWrt-2G'
	option encryption 'psk2+ccmp'
	option key 'wpa2pass'

config wifi-device 'radio1'
	option type 'mac80211'
	option path '1a143000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0'
	option band '5g'
	option htmode 'HE80'
	option cell_density '0'
	option country 'US'
	option channel '153'
	option he_su_beamformee '1'
	option he_bss_color '8'

config wifi-iface 'default_radio1'
	option device 'radio1'
	option network 'lan'
	option mode 'ap'
	option ssid 'OpenWrt-5G'
	option encryption 'psk2+ccmp'
	option key 'wpa2pass'
	option wds '1'
/etc/config/dhcp 
config dnsmasq
	option localise_queries '1'
	option expandhosts '1'
	option readethers '1'
	option leasefile '/tmp/dhcp.leases'
	option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
	option ednspacket_max '1232'
	option rebind_protection '0'
	option logqueries '1'
	option domainneeded '1'
	option localservice '1'
	list interface 'br-lan'

config dhcp 'lan'
	option interface 'lan'
	option start '100'
	option limit '150'
	option leasetime '12h'
	option dhcpv4 'server'
	option ignore '1'
	option dynamicdhcp '0'

config odhcpd 'odhcpd'
	option maindhcp '0'
	option leasefile '/tmp/hosts/odhcpd'
	option leasetrigger '/usr/sbin/odhcpd-update'
	option loglevel '4'
17

YES, VIDICATION!!

I have a pfSense appliance as router and a Netgear WAX206 + EX6120 (both Mediatek devices) which behave much the same way with Android and iOS devices. I thought I was losing my mind after searching for anything that came close to what I was experiencing...

Funny detail: I started experiencing this issue with the deployment of DAWN/802.11r/k to have clients moved to the closest AP for the best WiFi experience possible. So I initially blamed these modifications and reverted everything to try and dumb it down again. The only thing I did not do was revert the OpenWRT version I was using to the older one (19 something) and the problems remained but mostly for iOS devices, though sometimes the Android devices would join the fray...

I am thinking of trying to enable the OpenWRT firewall and filtering out all ARP traffic over the bridge. Did anyone try this?

18

Reverted the EX6120 to 21.02.5 and the problems seem gone on that device.

I am going to upgrade this device step by step to see where it breaks, I am going to take it easy though, I have had more then enough issues with WiFi so far.

For the EX6120 there is another issue I discovered, the WiFi drivers get replaced or mangled in the latest version (22.03.x as well as any snapshot) of openwrt, which causes the wifi to stop working after only a couple connects. The AP just disapears from the air, until I reboot it. This is something I am trying to debug a bit for more information which I will be putting in a seperate bug report on GitHub.

19

@dajakerboss and @AmiSapphire are you still experiencing this issue? If so, can you try to enable ProxyARP on your WLAN Advanced settings and report back how it works after that?

I think that may have fixed the issue for me on my WAX206...

I also have this at start-up. If the ProxyARP did not help on the WLAN as a stand alone solution, add this to the /etc/rc.local and reboot the AP:

for device in `ls /proc/sys/net/ipv4/conf/*/proxy_arp | awk -F'/' '{print $7}'`; do 
  sysctl -w net.ipv4.conf.$device.proxy_arp=1;
  sysctl -w net.ipv4.conf.$device.proxy_arp_pvlan=1;
done
1 Like
20

Yeah, the power is out (Michigan ice storm), so I won't be able to test this right away. On a portable generator for mostly running essentials.

I'll keep a note of this for when the power returns (probably a few days at most).

Edit: The power is actually back on and the original setup is fully operational! However, I will test this tomorrow at 5AM EST.

1 Like