Dumb AP & No access to the outside world

[mqtthiqs]

Hello,

Not quite a newbie, but because I don't practice I keep forgetting my sysadmin skills... Thanks in advance for your help.

I am trying to set up a dumb AP at work to get a Wifi access point from the wired connection. Using a TL-WPA8630 for this. My local network — which I don't have control over — is 10.50.31.0/24; if I plug my computer to the wall it gets a 10.50.31.XXX address through DHCP. I followed the Dumb AP tutorial, and set the AP's IP to 10.50.31.222. But am stuck with no access to the outside world.

SSHing into the AP, I can ping local machines 10.50.31.XXX and even neighboring machines at 10.50.30.XXX. But anything outside of this fails:

root@OpenWrt:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes

... and it sits there indefinitely. The routes seem correct to me:

root@OpenWrt:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.50.31.254    0.0.0.0         UG    0      0        0 br-lan
10.50.31.0      0.0.0.0         255.255.255.0   U     0      0        0 br-lan

From a machine connected to the AP wirelessly I do get an IP from the local DHCP (10.50.31.XXX) and a working DNS and gateway, but no ping to the outside world either (but with repeated messages "Destination Host Unreachable").

Obviously the wired network works as it should.

Could this be a security measure? Is it technically possible for routers downstream to detect and block this specific traffic? (I work at a fairly large organization) Or is it just a config issue?

Thanks!

[mqtthiqs]

My /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 'fd22:85ad:8349::/48'

config interface 'lan'
	option type 'bridge'
	option ifname 'eth0.1'
	option proto 'static'
	option netmask '255.255.255.0'
	option ip6assign '60'
	option ipaddr '10.50.31.222'
	option gateway '10.50.31.254'
	option broadcast '10.50.31.255'
	option dns '10.3.200.100 10.201.200.201'

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

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

[psherman]

A few things here...

@mqtthiqs

config interface 'lan'
	option type 'bridge'
	option ifname 'eth0.1'
	option proto 'static'
	option netmask '255.255.255.0'
	option ip6assign '60'
	option ipaddr '10.50.31.222'
	option gateway '10.50.31.254'
	option broadcast '10.50.31.255'
	option dns '10.3.200.100 10.201.200.201'

Although it does seem like things are not colliding, are you positive that 10.50.31.222 is outside the DHCP pool for the network and that no other device will ever be assigned that same static IP address? This is critical because if you don't control the upstream network, you need to make sure that your use of this IP won't cause a conflict down the road.

Next, is the gateway correct (.254) -- is that the gateway you get if you have a computer directly connected and pulling an address via DHCP?

And those DNS addresses -- are those correct and reachable by the router (they're in totally different subnets, so the upstream network must allow routing accordingly).

Finally, what version of OpenWrt are you using? The bridge and ifname declarations have changed in more recent versions of OpenWrt, so that would be a problem if you're up-to-date (and if you're not up-to-date, you should consider upgrading).

What is the ouput of:

ubus call system board

Finally, I personally recommend removing the broadcast address... it is actually auto-calculated, so it is not necessary to specify. I don't expect that this will change anything (what you have there is correct), but I would advise removing it just to keep things cleaner.

[mqtthiqs]

Thanks for your help @psherman

Although it does seem like things are not colliding, are you positive that 10.50.31.222 is outside the DHCP pool for the network and that no other device will ever be assigned that same static IP address? This is critical because if you don't control the upstream network, you need to make sure that your use of this IP won't cause a conflict down the road.

Good point. I changed the address to 10.50.31.241 and am making progress.

• SSHing into the AP I can now ping openwrt.org
• ...but still no dice from a client connected to the AP's wifi.

Next, is the gateway correct (.254) -- is that the gateway you get if you have a computer directly connected and pulling an address via DHCP?

Yes.

And those DNS addresses -- are those correct and reachable by the router (they're in totally different subnets, so the upstream network must allow routing accordingly).

Correct and reachable yes.

Finally, what version of OpenWrt are you using? The bridge and ifname declarations have changed in more recent versions of OpenWrt, so that would be a problem if you're up-to-date (and if you're not up-to-date, you should consider upgrading).

Ancient. Will upgrade and report back if it changes anything.

What is the ouput of:

ubus call system board

{
	"kernel": "4.9.184",
	"hostname": "OpenWrt",
	"system": "Qualcomm Atheros QCA956X ver 1 rev 0",
	"model": "TP-LINK TL-WPA8630",
	"board_name": "tl-wpa8630",
	"release": {
		"distribution": "OpenWrt",
		"version": "18.06.4",
		"revision": "r7808-ef686b7292",
		"target": "ar71xx\/generic",
		"description": "OpenWrt 18.06.4 r7808-ef686b7292"
	}
}

[mqtthiqs]

Just upgraded to 22.03.3, played around with the settings to upgrade the config files. Makes no difference unfortunately (apart from the cosy new interface).

ubus call system board:

{
	"kernel": "5.10.161",
	"hostname": "OpenWrt",
	"system": "Qualcomm Atheros QCA956X ver 1 rev 0",
	"model": "TP-Link TL-WPA8630 v1",
	"board_name": "tplink,tl-wpa8630-v1",
	"rootfs_type": "squashfs",
	"release": {
		"distribution": "OpenWrt",
		"version": "22.03.3",
		"revision": "r20028-43d71ad93e",
		"target": "ath79/generic",
		"description": "OpenWrt 22.03.3 r20028-43d71ad93e"
	}
}

/etc/config/network:

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

config globals 'globals'
	option ula_prefix 'fd22:85ad:8349::/48'

config interface 'lan'
	option proto 'static'
	option netmask '255.255.255.0'
	option ip6assign '60'
	option gateway '10.50.31.254'
	option ipaddr '10.50.31.241'
	option device 'br-lan'
	list dns '10.3.200.100'
	list dns '10.201.200.201'

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

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

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

config device
	option name 'eth0'

config device
	option name 'eth0.1'
	option type '8021q'
	option ifname 'eth0'
	option vid '1'

config device
	option name 'wlan0'

[psherman]

I assume that pinging 8.8.8.8 from the OpenWrt device itself results in no response?

If so, you might have hit this point:

@mqtthiqs

Could this be a security measure? Is it technically possible for routers downstream to detect and block this specific traffic? (I work at a fairly large organization) Or is it just a config issue?

Yes, higher end enterprise equipment (switches and routers) can detect and shut down access to devices that are not authorized to be on the network.

[mk24]

Endpoints connected to the wifi of a dumb AP will interact with the upstream network's DHCP server which will provision their IP address etc. So all this fretting about the AP's local IP configuration is not necessary. In fact you could make the AP a bridge to the Ethernet without it itself holding any IP address, and a device connected to the wifi will still work as long as the corporate network allows it.

Corporate networks use a variety of methods to prevent the attachment of devices that are not officially recognized, as they can be a security issue. It's a bad idea to bring in your own AP or router without permission.

[psherman]

@mk24

It's a bad idea to bring in your own AP or router without permission.

^^^ 1000000% this.

At my company, they will find you, and you will be diciplined.

[mqtthiqs]

@psherman

I assume that pinging 8.8.8.8 from the OpenWrt device itself results in no response?

I can ping 8.8.8.8 (or openwrt.org for that matter) from the device since I switched IP adresses; sorry if I was unclear above.

So, now that the device has full network access and isn't restricted, would a router be able to make a difference between a packet coming from the device itself and one forwarded by it then?

@mk24

It's a bad idea to bring in your own AP or router without permission.

That's another discussion, and I'd rather leave this one purely technical; just trying to deal with common workplace mediocrity here, and get my job done in reasonable conditions.

[psherman]

@mqtthiqs

So, now that the device has full network access and isn't restricted, would a router be able to make a difference between a packet coming from the device itself and one forwarded by it then?

If your OpenWrt router is running NAT masquerading, an upstream router would not be able to determine the difference between the router's own traffic vs that of the devices behind that router. However, an upstream switch or router may be able to determine that this is not an allow-listed/approved device, in which case access may be cut off. At my company, it is likely the port would be shut down if an unapproved device was connected.

But, the above is based purely on the ethernet stack... if you add wireless to the mix, enterprise APs can often scan the airwaves for unsanctioned APs/SSIDs, and they may be able to triangulate the position... they might then work to figure out if that is connected to any corporate network ports and then action on that accordingly.

[mqtthiqs]

When you say

determine that this is not an allow-listed/approved device

You mean filtering by a list of MACs right? But since any device can get an IP and access the outside it means there is no such filtering, right?

If your OpenWrt router is running NAT masquerading, an upstream router would not be able to determine the difference between the router's own traffic vs that of the devices behind that router.

Ok, that's probably my next attempt then.
Thanks a lot for your advices @psherman @mk24

[psherman]

@mqtthiqs

You mean filtering by a list of MACs right?

It could be MAC address filtering or something more complex like 802.1x authentication or other cryptographic certs.

@mqtthiqs

But since any device can get an IP and access the outside it means there is no such filtering, right?

Maybe... depends on if and how they implement their security. You may or may not be able to access corporate resources yet still have access to the internet, as an example.

[mqtthiqs]

Are you really sure we've been through everything else config-wise though? The whole security argument somehow seems a bit rushed at this point... To sum it up again:

• I want to bridge a local wired network to my OpenWRT device's wlan
• any (wired) device can get access to the wired network, and can talk to the inside/outside via its gateway
• the OpenWRT device is configured so it can talk to the inside/outside
• the devices connected to the OpenWRT's wlan can talk to the inside but strangely not to the outside

[mk24]

@mqtthiqs

I want to bridge a local wired network to my OpenWRT device's wlan

You have done that, and apparently the wired network is not serving your devices properly. This is likely not an OpenWrt issue. Look directly at a wifi endpoint device's network status while it is connected, and see if it has a valid IP, DNS, and gateway on the wired network.

In a dumb AP, it is very important to have disabled the DHCP server which OpenWrt runs on lan by default. If that server is still running, it will be in a race to serve incorrect replies to devices on the lan, both your wifi devices, and other wired devices in the building on the same network segment. Other offices may lose network access, causing an IT department investigation.

[mqtthiqs]

@mk24

Look directly at a wifi endpoint device's network status while it is connected, and see if it has a valid IP, DNS, and gateway on the wired network.

I checked, it does have a valid IP, DNS, gateway.

@mk24

In a dumb AP, it is very important to have disabled the DHCP server which OpenWrt runs on lan by default.

Yes thx, I know and I did.

Well, I guess it'll stay a mystery.
Thanks again.

[psherman]

@mqtthiqs

• the OpenWRT device is configured so it can talk to the inside/outside
• the devices connected to the OpenWRT's wlan can talk to the inside but strangely not to the outside

So to really understand what is happening, from a purely technical perspective on the OpenWrt side, we need to see 4 config files:

Please copy the output of the following commands and post it here using the "Preformatted text </> " button:

Remember to redact passwords, MAC addresses and any public IP addresses you may have:

cat /etc/config/network
cat /etc/config/wireless
cat /etc/config/dhcp
cat /etc/config/firewall

@mqtthiqs

The whole security argument somehow seems a bit rushed at this point.

TBH, I have opinions about this, but I'm respecting your statement from here:

@mqtthiqs

That's another discussion, and I'd rather leave this one purely technical; just trying to deal with common workplace mediocrity here, and get my job done in reasonable conditions.

Put plainly, I would argue that adding your own router or dumb AP is tenuous at best with respect to security (at least from a corporate IT perspective), but it does very much depend on the security models of your institution.

To be clear, I'm not judging you personally -- I absoutely understand the issue of trying to 'just get work done' despite the bureaucracy of a workplace. Many years ago, I needed a wireless mouse but decided that it was better to spend my own $30 than to literally get the request up for VP approval in a company of nearly 20K employees), so I understand your motivation.