OPNsense Forum
Archive => 15.7 Legacy Series => Topic started by: phoenix on August 27, 2015, 01:18:52 pm
-
I was messing around with some configuration changes today and found the following problem. I have three NICs installed (in a VM) one each for the WAN, LAN & OPT1 - I use OPT1 to connect to the web ui and as an Admin that isn't the default "root" account.
I logged in as usual via OPT1 as the non-root Admin, I then disabled the LAN interface and the Web UI is not contactable - is this expected behaviour or should I still be able to manage the server if the LAN is down?
Another side effect of this was that I couldn't then login to the console as the non-root admin but I could login as the 'root' admin. If I tried to login as non-root admin I saw the following message:
This account is currently not available
Is this also expected behaviour?
This is with the current 15.7.11 version but it also happened with prior versions, I'm afraid I've only just got around to testing this on my live OPNsense install.
-
Interesting, I'll add another issue to investigate: https://github.com/opnsense/core/issues/356
User accounts need shell access privileges in order to login, that's normal, but if they are in the admins group maybe that isn't set properly. Does adding the privilege as a single option help there?
The non-root admin and the LAN are two distinct issues in any case.
-
@phoenix
If you have the time, could you dump some lines from the pf config on the forum?
I'm especially interested if your OPT rules have something like this in them:
pass in on $WAN reply-to ( em1 192.168.192.1 ) ....
If the packet tries to go back via a gateway, it could be logical that you can't access the page anymore. (although it can still be a bug if you can't switch it off)
The rules should be in /tmp/rules.debug, you can probably grep them with:
grep "OPT" /tmp/rules.debug
-
The only entries in that file are the following:
OPT1 = "{ vmx2 }"
scrub on $OPT1 all no-df fragment reassemble
antispoof log for $OPT1
pass in quick on $OPT1 inet proto tcp from any to any flags S/SA keep state label "USER_RULE"
Does that help?
@franco - I'll take a look at your question tomorrow, if that's OK.
-
Hi Bill,
Thanks for checking, its probably is related to lighthttp.
I will update the issue.
Cheers,
Ad
-
User accounts need shell access privileges in order to login, that's normal, but if they are in the admins group maybe that isn't set properly. Does adding the privilege as a single option help there?
Hi Franco
Sorry about the late reply. You can put this login problem down to a dumb user error (me), I could have sworn I had that setting in there but it must have been while I was testing it on my workstation. I seem to have lost/removed that option between testing and moving it into production. I also assumed that it was because of the LAN NIC going down that was causing this problem, sorry about the noise.
Just as an additional comment about the NIC settings, would it be useful to have a restart option in the Web UI for a NIC or is there a specific reason it's not included?
-
No worries, Bill. I like one problem better than two. :)
Ad is taking over the LAN disable. Almost ready to sign off for 10 days.
-
Hi Bill,
This should be fixed since 15.7.22, we've seen quite a few obscure reports being resolved due to fixing the filter reloading. :)
Cheers,
Franco
-
Hi Franco
Unfortunately this behaviour still happens as I described in my original post. It's always reproducible, if you need me to provide anything specific about this problem then let me know.
-
Okay, one down, on to go then, thanks.
-
I just tried this, added 168.192.77.1/24 to OPT1 (LAN is on an unconventional 10.0.0.1/16 setup).
I connected to 192.168.77.1 from my local device, went to [LAN], disabled it, saved, reloaded the configuration from the dialog.
The GUI was still available on 192.168.77.1. I switched LAN back on while connect to OPT1. Went back to LAN with my device. Everything was like it was supposed to.
Just how does that test differ from yours? There must be something different about your approach.
Thanks for your help.
-
Hi Franco
The difference in my test is that my LAN & OPT1 are on the same subnet i.e. 192.168.1.1 for the LAN and 192.168.1.240 for OPT1 - they're both fixed IPs and the WAN is fixed but picked up by DHCP for IPv4 & IPv6 (if that's relevant in this case).
-
It seems logical that shutting down LAN (192.168.1.1) makes your GUI unavailable there. I don't know about the oddities of your setup as it surprises me, but by that same logic the GUI ought to be available from 192.168.1.240 as well?
-
Yes, I tried it from both connections and obviously the LAN goes away if I'm on that NIC but I wouldn't have expected it to disappear if I use OPT1. In fact, the only way to get this back is a reboot, it's a VM running on an ESXi 6 server and has VMXNET3 NICs installed but I don't think there's anything odd about this set-up and there's also very few rules in the firewall. For various reasons I did a clean install of the current 15.7.22 and that had the same problem.
This isn't really a big problem for me, just an oddity. It would be interesting to know if anyone else can reproduce it.
-
It's odd in the sense that assigned interfaces are (as far as I have come across) exclusive subnets (OPT1 is actually located inside LAN if you look at it from an IP network perspective, not physical connections). This creates an interesting situation where applying a policy to LAN will not work for OPT1. I would have expected the GUI to refuse this setup outright.
Some piece of code doesn't play well with this, but I think it's fixable. It's the first problem I've heard for such setups so it's worth fixing. :)
-
Sorry, my bad. The LAN is a /24 and the OPT1 is probably a single IP. I say 'probably' there as I not added an OPT1 after my testing the other day, I'll try it again tomorrow and see what happens and make sure that what I've told you here is correct. :)