Remote Access with Enable Access Restrictions ON

[PunchCardBoss]

Objective:

• Restrict (allow only) access to my home router UI from a known WAN (ISP) IP remote location.
• Allow local LAN devices to access the router UI

Conditions:

• Router Model: RT-AX88U
• Firmware: 388_20518 (AsusWRT) current
• Remote location WAN IP = 68.243.55.29 (fictitious for this discussion)

It would appear that the AsusWRT firmware offers the ability to enable remote access restrictions. However, the description that Asus gives seems to be ambiguous (not unusual for Asus). It would seem that the “Network/Host IP” field should be the WAN (ISP) location for the remote location: 68.243.55.29 (kind of an IP 'allow' filter/firewall). But the description and options in the drop list seem to be all local LAN devices.

My questions are simple ones:

1. Should the “Network/Host IP” field be filled in with the remote WAN (ISP) IP addresses? If not, then what?
2. What is the function of the “All” button just under the words “Access restriction list”?

Images follow...

Tks in advance for your guidance.

P.S. I did extensive searches on the web and this forum for answers prior to posting this information request. But, if someone knows where to point me for the answers, I would be grateful.

 

[ColinTaylor]

I suggest you just try this for yourself and see if it works the way you want it to.

 

[PunchCardBoss]

try this for yourself and see if it works the way you want it to

Thought of that. Actually, the real scenario is the reverse. I am the remote location and didn't want to mess up my access to the remote router. Hence the question 1st.
"Measure twice, cut once".

 

[eibgrad]

The Network/Host IP is simply the public IP (or network containing it) of the remote device, since that's what the router's services are going to see for purposes of restricting access. Might have been better explained by ASUS by using actually public IPs rather than the private IP space.

 

[PunchCardBoss]

didn't want to mess up my access to the remote router.

Well, Colin. Get ready for a good chuckle.

I tried as your suggestion on my home router and locked myself out! Fortunately, I had created one back-door...

With my cell phone, I disconnected from my local WIFI and established a connection with my wireless phone carrier. Then, I found the IP address that the carrier was assigned to my phone. I used that single IP address in the “Network/Host IP” field. And pressed the "Apply" button on the router UI.

Oops. no device in my local LAN could access the router UI. BUT, my back-door worked. I used the browser on my phone and connected to the router with remote access ENABLED and my DDNS.

And after several tests, I confirmed the following:

1. “Network/Host IP” fields may be either local LAN IP addresses or WAN (ISP) IP addresses.
2. The "Access restriction list" functions much like an "Allow" list: If an IP (whether WAN or LAN) is not on the list, it has no access. Be careful!
3. “Network/Host IP” field does appear to accept IP with subnet values.
4. The list will only accept (4) entries even though some records may be disabled.
5. The "ALL" button enables/disables all entries on the "Access restriction list".
6. Best practice: add LAN devices with static IP address to the "Access restriction list" so you don't get locked out.
7. Be careful!!! Make system backups just in case...

So Colin.... how hard did you laugh?

 

[PunchCardBoss]

The Network/Host IP is simply the public IP (or network containing it) of the remote device

Any thoughts if my local gateway IP address would work for all local LAN devices?
Or maybe 192.168.1.0/24?

 

[ColinTaylor]

“Network/Host IP” field does appear to accept IP with subnet values.

Except it doesn't work. I'll have to check the source code to confirm a syntax that actually works.

So Colin.... how hard did you laugh?

To be honest - not at all considering I just did exactly the same thing (out of curiosity). So now I'm locked out of my router, but unlike you I didn't create a backdoor. Ho hum, I live and learn. Fortunately I have a recent backup. I just need to get permission from my better half to take the router down for a few minutes for the restore.

You may now laugh....

 

[PunchCardBoss]

I'm locked out of my router

Ooooooh noooooo!
So sorry to hear of your wows.
Any how, glad you have a system backup.

Except it doesn't work

Re subnet. I should say that the router accepted a subnet address like 192.168.1.0/24. But I did not [Apply] or test it. But it would be nice if one entry would allow all (or part) LAN devices.

 

[PunchCardBoss]

One more update...

With:
DDNS [Enabled],
"Remote Access" [Enabled] and
"Access restriction list" [Enabled] with only LAN IPs in the list.

... the Android Asus router app will NOT connect.

If I [Disable] the "Access restriction list", then the app connects.

This update behavior is consistent with earlier observations.

 

[Apprentice]

Question answered! This feature would imv be significantly more useful if it implemented some sort of MAC filtering! I don't suppose there is a feature request list somewhere?

 

[ColinTaylor]

Question answered! This feature would imv be significantly more useful if it implemented some sort of MAC filtering! I don't suppose there is a feature request list somewhere?

MAC addresses only exist in the local subnet. Therefore they cannot be used to control remote access from the internet.

 

[Apprentice]

MAC addresses only exist in the local subnet. Therefore they cannot be used to control remote access from the internet.

Right, and what I have in mind is SSH as the primary remote access control, with something like a MAC whitelist operating on wan connections as a second layer of security. I certainly wouldn't feel comfortable trying to implement this, but should be possible via Iptables as I see it!

 

[ColinTaylor]

... with something like a MAC whitelist operating on wan connections as a second layer of security.

As I just said, MAC addresses only exist in their local (originating) subnet, therefore they cannot be used to control remote access from the internet.

 

[Apprentice]

As I just said, MAC addresses only exist in their local (originating) subnet, therefore they cannot be used to control remote access from the internet.

i don't understand what you are talking bout. MAC addresses are hard coded into network interfaces. Yes, they can be spoofed by a malicious attacker, but an attacker would first have to know what specific MAC address had been whitelisted in the scenario I outlined above.

Good day to you

 

[ColinTaylor]

i don't understand what you are talking bout. MAC addresses are hard coded into network interfaces. Yes, they can be spoofed by a malicious attacker, but an attacker would first have to know what specific MAC address had been whitelisted in the scenario I outlined above.

Good day to you

Maybe I'm missing the purpose of your original question. It sounded like you wanted to restrict access from the internet based on the MAC address of the originating host machine? This is not possible because MAC addresses do not traverse the internet, they a limited to their own local network.

So for example, if you do a packet capture of all of the incoming traffic on your router's WAN interface you will see that all of it has the same source MAC address. That MAC address is that of the ISP device connected to the WAN interface (or the ISP gateway in the case of cable modems).

 

[Apprentice]

Maybe I'm missing the purpose of your original question. It sounded like you wanted to restrict access from the internet based on the MAC address of the originating host machine? This is not possible because MAC addresses do not traverse the internet, they a limited to their own local network.

So for example, if you do a packet capture of all of the incoming traffic on your router's WAN interface you will see that all of it has the same source MAC address. That MAC address is that of the ISP device connected to the WAN interface (or the ISP gateway in the case of cable modems).

Well it does seem my assumption that a MAC address is available for SSH clients via the Arp table was mistaken. My bad