@petri said in webGUI not accessible from VLAN but ...:

Client connected to em2 cannot access to GUI if em1 doesn't have an active connection

Normally you would have interfaces connected to a switch, and not some single device.. But if an interface is not up then no you wouldn't be able to connect to its up, because the interface is not up..

https://docs.netgate.com/pfsense/en/latest/multiwan/policy-route.html#policy-routing-configuration

Why would you not just fix whatever it is your wanting to happen on lan interface not doing what you want for your vpn??

@johnpoz and @bingo600

Thank you! That did the trick.

@johnpoz Thank you so much, now im working on it, i was able to see that the rules on wan settings was gone and a new rule was created on the LAN settings..

THanks,
joe

UPDATE:

I've been doing some tests trying to know where the problem is and it seems that finally it comes from WAN interface. I configured first WAN but until I configured the IPSEC tunnels the problem didnt appear.

Today I reinstall a fresh pfsense and first of all I configured the tunnels with no problems and when I configured the WAN the problem start. If I enable WAN with DHCP or Static IP without a gateway it works everything fine, when I choose a IPv4 Upstream gatewy then return the problem.

At this point this topic can be closed.

@gertjan I will attempt this tonight and report back. Thanks.

@publictoiletbowl

You mean the status monitoring page ?

You have access to the page, but .... the page builder, PHP; is probably using commands that need root/admin access.

@gertjan Did as you suggested and turned off the Wireguard tunnel and the web page response time improved dramatically, unless I tried to go to: Status/ Wireguard - which was still slow.
Memory usage is at 12% and cpu at 33%.
It simply appears to be very slow in pulling data from the Status of the Wireguard peers and displaying this data on a web page.

@jimmychoosshoes The UI display and filter only handles 10.000 logentries from the current logfile/rotation. If your current logfile is much larger than 10.000 lines, it becomes REALLY slow to load.

If you want lots of log retention, create a MUCH bigger rotation and use smaller logfiles. This will make the UI much faster since the 10.000 lines does not require loading a 400Mb file. This way you still have a lot of retention.

The only drawback (regardless of which settings you use) is you can’t find older log entries from the UI as that only goes back 10.000 lines in the combined log rotation. So the remaining rotation logs can only be searched from the CLI or som external tool.

I’m still hoping a log analysis/parsing package will be created for pfSense, or that Netgate will create an option for letting the UI filter feature go MUCH further back than 10.000 lines.

ntopng, darkstath, bandwidthd probably there are other packages now that can give you a better log view, idk, personally i send everything to grafana and i let the firewall do the firewall.

@jimp said in Firewall filter LOG, GUI search and Circular logging:

It's partially a holdover from the days when clog could rarely have more than a few thousand lines and partially because parsing that many filter log lines can be a burden on the firewall so it is limited so it doesn't put undue strain on the system.

You can increase it on your own by editing the line at https://github.com/pfsense/pfsense/blob/master/src/etc/inc/syslog.inc#L705

We haven't come to a decision on what the best course of action is there overall.

Okay - that is very good to know. I think you should make a GUI setting for limiting how far it goes back - with a memory use estimator explaining the consequenses of increasing it (Just like you do where you can edit the current log file size in diskspace terms).

Alternatively there should be developed a dedicated log processing and analytical package people can install if they have CPU/memory enough.

@ddbnj When you have a screen that can show all the content this is what you get. Without the redaction square, of course.

Screen Shot 2022-08-09 at 5.03.00 PM.png

Common knowledge applies for pfSense !

So, go to /usr/local/www/css/ and copy the standard style sheet 'pfSense.css' to your own :

[22.05-RELEASE][root@pfSense.did-I-mess-up-again.net]/usr/local/www/css: cp pfSense.css MyOwnStyle.css

And now you'll see :

837dbcb3-ff12-4970-88a8-727f7a5b1586-image.png

Open MyOwnStyle.css and another one, like pfSense-dark-BETA.css as an example, and now you can control whatever you want.

If something goes horribly wrong : undo your edits.
Still wrong ? Select the "pfSense" theme in the GUI and problem solved.

@jonofmac said in WebGUI redirects to wrong domain:

but chrome doesn't use it

Pfsense isn't a webserver - it has a gui served up by nginx sure, with really no access to those settings other then redirect 80 to https port, etc.

But you could most likely just setup haproxy to what you want.. You can do redirection there..

You might be able to directly edit the files on pfsense to put in a redirect to whatever fqdn you want, etc.

But it takes what .03 seconds to type in pfsense.home.domain.com ;) Not using fqdn is a bad habit - you should break yourself of.. Webservers shouldn't answer to just hostnames either..

So pfsense.home.domain.com resolves to a public IP.. Why are you worried about redacting some rfc1918 address. My lan IP of pfsense is 192.168.9.253 - what would you do with that info??

@johnpoz Thanks for the reply. I had tried Edge and Brave to get into the system. Out of curiosity, I switched Edge to Internet Explorer mode, and it worked. Checking setting on my browsers now.

@cool_corona I really do appreciate your input and ideas but I've only provided part of the information and the business case as I didn't feel in warranted explaining. In summary with 150 desktop/laptops in the estate and the impact of Teams A/V on our centralised infrastructure it was much more cost effective to move our hosting requirements online rather than hosting internally as we had been doing. We were at a point where the server estate needed major investment which wasn't a viable or sustainable option. So going back to a Terminal Server/VDI solution is off the cards just so we can manage the network.

Irrespective of my particular circumstances, the key 'positive' thing here is that netgate/pfSense has now matured to such an extent that much larger deployments use cases are being considered. To break into the next market, they need to consider the ease on managing an 'estate' rather than an 'individual' devices. I don't mean that to be a slur on netgate/pfSense in any way. Many companies out there have great products but get to a point where chasing the 'next new thing' out weighs the more mundane tasks on optimising the less glamorous management functions larger/complex organisations require.