Can’t access Web GUI from LAN

The cause of this may have happened some time ago, and I am only just noticing it now, but I can’t seem to access the Web GUI for my wireless access point from any box within my LAN.

I have a Buffalo WZR-600DHP wireless router that is setup on my network exclusively as a wireless access point for local wireless devices. It is not doing any routing, but is purely a wireless access point. It has been setup this way for a couple of years and I know I have been able to access the web interface since it was setup as an AP.

The last significant change I made to my network was to install a managed switch and create two VLANs on the switch for establishing private and a guest wireless network SSIDs on the access point. This change occurred about a year ago and it has been working as expected.

My network configuration to the access point looks like this:

Incoming WAN ---> pfSense Gateway / Router / Firewall ---> Managed Switch (Netgear) with 3 VLANs (1=home wired vlan, 20=private wireless vlan, 30=guest wireless vlan) ---> Buffalo AP

pfSense Router = 192.168.123.2
Netgear Switch = 192.168.123.4
Wired LAN = 192.168.123.xxx
Private Wlan = 192.168.124.xxx
Guest Wlan = 192.168.133.xxx
Buffalo AP = 192.168.123.5 (according to my setup notes)

I think I recall being able to access the Web GUI of the access point since I setup the VLANs, but not entirely sure since I had not needed to access it since then. I know I accessed it during the process of setting up the VLANs. I don’t have any notes during this process that indicates I needed to do anything special to access the Web GUI.

I have tried numerous different things to connect, including disconnecting the Access Point from my router and making a direct wired connection to a laptop, even trying a crossover cable, and plugging into LAN or the WAN ports of the AP. And too many other possibilities to list here. Nothing has been successful yet. The results I think that are pertinent to describe here as a starting point to continue this are the ping and network scan results listed below. The results I am seeing in a ping test from both a PC in the LAN and the pfSense router indicate that the IP address for the AP doesn’t exist.

From LAN PC, 192.168.123.20
C:\WINDOWS\system32>ping 192.168.123.5
Pinging 192.168.123.5 with 32 bytes of data:
Reply from 192.168.123.20: Destination host unreachable.
Reply from 192.168.123.20: Destination host unreachable.
Reply from 192.168.123.20: Destination host unreachable.
Reply from 192.168.123.20: Destination host unreachable.
Ping statistics for 192.168.123.5:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

From pfSense box (router), 192.168.123.2
PING 192.168.123.5 (192.168.123.5) from 192.168.123.2: 56 data bytes
--- 192.168.123.5 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss

At first from this I thought that maybe I had messed up my routing when I setup the VLANs, or maybe the AP was actually assigned a different IP address than what I had listed in my notes. So, I started Nmap from the LAN PC and did a scan of the 192.168.123.0/24 network. The results from this did not identify the AP anywhere in the network, but correctly identified everything else.

So, I expanded the Nmap test and did a scan on the 192.168.0.0/16 network. The results of this did not identify the AP anywhere in the network. However, the scan did successfully find computers in the network on the other side of the VPN the LAN PC was connected to at the time of the scan.

So now I have run out of ideas to test, and am wondering if someone can point me to where my knowledge is lacking. I am thinking the issue might lie in my VLAN configuration, since my experience with VLANs is pretty limited and I might not see a configuration error while looking right at it.

Can someone please educate me on where I should be looking next. Thanks.

  • What is the time frame you're referring to: hours, weeks, years???
  • Can you show us the configs?
  • What version of OpenWrt are you running?
  • Can you SSH into it?

Timeframe? Don't know that it matters much but as I mentioned the last configuration change I made was about a year ago. Don't know if I have logged into the GUI since then.

Configs? Can't ping the device or get to the GUI, so have no way of getting a current copy of the configs.

Version? My notes show that it is running lede-17.01.2

SSH? Nope. I tried that also.

Have you tried doing a complete network scan? There are lots of apps available for all platforms (or just use nmap). You'll really only need to do a ping scan or scan for devices with ssh (22) or http (80)/https (443) listening across the network. Or if you know the MAC address of the device, you can look at your router DHCP leases or ARP to see if you can find it that way.

Yep, I used Nmap to scan the network to see if I could see it. As mentioned in the OP I scanned the 192.168.123.0/24 network and didn't find it. Then scanned the 192.168.0.0/16 network and did not find the AP anywhere.

Did you renumber your network at any time over the year?

If your AP was configured with a LAN static address, it's possible that you never readdressed the AP and it may still be configured to an old subnet.

If so, scanning wouldn't likely see this IP on the network until you readdressed the scanning client.

Checking IPv6 neighbors can sometimes locate a "lost" device.

With luck, you can SSH or otherwise connect to its link-local address.

1 Like

I haven't renumbered my primary wired network in probably 10 years, it has always been 192.168.123.xxx. I added the two additional subnets when I created the vlans a year ago, that is why I also scanned the 192.168.x.x network.

1 Like

Not familiar with "checking IPv6 neighbors". Can you provide some additional explanation of this?

ip -6 neigh

  • See if the AP is announcing an IPv6 Link-Local IP.
  • If so, try to SSH it

On a Linux-based OS

ip -6 neigh

On FreeBSD and macOS

ndp -an

I don't know about Windows


Output like

fe80::9683:c4ff:fe00:4a31 dev enp9s0f1

would be used such as

ssh root@fe80::9683:c4ff:fe00:4a31%enp9s0f1
1 Like

In PowerShell, should be:

Get-NetNeighbor

Also, the OP could always try to failsafe it:

1 Like

Ok, I first tried checking the IPv6 neighbor from the pfSense router box and just got the interfaces that are directly on the pfSense box. So I then tried from the Windows box Powershell and that gave a long list of things. The relevant items from the output are below. Not sure that it helps.

PS C:\WINDOWS\system32> Get-NetNeighbor

ifIndex IPAddress LinkLayerAddress State PolicyStore


6 192.168.123.5 00-00-00-00-00-00 Unreachable ActiveStore

I am aware that I could do a failsafe or factory reset, but didn't want to have to rebuild my configuration from scratch. I see that I do have a config backup from about a year ago, but not sure if it was made immediately after setting up the vlans or before. Since the system is working as-is, I didn't want to go to the extreme of resetting it from scratch. That is why I was hoping to find other options that I might not be aware of.

Failsafe and reset are two distinctly different actions (although sometimes failsafe is required to get into the router such that you can reset it). As long as you don't mind taking it offline for a short time, you can use failsafe to gain access and check out the configuration -- namely the /etc/config/network, /etc/config/wireless, and /etc/config/firewall files. This will help you figure out what the configuration is doing (and thus how it should present on your network and/or if there are restrictions for specific VLANs to gain access, etc.). If you don't make any changes, everything will go back to normal when you reboot. But you can also make changes and/or reset if necessary.

2 Likes

Ok, I finally had the opportunity to interrupt our wifi service and boot the access point into failsafe mode and dump out the current configuration information. It doesn't look like there are new timestamps on anything but the Firewall, Network, and Wireless config files. They are posted below. My ssid and password have been anonymized. A quick summary of my home network arrangement as I described in the original post is:

Incoming WAN ---> pfSense Gateway / Router / Firewall ---> Managed Switch (Netgear) with 3 VLANs (1=home wired vlan, 20=private wireless vlan, 30=guest wireless vlan) ---> Buffalo AP

pfSense Router = 192.168.123.2
Netgear Switch = 192.168.123.4
Wired LAN = 192.168.123.xxx
Private Wlan = 192.168.124.xxx
Guest Wlan = 192.168.133.xxx
Buffalo AP = 192.168.123.5 (according to my setup notes)

root@(none):/etc/config# ls -l
-rw-r--r--    1 root     root           789 Sep 30  2017 dhcp
-rw-r--r--    1 root     root            86 Sep 10  2017 dropbear
-rw-r--r--    1 root     root          2625 Jan  4  2019 firewall
-rw-r--r--    1 root     root           742 Jun  8  2017 luci
-rw-r--r--    1 root     root          1242 Jan  4  2019 network
-rw-------    1 root     root            97 Jun  8  2017 rpcd
-rw-r--r--    1 root     root           842 Sep 10  2017 system
-rw-r--r--    1 root     root           115 Jun  8  2017 ubootenv
-rw-r--r--    1 root     root           736 Jun  8  2017 ucitrack
-rw-------    1 root     root           667 Jun  8  2017 uhttpd
-rw-r--r--    1 root     root          1072 Jan  4  2019 wireless
root@(none):/etc/config#
root@(none):/etc/config#
root@(none):/etc/config#
root@(none):/etc/config# cat firewall

config defaults
        option syn_flood '1'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'REJECT'

config zone
        option name 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        option network 'lan'

config zone
        option name 'wan'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option masq '1'
        option mtu_fix '1'
        option network 'wan wan6'

config forwarding
        option src 'lan'
        option dest 'wan'

config rule
        option name 'Allow-DHCP-Renew'
        option src 'wan'
        option proto 'udp'
        option dest_port '68'
        option target 'ACCEPT'
        option family 'ipv4'

config rule
        option name 'Allow-Ping'
        option src 'wan'
        option proto 'icmp'
        option icmp_type 'echo-request'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-IGMP'
        option src 'wan'
        option proto 'igmp'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-DHCPv6'
        option src 'wan'
        option proto 'udp'
        option src_ip 'fc00::/6'
        option dest_ip 'fc00::/6'
        option dest_port '546'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-MLD'
        option src 'wan'
        option proto 'icmp'
        option src_ip 'fe80::/10'
        list icmp_type '130/0'
        list icmp_type '131/0'
        list icmp_type '132/0'
        list icmp_type '143/0'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Input'
        option src 'wan'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        list icmp_type 'router-solicitation'
        list icmp_type 'neighbour-solicitation'
        list icmp_type 'router-advertisement'
        list icmp_type 'neighbour-advertisement'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Forward'
        option src 'wan'
        option dest '*'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-IPSec-ESP'
        option src 'wan'
        option dest 'lan'
        option proto 'esp'
        option target 'ACCEPT'

config rule
        option name 'Allow-ISAKMP'
        option src 'wan'
        option dest 'lan'
        option dest_port '500'
        option proto 'udp'
        option target 'ACCEPT'

config include
        option path '/etc/firewall.user'

root@(none):/etc/config#
root@(none):/etc/config#
root@(none):/etc/config#
root@(none):/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 'fd1d:abe9:6da3::/48'

config interface 'lan'
        option type 'bridge'
        option _orig_ifname 'eth0 radio0.network1 radio1.network1'
        option _orig_bridge 'true'
        option proto 'dhcp'
        option hostname 'buffaloap'
        option ifname 'eth0.1'

config interface 'wan'
        option ifname 'eth1'
        option proto 'dhcp'

config interface 'wan6'
        option ifname 'eth1'
        option proto 'dhcpv6'

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

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option vid '1'
        option ports '0t 1 2 3 4t'

config switch_vlan
        option device 'switch0'
        option vlan '2'
        option ports '0t 4t'
        option vid '30'

config interface 'VLAN_30'
        option proto 'static'
        option type 'bridge'
        option _orig_ifname 'eth0.30'
        option _orig_bridge 'true'
        option ifname 'eth0.30'

config switch_vlan
        option device 'switch0'
        option vlan '3'
        option ports '0t 4t'
        option vid '20'

config interface 'VLAN_20'
        option proto 'static'
        option type 'bridge'
        option _orig_ifname 'eth0.20'
        option _orig_bridge 'true'
        option ifname 'eth0.20'

root@(none):/etc/config#
root@(none):/etc/config#
root@(none):/etc/config#
root@(none):/etc/config# cat wireless

config wifi-device 'radio0'
        option type 'mac80211'
        option hwmode '11g'
        option path 'pci0000:00/0000:00:11.0'
        option htmode 'HT20'
        option country 'US'
        option channel '6'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option mode 'ap'
        option ssid 'AntiHome'
        option encryption 'psk2'
        option key 'AntiPassword'
        option network 'lan VLAN_20'

config wifi-device 'radio1'
        option type 'mac80211'
        option channel '36'
        option hwmode '11a'
        option path 'pci0000:00/0000:00:12.0'
        option htmode 'HT20'
        option country 'US'

config wifi-iface 'default_radio1'
        option device 'radio1'
        option mode 'ap'
        option encryption 'psk2'
        option key 'Password'
        option ssid 'Home'
        option network 'lan VLAN_20'

config wifi-iface
        option device 'radio0'
        option mode 'ap'
        option ssid 'antihome-guest'
        option encryption 'psk2'
        option key 'antipassword'
        option network 'VLAN_30'

config wifi-iface
        option device 'radio1'
        option mode 'ap'
        option ssid 'home-guest'
        option encryption 'psk2'
        option key 'password'
        option network 'VLAN_30'

root@(none):/etc/config#

My quick read of your config files is that everything is configured reasonably and there is likely no issue with the config itself. More than likely, the issue is that the IP address is dhcp supplied and may have changed at some point without you realizing it (maybe a change in the router config or firmware triggered the change). I’d recommend that you look at your routers dhcp leases (both static/reserved and dynamic) to see if it is showing up. Otherwise, change the IP address of your lan interface On the OpenWrt box to static and assign an address you know to be available (seems like the address you were expecting the device to occupy is not being used, so it would be a safe bet).

I tried a couple of changes to the firewall (listed below) but it had no effect on accessing the GUI.

Changed Config Zone WAN to Accept on Input and Forward.
Changed Config Rule Allow-DHCP-Renew to Source 'lan'.
Changed Config Rule Allow-Ping to Source 'lan'.
Changed Config Rule Allow-IGMP to Source 'lan'.

The last three I actually duplicated the existing rule and changed the Source to Lan, rather than changed the existing rule. I did all the rules at once, and did not test them individually.

I have many of my hardware pieces setup with static addresses in my router, and the Wireless AP has a static address designated at 192.168.123.5, and shows as that in the arp table of the router. I have been looking for a mysterious IP in my Nmap queries and have not found anything. All IPs in the Nmap searches are accounted for with other hardware, and the 192.168.123.5 address does not show up in any Nmap search.

Looking in the logs of my router (which is also my DHCP server) I see the following two lines repeated every three seconds for the entire history of my log file.

Dec 28 11:22:31 	dhcpd 		DHCPOFFER on 192.168.123.5 to 10:6f:3f:e7:f3:de via igb1
Dec 28 11:22:31 	dhcpd 		DHCPDISCOVER from 10:6f:3f:e7:f3:de via igb1 

Not sure how to interpret what these two lines mean, or if they are relevant to the problem, but I have confirmed that it is the mac address of my Wireless AP.

I should be able to run some more tests today, after the family leaves the house and I can take the wifi down and boot into failsafe mode again. One thing I am wondering about is whether the http and/or luci service is starting properly.

The other thing I am wondering about is whether the problem has something to do with a combination of the lan bridge and the vlan setup. In most of my testing I have been directly connecting (hardwired) to the Wireless AP with a laptop without going through the router, and test multiple times trying all the lan ports and the wan port.

Solved.

The basis of this solution is that the WAN interface is assigned a static IP within the LAN network. Since the Buffalo is configured as a Wireless Access point (a routed AP since there are multiple SSIDs and VLANs configured) it was only connected to the router via the APs LAN port, and since the LAN port is bridged it is not accessible. The WAN interface is then basically used as a management interface for the AP and only needs to be connected when access to the LEDE GUI is required.

The changes I made to solve this (using vi editor while connected in failsafe mode) included one change to the firewall, and three changes to the network configuration file, as listed below.

Firewall Change:
Changed Config Zone WAN from Input Reject to Input Accept.

Network Change:
Changed Interface WAN from Proto DHCP to Proto Static
Added Option ipaddr '192.168.123.6'
Added Option netmask '255.255.255.0'

The IP address 192.168.123.6 is outside the range that is assigned to dynamic IP addresses, so I know that it won't collide with any IP address in the future. I can probably leave the connection between my router and the Buffalo AP WAN port connected full time, and have a static IP address designated in the router to the MAC address of the Buffalo WAN port. That would allow me to reverse the network changes listed above, leaving only the firewall change as necessary. I can probably also remove the static IP assignment in my router to the Buffalo's LAN port, as it is meaningless and is probably what is causing the repeating DHCP query I am seeing every three seconds in my log files.

I will experiment with those changes next, but in the mean time I now have access to the GUI to make other changes to my wireless network.

Thanks to all that offered constructive advice; it eventually lead me to a solution.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.