Log into R7800 web gui from different local subnet

revengineer

Occasional Visitor
I moved my R7800 with Voxel firmware and configured as an Access Point to a different subnet (address now 192.168.3.2). The access point is configured with a static IP. Now I cannot connect to the admin web gui from another local subnet (192.168.1.x). I can ping the R7800 from the .1.x subnet and I can connect to the R7800 from the .1.x subnet via SSH. So the connectivity and routing seems fine, it just appears that the admin gui cannot be accessed from a subnet other than that configured in the gui. I have tested that the gui is accessible from a machine connected to the .3.x subnet.

From my observations, I conclude that gui access from different subnet may be prevented for security reasons. Since this device is on a home network behind a good firewall, I would like to relax the security to allow gui login from a different subnet.

Can anyone confirm this behavior and perhaps provide a configuration option to allow logins from other subnets?

Thank you for advice in advance.
 

R. Gerrits

Senior Member
Looking at the iptables on my R7800 (configured as router):
Code:
Chain loc2net (2 references)
 pkts bytes target     prot opt in     out     source               destination         
  15M   10G ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
  252 74494 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW tcp flags:!0x3F/0x02
 3730  295K DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
1870K  130M TRIGGER    all  --  *      *       0.0.0.0/0            0.0.0.0/0           [16 bytes of unknown target data] 
 4612  599K ACCEPT     all  --  *      *       192.168.2.0/24       0.0.0.0/0           
    0     0 DROP       all  --  *      *      !192.168.1.0/24       0.0.0.0/0           
1865K  129M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0

That second to last line would indeed drop all traffic that is not from the same subnet.
(and the third to last line is there because I have OpenVPN-server enabled)

If an R7800 in AP-mode has similar rules, you could try running this command: (to allow all traffic from 192.168.1.0/24)

iptables -w -I loc2net -s 192.168.1.0/24 -j ACCEPT

(And if that works, you could add this rule to /opt/scripts/firewall-start.sh)
 

revengineer

Occasional Visitor
The chain loc2net does not seem to exist on my R7800 running Voxel firmware v1.0.2.97SF. When listing the rules, my system shows as seen below. Essentially there seems to be no rules defined. I tried adding suggested rule to chains INPUT, OUTPUT, and FORWARD but gui access still gives "404 not found" error.

Code:
[email protected]:~$ iptables -L -v -n

Chain INPUT (policy ACCEPT 2203 packets, 117K bytes)

pkts bytes target     prot opt in     out     source               destination



Chain FORWARD (policy DROP 0 packets, 0 bytes)

pkts bytes target     prot opt in     out     source               destination



Chain OUTPUT (policy ACCEPT 2180 packets, 99382 bytes)

pkts bytes target     prot opt in     out     source               destination

[email protected]:~$
 

R. Gerrits

Senior Member
The chain loc2net does not seem to exist on my R7800 running Voxel firmware v1.0.2.97SF. When listing the rules, my system shows as seen below. Essentially there seems to be no rules defined. I tried adding suggested rule to chains INPUT, OUTPUT, and FORWARD but gui access still gives "404 not found" error.

Code:
[email protected]:~$ iptables -L -v -n

Chain INPUT (policy ACCEPT 2203 packets, 117K bytes)

pkts bytes target     prot opt in     out     source               destination



Chain FORWARD (policy DROP 0 packets, 0 bytes)

pkts bytes target     prot opt in     out     source               destination



Chain OUTPUT (policy ACCEPT 2180 packets, 99382 bytes)

pkts bytes target     prot opt in     out     source               destination

[email protected]:~$

now that I think of it, that kind of makes sense.... An access point is only switching. so it only uses ebtables and not iptables.
You could check if ebtables is blocking something:
ebtables -L

Or check if the iptables on the main router is somehow dropping the tcp traffic.
 

revengineer

Occasional Visitor
I checked the ebtables yesterday and just again, they are empty too. So I am not sure what blocking the http access but letting through ssh and telnet. Perhaps it's in the configuration of uhttpd daemon; I looked at the config in /etc/config/uhttpd but there is nothing obvious.
 

R. Gerrits

Senior Member
I checked the ebtables yesterday and just again, they are empty too. So I am not sure what blocking the http access but letting through ssh and telnet. Perhaps it's in the configuration of uhttpd daemon; I looked at the config in /etc/config/uhttpd but there is nothing obvious.
something you could test: kill the telnet daemon and reconfigure the uhttpd daemon to run on port 23 (and restart it) -> if you can then access the GUI via port 23 then you know that it is not the uhttpd daemon.

(or alternatively, kill uhttpd, reconfigure telnet to run on port 80 and test if you can telnet to port 80)
 

revengineer

Occasional Visitor
I tried a lot of things but do not seem to get it right. I see others complaining about this issue across the internet without a solution. I think I may just have to accept that this router is flawed and move on.
 

Kitsap

Occasional Visitor
Reply
I tried a lot of things but do not seem to get it right. I see others complaining about this issue across the internet without a solution. I think I may just have to accept that this router is flawed and move on.


Thinking out of the box. Did you ever consider adding a static route to your access point from your primary router?

Some versions of Netgear firmware prevented access to the modems GUI from the router. See attached.
 

Attachments

  • Static Route for Modem.pdf
    169.2 KB · Views: 24

revengineer

Occasional Visitor
Reply



Thinking out of the box. Did you ever consider adding a static route to your access point from your primary router?

Some versions of Netgear firmware prevented access to the modems GUI from the router. See attached.
Thank you for the pointer to static routes. My understanding is that static routes are for traffic originating from the access point, and not for incoming packets from other subnets. I am happy to be corrected if I misunderstood.

I reiterate that the routing generally seems to work because I can log into the access point from another subnet via SSH. Only for port 80, this seems to be block on this device. I have other brand/model access points on other subnets, and the access of port 80 seems to be fine on those devices. This makes me think that the traffic to the web GUI is blocked internal to the R7800. Unfortunately, I do not know how to continue the troubleshooting within the Voxel firmware.
 

Kitsap

Occasional Visitor
Thank you for the pointer to static routes. My understanding is that static routes are for traffic originating from the access point, and not for incoming packets from other subnets. I am happy to be corrected if I misunderstood.

I reiterate that the routing generally seems to work because I can log into the access point from another subnet via SSH. Only for port 80, this seems to be block on this device. I have other brand/model access points on other subnets, and the access of port 80 seems to be fine on those devices. This makes me think that the traffic to the web GUI is blocked internal to the R7800. Unfortunately, I do not know how to continue the troubleshooting within the Voxel firmware.

I do not think you can configure an access point with a static route. The intent was to put the static route in the router that provides DHCP services to your other subnet and point it toward your access point IP.

It should be easy enough to test and see as part of your troubleshooting efforts.
 

revengineer

Occasional Visitor
Understood! I have now tried this route on my pfsense firewall, which is my DHCP server and is the link between the two subnets. Unfortunately, without success. I think it's because the route into the subnet, where the access point resides, is generally working.
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top