Fixes #3510. Sorry for all the comments in function is_blank_or_posint_string($strvar) - but this validation stuff is a real pain in PHP. "0" being empty and false, and all the various is_int is_numeric ctype_digit functions that do some unexpected things when passed (int) (float) (boolean) and (string) types. And in this case we really do want to accept just strings of digits from 0 to 9 without any leading zero. We don't want any fancy forms or casts of numbers to slip in somehow. The tests in function is_aoadv_used($rule_config) had to be changed back from using empty() to use $var != "" because if the user enters "0" in one of those fields and presses save, they get an error message, but the Advanced Options block on the GUI is closed (the "0" was considered empty()). That seemed rather confusing - the user had to click on the Advanced Options "Advanced" button again to open up that block and see the "0" they had entered. I have prohibited 2 things that "pf" allows into the ruleset without generating an error: (max 0) (tcp.established 0) Both of these seem (IMHO) to have no valid use case. They would prevent states from ever happening, and so would effectively be block rules, which could be implemented easily as block rules. But let me know if there is some valid use case, and I will have to allow "0" in those fields.
Currently, if there are some settings defined in Firewall Rules Edit, Advanced Features, Advanced Options, the Advanced Options section is left minimized when the Firewall Edit screen is displayed. This makes it easy for a user to not notice that there are some Advanced Options settings. This change makes the Advanced Options section be displayed if any of the settings are defined, in the same way it is done for all the other Advanced Features sections.
Tested this making a new rule, and editing existing IPv4, IPv6 and IPv4+Ipv6 rules, and switching the IP version on an existing rule. Seems to work!
While I notice this also, for a plain gateway, the current IP address is also listed in the dropdown list text, like "WAN_DHCP - 10.42.11.1". If there is no IP address currently, it might say "WAN_DHCP - dynamic". But for some DHCP gateways that have not had any non-default manual settings done, it can say "OPT1_DHCP -". This gets rid of the silly-looking "-"
Now return_gateway_groups_array() always returns at least the IP version 'ipprotocol' of each GWG, even if all its members are down at present. It is better to use this to check what IP version the GWG is. The previous check was using the IP address of the first member of the GWG to deduce 'ipprotocol'. That would fail if the WAN was DHCP and was down.
This is a resubmit of an older pull request I had closed. It came up again in the forum, with a user setting up a VM environment and wondering why he cannot make policy-routing rules to a gateway group. The gateway group names did not display because all his WANs were down at the time and so the existing code was too dumb to determine the IP protocol (version 4 or 6) when none of the WANs in the gateway group actually have an IP address yet.
…ugin of StrongSWAN. No need to go through the setkey dumps
…ified and attributes. Probably should be made the default due to its speed.
Port dropdowns: Put port no. after descrip
At the moment, even if a port number is entered, it's re-displayed only as a port name when editing. Users who don't have port names -> numbers lookup memorised can't easily confirm when editing a rule, that the port is as intended. Then, when they return to firewall_rules.php the same rules have ports displayed as numbers not names (inconsistent). This small UI edit changes the port dropdowns from just the name "NetBIOS-NS" to "NetBIOS-NS (137)" and shows the very well known port number, for ease of use.
…ipsec.secrets to be properly considered
* Use proper commands to reload strongswan rather than just the daemon
Fix #3483 only use IPv4 DNS servers in DHCP v4 conf
…plicate it to slave
…and to use the local DB for this. Otherwise detect if the remote says the voucher is not valid say its not valid.
…While here respect the redirurl when passed to portal_allow and use proper function to do redirection.
Tighten is_subnet() functions