form 2.4.3 upgrade 2.4.4rc20180904 can't open gateway GUI

yon 0

i have no find the clog / folder
find the
/var/log/system.log show:

l as up/active. (Group: dn42v6)
Sep 12 02:54:28 face php-fpm[45489]: /rc.filter_configure_sync: GATEWAYS: Group dn42v6 did not have any gateways up on tier 1!
Sep 12 02:54:28 face php-fpm[45489]: /rc.filter_configure_sync: Gateways status could not be determined, considering all as up/active. (Group: dn42v4)
Sep 12 02:54:28 face php-fpm[45489]: /rc.filter_configure_sync: GATEWAYS: Group dn42v4 did not have any gateways up on tier 1!
Sep 12 02:54:30 face xinetd[87501]: Starting reconfiguration
Sep 12 02:54:30 face xinetd[87501]: Swapping defaults
Sep 12 02:54:30 face xinetd[87501]: readjusting service 19000-tcp
Sep 12 02:54:30 face xinetd[87501]: readjusting service 19003-tcp
Sep 12 02:54:30 face xinetd[87501]: readjusting service 19005-tcp
Sep 12 02:54:30 face xinetd[87501]: readjusting service 19006-tcp
Sep 12 02:54:30 face xinetd[87501]: readjusting service 19007-tcp
Sep 12 02:54:30 face xinetd[87501]: readjusting service 19008-tcp
Sep 12 02:54:30 face xinetd[87501]: readjusting service 19009-tcp
Sep 12 02:54:30 face xinetd[87501]: readjusting service 19010-tcp
Sep 12 02:54:30 face xinetd[87501]: readjusting service 19011-tcp
Sep 12 02:54:30 face xinetd[87501]: readjusting service 19012-tcp
Sep 12 02:54:30 face xinetd[87501]: readjusting service 19001-tcp
Sep 12 02:54:30 face xinetd[87501]: readjusting service 19004-udp
Sep 12 02:54:30 face xinetd[87501]: readjusting service 19013-tcp
Sep 12 02:54:30 face xinetd[87501]: readjusting service 19014-tcp
Sep 12 02:54:30 face xinetd[87501]: readjusting service 19015-tcp
Sep 12 02:54:30 face xinetd[87501]: readjusting service 19002-tcp
Sep 12 02:54:30 face xinetd[87501]: readjusting service 19005-udp
Sep 12 02:54:30 face xinetd[87501]: readjusting service 19006-udp
Sep 12 02:54:30 face xinetd[87501]: readjusting service 19012-udp
Sep 12 02:54:30 face xinetd[87501]: readjusting service 19016-tcp
Sep 12 02:54:30 face xinetd[87501]: readjusting service 19017-tcp
Sep 12 02:54:30 face xinetd[87501]: readjusting service 19018-tcp
Sep 12 02:54:30 face xinetd[87501]: readjusting service 19018-udp
Sep 12 02:54:30 face xinetd[87501]: readjusting service 19019-tcp
Sep 12 02:54:30 face xinetd[87501]: readjusting service 19020-tcp
Sep 12 02:54:30 face xinetd[87501]: readjusting service 19021-tcp
Sep 12 02:54:30 face xinetd[87501]: readjusting service 19022-tcp
Sep 12 02:54:30 face xinetd[87501]: readjusting service 19023-tcp
Sep 12 02:54:30 face xinetd[87501]: readjusting service 19024-tcp
Sep 12 02:54:30 face xinetd[87501]: readjusting service 19025-tcp
Sep 12 02:54:30 face xinetd[87501]: Reconfigured: new=0 old=30 dropped=0 (services)
Sep 12 02:54:30 face php-fpm[322]: /rc.filter_configure_sync: Gateways status could not be determined, considering all as up/active. (Group: dn42v4)
Sep 12 02:54:30 face php-fpm[322]: /rc.filter_configure_sync: GATEWAYS: Group dn42v4 did not have any gateways up on tier 1!
Sep 11 21:26:17 face php-cgi: rc.bootup: The command '/usr/local/sbin/nginx -c /var/etc/nginx-webConfigurator.conf' returned exit code '1', the output was 'nginx: [emerg] invalid port in resolver "2a05:dfc7:5::53" in /var/etc/nginx-webConfigurator.conf:42'
Sep 11 21:26:17 face kernel: done.

Sep 11 21:20:03 face pkg: nginx reinstalled: 1.14.0_6,2 -> 1.14.0_6,2
Sep 11 21:20:03 face pkg: mtr-nox11 reinstalled: 0.92 -> 0.92
Sep 11 21:20:03 face pkg: mpd5 reinstalled: 5.8_7 -> 5.8_7
Sep 11 21:20:03 face pkg: mobile-broadband-provider-info reinstalled: 20170310 -> 20170310
Sep 11 21:20:03 face pkg: miniupnpd reinstalled: 2.0.20180503,1 -> 2.0.20180503,1

Gertjan

There you go :

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

1 21:26:17 face php-cgi: rc.bootup: The command '/usr/local/sbin/nginx -c /var/etc/nginx-webConfigurator.conf' returned exit code '1', the output was 'nginx: [emerg] invalid port in resolver "2a05:dfc7:5::53" in /var/etc/nginx-webConfigurator.conf:42'

What I make of it :
nginx is not happy - see also the config file /var/etc/nginx-webConfigurator.conf - line 42

Because : see the line before nfinx complaing : some gateway issue.
Because : I presume some interface trouble.

What is this : "mobile-broadband-provider-info" ?

yon 0

@gertjan
What I make of it :
nginx is not happy - see also the config file /var/etc/nginx-webConfigurator.conf - line 42

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;

Gertjan

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

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;

Really ?

This line just can't be in this file : /var/etc/nginx-webConfigurator.conf

I checked the code where /var/etc/nginx-webConfigurator.conf is build, and no way a

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;
is injected.

Check line 1444 and further along in /etc/inc/system.inc.

Use option 11 ( Restart webConfigurator) or even option 1) Re asign the interfaces to make a clean start.

edit : show the /var/etc/nginx-webConfigurator.conf file please.
If the file is hosed, consider the disk in bad shape, or worse.

Grimson

@Gertjan
I guess yon-0 is the new account of https://forum.netgate.com/user/yon in that case be prepared to spend a lotof time here.

yon 0

@gertjan

i try edit the /cf/conf/config.xml and /var/etc/nginx-webConfigurator.conf file, deleted the 2a05:dfc7:5::53 and dn42 gateway, still not work. maybe i should try reset config and import again ?

yon 0

@grimson

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.