form 2.4.3 upgrade 2.4.4rc20180904 can't open gateway GUI

yon 0

what's mean? so old pfsense forum site close and i am come here.

Gertjan

@yon-0 said in form 2.4.3 upgrade 2.4.4rc20180904 can't open gateway GUI:

@grimson

what's mean? so old pfsense forum site close and i am come here.

What he meant to say is :
You missed the mail and thousands of messages on this new forum telling that pfSense has a new forum.
https://www.netgate.com/blog/introducing-the-netgate-forum.html

Your 'original' account still exists ... we were all forced to make a new password, that it. No need to create an new account.

@Grimson : Ohhh, yes : https://forum.netgate.com/user/yon was even discussing with @doktornotor (I actually miss him ^^) in the old days ... I'll save the link for later reading - having some fun.

yon 0

@gertjan

well.., i never seen that news and i had some time no visit old forum. so i have to creat new account when i come the new forum.

Gertjan

You still have access to your old account.
Visit Lost your password ?, type in your email and instructions how to make a new password are send to you right away.
Just try it out. It's soooo easy.

yon 0

i have to reback pf 2.4.3 just work. Can i upgrade the frr to 5.0.1 with pf 2.4.3?

jimp

No, you cannot use 2.4.4 packages on 2.4.3. Load the pfSense 2.4.4-RC and keep trying to figure out what is happening that prevents it from working for you.

If a problem doesn't get found and fixed in the snapshots or RC it will still be a problem in the release. But since nobody else is hitting that issue but you, you need to do some debugging to figure out what is wrong with your configuration that triggers the problem.

yon 0

@jimp i true have no find the reason. i have to back 2.4.3 is work

yon 0

@jimp i can send config and log files. new 2.4.4 still cant open webgui.

Gertjan

@gertjan said in form 2.4.3 upgrade 2.4.4rc20180904 can't open gateway GUI:

/var/etc/nginx-webConfigurator.conf

Can you show us this file :
/var/etc/nginx-webConfigurator.conf

?

yon 0

# nginx configuration file

pid /var/run/nginx-webConfigurator.pid;

user  root wheel;
worker_processes  2;
error_log  syslog:server=unix:/var/run/log,facility=local5;

events {
    worker_connections  1024;
}

http {
	include       /usr/local/etc/nginx/mime.types;
	default_type  application/octet-stream;
	add_header X-Frame-Options SAMEORIGIN;
	server_tokens off;

	sendfile        on;

	access_log      syslog:server=unix:/var/run/log,facility=local5 combined;
	keepalive_timeout 75;

	server {
		listen 2253 ssl http2;
		listen [::]:2253 ssl http2;

		ssl_certificate         /var/etc/cert.crt;
		ssl_certificate_key     /var/etc/cert.key;
		ssl_session_timeout     10m;
		keepalive_timeout       70;
		ssl_session_cache       shared:SSL:10m;
		ssl_protocols   TLSv1.1 TLSv1.2;
		ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
		ssl_prefer_server_ciphers       on;
		add_header X-Content-Type-Options nosniff;
		ssl_session_tickets off;
		ssl_dhparam /etc/dh-parameters.4096;
		ssl_stapling on;
		ssl_stapling_verify on;
		resolver 202.141.162.123 2001:19f0:7402:d:5400:00ff:fe2a:7fb6 1.1.1.1 2001:41d0:8:be92::1 valid=300s;
		resolver_timeout 5s;

		client_max_body_size 200m;

		gzip on;
		gzip_types text/plain text/css text/javascript application/x-javascript text/xml application/xml application/xml+rss application/json;

		root "/usr/local/www/";
		location / {
			index  index.php index.html index.htm;
		}
		location ~ \.inc$ {
			deny all;
			return 403;
		}
		location ~ \.php$ {
			try_files $uri =404; #  This line closes a potential security hole
			# ensuring users can't execute uploaded files
			# see: http://forum.nginx.org/read.php?2,88845,page=3
			fastcgi_pass   unix:/var/run/php-fpm.socket;
			fastcgi_index  index.php;
			fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
			# Fix httpoxy - https://httpoxy.org/#fix-now
			fastcgi_param  HTTP_PROXY  "";
			fastcgi_read_timeout 180;
			include        /usr/local/etc/nginx/fastcgi_params;
		}
		location ~ (^/status$) {
			allow 127.0.0.1;
			deny all;
			fastcgi_pass   unix:/var/run/php-fpm.socket;
			fastcgi_index  index.php;
			fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
			# Fix httpoxy - https://httpoxy.org/#fix-now
			fastcgi_param  HTTP_PROXY  "";
			fastcgi_read_timeout 360;
			include        /usr/local/etc/nginx/fastcgi_params;
		}
	}
	server {
		listen 80;
		listen [::]:80;
		return 301 https://$http_host:2253$request_uri;
	}
}

Gertjan

Ok, found something.

When asking for certicate, you checked

OCSP Must Staple
Add the OCSP Must Staple extension to the certificate.

This produces in 2.4.4 some extra config lines for nginx :

@yon-0 said in form 2.4.3 upgrade 2.4.4rc20180904 can't open gateway GUI:

  ssl_stapling on;
  ssl_stapling_verify on;
  resolver 202.141.162.123 2001:19f0:7402:d:5400:00ff:fe2a:7fb6 1.1.1.1 2001:41d0:8:be92::1 valid=300s;
  resolver_timeout 5s;

I just asked also for a stapled certificate.
So, no my nginx config show :

                ssl_stapling on;
                ssl_stapling_verify on;
                resolver 127.0.0.1 valid=300s;
                resolver_timeout 5s;

and ... my GUI works very well.

I use the default Resolver.
You use some "other DNS".

For the time being, your have severals options to get your GUi back :
Ask for a new certicate, without the OCSP Must Staple option (dono how that can be done without GUI access ^^).
Or blow away your DNS ( these "202.141.162.123 2001:19f0:7402:d:5400:00ff:fe2a:7fb6 1.1.1.1 2001:41d0:8:be92::1" ) - thuis can be done with the command viconfig - or export /conf/config.xml and it it.
Or reset to default, redo your config,

Now for plan Z :
The pfSense code (this file : /etc/inc/system.inc) doesn't set up the parameters for the "resolve" line correctly , this one :

resolver 202.141.162.123 2a05:dfc7:5::53 2001:19f0:7402:d:5400:00ff:fe2a:7fb6 1.1.1.1 2001:41d0:8:be92::1 valid=300s;

nginx became recently OSCP staple-aware, and a quick search on the net learns us :

resolver 202.141.162.123 [2a05:dfc7:5::53] [2001:19f0:7402:d:5400:00ff:fe2a:7fb6] 1.1.1.1 [2001:41d0:8:be92::1] valid=300s;

... the [] to delimit IPv6 addresses are missing !!! ( this is the bug)
( /etc/inc/system.inc needs a small edit )

So, I recap :
Use the default DNS - the resolver - and you'll be happy.
and/or
OCSP Must Staplede activate and ask a new cerificate - and remove the option OSCP .... in Menu System => Advanced => Admin Access

and you will get your GUI back.

yon 0

@gertjan

yes, you are smart. i delete these ipv6 dns ip just can open webGUI, but why 2.4.43 can work and 2.4.4 down?

and show system Crash Reporter how i submit it ?

0_1537870578749_Screenshot Diagnostics_ Crash Reporter.jpg

Gertjan

@yon-0 said in form 2.4.3 upgrade 2.4.4rc20180904 can't open gateway GUI:

i delete these ipv6 dns ip just can open webGUI, but why 2.4.43 can work and 2.4.4 down?

Because 2.4.4 includes a newer "nginx" and/or pfSense exposes an option now that can handle OSCP Stapling for the GUI (and captive portal).
The integration was done without testing IPv6 resolver addresses (otherwise the author would have found the loss of the GUI right away ).

No need to send over the crash report. The bug has been identified.
I'lll put it on my todo list - prepare a Issue on redmine here.

Gertjan

This is what I'm running right now :

Instead of the present ( pfSense 2.4.4 Release - /etc/inc/system.inc - appr line 1460 - function system_generate_nginx_config() ) :

		if (($config['system']['webgui']['ocsp-staple'] == true) or
		    (cert_get_ocspstaple($cert_temp['crt']) == true)) {
			$nginx_config .= "\t\tssl_stapling on;\n";
			$nginx_config .= "\t\tssl_stapling_verify on;\n";
			$nginx_config .= "\t\tresolver " . implode(" ", get_dns_nameservers()) . " valid=300s;\n";
			$nginx_config .= "\t\tresolver_timeout 5s;\n";
		}

I use :

		if (($config['system']['webgui']['ocsp-staple'] == true) or
		    (cert_get_ocspstaple($cert_temp['crt']) == true)) {

			$nginx_resolver_list ='';
			$dns_nameservers_array = array();
			$dns_nameservers_array = get_dns_nameservers();
			foreach ($dns_nameservers_array as $dns_nameserver) {
				if (is_ipaddrv6($dns_nameserver))
					$nginx_resolver_list .= '[' . $dns_nameserver . '] ';
				else
					$nginx_resolver_list .= $dns_nameserver .' ';
			}

			$nginx_config .= "\t\tssl_stapling on;\n";
			$nginx_config .= "\t\tssl_stapling_verify on;\n";

			$nginx_config .= "\t\tresolver " . $nginx_resolver . " valid=300s;\n";
			$nginx_config .= "\t\tresolver_timeout 5s;\n";
		}

The DNS server list obtained by get_dns_nameservers() is concatenate and separated by a space,
and IPv6 addresses are surrounded with brackets [].
Like this

resolver 127.0.0.1 [::1]  valid=300s;

nginx is happy now and doesn't blow out of the water when DNS IP's are IPv6.

yon 0

@gertjan said in form 2.4.3 upgrade 2.4.4rc20180904 can't open gateway GUI:

Instead of the present ( pfSense 2.4.4 Release - /etc/inc/system.inc - appr line 1460 - function system_generate_nginx_config() ) :

YES, this is had fix in PF2.4.4 ?

Gertjan

@yon-0 said in form 2.4.3 upgrade 2.4.4rc20180904 can't open gateway GUI:

@gertjan said in form 2.4.3 upgrade 2.4.4rc20180904 can't open gateway GUI:

Instead of the present ( pfSense 2.4.4 Release - /etc/inc/system.inc - appr line 1460 - function system_generate_nginx_config() ) :

YES, this is had fix in PF2.4.4 ?

My "fix" should be applied for 2.4.4 Release, nothing else.
Didn't redmine it yet,and as said here Pfsense Bug report, where to send?, I like to have some reactions back, like, why not, yours, after you used the patch.
The bug-squash team has raised DEFCON 1 lately, they have bigger bugs to nail right now.

Anyway, these are my DNS servers right now :

0_1537973616367_227bfd00-58c7-44cd-b57d-09cb73b1217c-image.png