How to best access internal web interface?
-
So I have this Netgear managed switch with web interface, which occasionally I need to remote manage.
Needless to say, it does not support https and as a result restricts access to the web interface to the LAN IPs.
If everything works just fine, I can do an RDP or VNC session to a machine on the LAN, open a browser there, and do my work. Of course, when does one need to access the interface? Yes, of course when things don't work, and that's when RDP/VNC will stop working, too.
I had the glorious idea to install lynx, links, elinks on my pfSense box, such that I would be able to log into the pfSense box with ssh, escape to the shell, and then call these text based browsers to access the switch, and all would be fine.
Unfortunately, that's not the case, as Netgear isn't capable of doing their simple UI without JavaScript, and these text browsers don't do that. There would be browsh, another text based browser, which does JS, but it requires that somewhere on the system Firefox be installed, and needless to say, that would require installing so many dependencies (incl. X11!) on pfSense, as to be ludicrous and also not advisable for security reasons. So browsh isn't an option either.
Of course it would be cool if pfSense had a browser-in-browser module that would allow authenticated users to access some other web interface from the pfSense admin web interface. But that doesn't exist, either.
So what's the best way of getting straight at an internal web browser that will only serve content to LAN IPs?
Note I'm NOT running a NAT setup, I'm using pfSense simply as a router and firewall in the sense of it doing sanity checks on the connections.
So I need a solution that fakes local access from the LAN to a embedded web server, while being somewhere on the internet. Either by something I can enable on an as needed basis in pfSense's web interface, which doesn't have to be particularly secure, or some quasi-permanent setup, that's secured, e.g. some sort of ssh tunnel of sorts.
What would be best practice to achieve this?
-
The best way to do it is VPN into pfSense and access it from there.
You could also SSH tunnel to pfSense.
If it really can't respond to anything outside it's own subnet you can add a very specific outbound NAT rule for traffic from the VPN subnet to the switch so it's translated to the correct subnet.
Links is installed by default BTW. Not that it helps you here.
Steve
-
Thanks for the hints. The VPN/NAT thing is a bit iffy because, and I mentioned to write that, my WAN link is actually going over a VPN, so IPSec grabs all sorts of things before the usual pfSense functionality has a go at getting to the packets. Yeah, screwy, but that's when you get if your ISP refuses/is-incapable-of routing a customer owned block of IP addresses...
I for the time being solved this with an stunnel setup, it's ugly, and of course not secure, because anyone can access that port, and it's like they were accessing the switch on the LAN and they could do a brute force password attack.
Since I need this rarely, and access to the router is prerequisite for remote management anyway, I'll simply enable/disable that stunnel as needed. But it's still kind of ugly.
Links is great, but Netgear sucks, because they, of all companies, didn't test their UI being usable with links, and them using javascript or something else, which breaks links, which is dumb: the think links is predestined for, web-based admin interfaces, doesn't work, because they failed to test that primitive web interface for a managed switch with links <facepalm>... If a sophisticated web interface like pfSense doesn't work with links I'm not surprised, but something as trivial as what Netgear has, arghh...
Anyway, I have a hack of a solution for the time being,
-
Now I'm stumped. The switch in question is between my pfSense box (one of these Netgate Minnowboard/Atom units with two NICs, one for WAN, one for LAN/Guest with VLAN1/2) and the rest of the internal net.
The Netgear unit is configured to have port 1 as uplink port with tagged membership in VLAN1 and VLAN2, default PVID1, and the rest of the ports are either untagged VLAN1 or VLAN2.
The IP Address of the Netgear switch is in VLAN1's range.
Now the odd thing: when I disable VLAN on the LAN/GUEST port, I can access the Netgear switch from the pfSense box, when I enable VLAN, I can't access the Netgear switch from the pfSense box, but I can still access it from the LAN aka VLAN1, despite the fact that the pfSense' IP is on the same subnet as VLAN1 and my LAN.
So e.g.
pfSense:
port 0: DHCP-WAN
port1-VLAN1: 12.34.56.254 (LAN)
port1-VLAN2: 10.0.0.254 (GUEST)VLAN1 (LAN): 12.34.56.x/24
netgear: 12.34.56.246
server on VLAN1: 12.34.56.1VLAN2 (GUEST): 10.0.0.x/24
Access from VLAN2 to netgear: impossible, as expected
Access from "inside" VLAN1 to netgear: possible, as expected
Access from pfSense unit to netgear: impossible, unexpectedSo:
FULL access to 12.34.56.246 from 12.34.56.1
FULL access to 12.34.56.254 from 12.34.56.1
FULL access to 12.34.56.1 from 12.34.56.254
ZERO access to 12.34.56.246 from 12.34.56.254Is this an issue with the netgear box, an issue with pfSense (in my case 2.5.0-dev), or a lack of my understanding of how VLANs work?
I mean, for now, key thing is network traffic seems to flow as it should between WAN and LAN/GUEST, but I like to understand what's going on, so this isn't something that comes back biting me in the ass later on when least expected.
-
Never use VLAN1. You can't be sure what switches will do with it.
Here it look like you probably can't actually tag VLAN1 leaving the switch ports. It's quite surprising that it allows you to try. Most switches would not.
pfSense allows you to use it because technically it's valid but:
https://docs.netgate.com/pfsense/en/latest/vlan/security.html#using-the-default-vlan1Steve