[SOLVED] Lost https web UI access (edited)

Installing and Using OpenWrt
1

This might be similar to the problem kattivius reported (Lost https web UI access) but I am choosing to start a new topic to avoid drawing the wrath of moderators. I also posted this to the IRC channel, but I think I might get more eyes here.

I am running openwrt in a vbox VM and have been doing so for over a year. It does work, but I wanted to see if I could kind of lock down the router somewhat more. I am trying this in openwrt 21.02.1 on a testing box; I don't use it for much except building packages and some debugging and testing different software configurations.

I decided to try DENY on all INPUT, including the management port of my openwrt router. Before doing so, however, I intentionally opened ports 22,53,123, and 443 so that I would still have access to the web ui, DNS, and SSH to the router. I also opened 123 thinking that SSL probably requires packet timing accuracy and I initially suspected that that might have been the source of my problem, described below. However, this did not quit the problem but I am leaving it open in further testing because it may help thwart packet timestamp issues.

After updating the router with this new configuration, I was able to access the LuCI (via https), and to continue working in an SSH shell on the router that I started prior to updating the router. I can ping the internet, and browse web sites.

After about a minute or so, I lost the web ui and I could not create a new SSH connection to the router even though the one I had opened continued to work without issue. I could continue browsing OTHER web sites and ping was happy to work virtually anywhere.

I think I am close to getting this to work, but I am wondering if anyone knows of any additional ports that need to be open, or possibly some configuration tuning that still needs to be done. I can't imagine what, but hopefully someone here knows of something I can try.

BTW, this is a really simple scenario anyone should be able to duplicate, given a spare box (possibly, though it should do the same on any hardware), virtualbox (as I haven't tried it with kvm), and a very, very simple interface configuration. No additional packages had to be installed. I used the stock image from the openwrt website. I created a separate management port, but using the LAN side should yield the same results.

Also, am I wrong to think that the configuration I am attempting could not possibly work? I'd think this is appropriate and would be well-supported. I don't think what I am doing is particularly radical, but I am still a bit green with networking and openwrt. After a year of working with it, I am still just learning stuff.

Sorry for being long in the tooth. I just wanted to supply enough information to be understood and hopefully receive some help with this. Thank you so much for any constructive feedback.

[EDIT]: I should also mention that, using the already-opened ssh session, I was able to see that uhttpd was still running, and I was able to access the rest of my local network as well as the Internet.

I was able to reproduce this scenario repeatedly by simply resetting the router's VM back to a snapshot I had created prior to munging with the router.

[EDIT2]: Forgot to also add that running tcpdump on the router while all INPUT is DENY'd does show ssh packets making it into the router. But there is no response from the router. I confirmed that dropbear continued to run, just as uhttpd was.

2

How exactly did you open them? The details here are critical.

Post your firewall config file so we can understand exactly what you have done.

1 Like
3 
config defaults
	option synflood_protect '1'
	option input 'DROP'
	option output 'DROP'
	option forward 'DROP'

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

config zone
	option name 'wan'
	option output 'ACCEPT'
	option mtu_fix '1'
	option input 'DROP'
	option network 'wan'
	option forward 'DROP'

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'
	option enabled '0'

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

config rule
	option name 'Forward Ping'
	list proto 'icmp'
	option dest 'lan'
	option target 'ACCEPT'
	option src 'wan'

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

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'
	option enabled '0'

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'
	option enabled '0'

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'
	option enabled '0'

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'
	option enabled '0'

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

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

config rule
	option name 'Support-UDP-Traceroute'
	option src 'wan'
	option dest_port '33434:33689'
	option proto 'udp'
	option family 'ipv4'
	option target 'REJECT'
	option enabled '0'

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

config zone
	option forward 'DROP'
	list network 'mng'
	option name 'mng'
	option output 'ACCEPT'
	option input 'ACCEPT'

config rule
	option name 'isolated webui'
	option src 'mng'
	list src_ip '192.168.90.110'
	list dest_ip '192.168.200.1'
	option dest_port '443'
	option target 'ACCEPT'

config rule
	option name 'isolated dns'
	option src 'mng'
	list src_ip '192.168.90.110'
	list dest_ip '192.168.200.2'
	option dest_port '53'
	option target 'ACCEPT'

config rule
	option name 'isolated ssh'
	option src 'mng'
	list src_ip '192.168.90.110'
	list dest_ip '192.168.200.2'
	option target 'ACCEPT'
	option dest_port '22'

config rule
	option name 'isolated NTP'
	option src 'mng'
	list src_ip '192.168.90.110'
	option dest_port '123'
	option target 'ACCEPT'
4

Remove these.

Also, is the host that is initiating the connections using 192.168.90.110 as mf is that part of your management network?

1 Like
5

The 192.168.200.0/24 net is the mng net, the one being accessed by the host 192.168.90.110. There is also a subnet 192.168.90.0/24 that is on the wan interface.

6

So your host is not on the management network, yet you are setting a firewall rule that only accepts connections from source=management. That will not work. Set the source to the correct zone (ie the lan) and it should work.

1 Like
7

psherman, thank you. Yeah, your questions made me re-think this. The luci connection must come from the lan, so I have reconfigured the firewall to listen for 443 on the lan (192.168.90.110) rather than the mng.

EDIT: I fixed ssh logins also, for the same reason. My router is now working precisely how I was picturing, so thank you so much.

8

It is uhttpd, dropbear, dnsmasq and odhcp that is the basic system management. A interface can’t be system management.

In the firewall rules the system management is defined as “device”. When you block Input you bloc traffic from the Interface to device and you loose control.
Therefore you must open the “mgmt ports” from your designated mgmt interface to “device” in the firewall.

9

Thanks, this issue has been marked as solved.

10

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