OpenVPN create the tun/tap interface and, when set an IP address to
it, mark it as UP. In some scenarios, when TAP is set as bridge and
doesn't have an IP address set on it, it never goes up and tunnel
doesn't work.
If rc.newwanip is called for this TAP interface, UP flag is set, but,
rc.newwanip is not executed when system is booting.
Since it's always rename the interface and add it the group, make sure
it's up here.
Tightens, canonicalises and improves for IPv6, the functions
gen_subnet(), gen_subnetv6(), gen_subnet_max(), gen_subnetv6_max()
Changes are transparent to calling code.
Issues:
1) gen_subnet() and gen_subnet_max() will validate both IPv4 and IPv6 as valid args, but will then try to process an IPv6 subnet bitwise as x32 LONG without further checking, causing erroneous but apparently valid responses.
2) None of the functions properly sanitise their input: if $bits is >32 or >128, or even a non-integer, erroneous results will be passed back to the calling code as valid data without checking, again causing erroneous but apparently valid responses.
3) 3 of the 4 functions return an empty string for invalid but gen_subnetv6_max() returns a numeric value for invalid. Both responses loose-evaluate as False, but consistency is better.
Fixes and improvements:
1) The unspecified functions gen_subnet() and gen_subnet_max() now handle all args correctly, and don't mishandle if unexpectedly passed IPv6 or bad data.
2) Names are now canonical: gen_subnet(), gen_subnet_max() are now IPv4/v6 agnostic, and IPv4-only versions gen_subnetv4() and gen_subnetv4_max() are added as expected to exist, to match existing functions gen_subnetv6() and gen_subnetv6_max().
3) The return value for bad args is made consistent (empty string = False).
4) gen_subnetv6_max() now uses Net_IPv6's Ip2Bin() and Bin2Ip() functions and simple string manipulation rather than bitwise operations, so it's guaranteed 32-bit safe (compared to 128-bit bitwise operations in current code which seem less certain?)
5) Changes are transparent - the canonical functions still work exactly as before on IPv4 (only with proper bad arg validation) but also now work on IPv6 transparently, and on arbitrary IPv4/IPv6 data, similar to other functions like is_ipaddr().
Tested and handles valid but uncommon edge cases of /0, /32 (IPv4) and /128 (IPv6) correctly. Also avoids inet_ntop/pton if that's a real issue (previous PR comment had asked to avoid these functions)
The array returned by auth_get_authserver_list() has key as the fixed name of each available authentication mode - e.g. "Local Database".
The array value ["name"] has the name string translated into the selected GUI language.
Use the key do determine which items are selected, and as the value that ends up being stored in the config.
Use ["name"] for display.
Forum report: https://forum.pfsense.org/index.php?topic=86326.0
Redmine Bug #4180
The following block uses "quick" which causes that block to come into effect before the "pass in" here. The pass rule also needs to be "quick".
Problem noted by Andy Sayler on https://redmine.pfsense.org/issues/4074
Before this change, an attempt to manually do something local with IPv6 fails:
[2.2-RC][root@xxx]/root: ntpq -pn
ntpq: write to localhost failed: Operation not permitted
After this change, it works:
[2.2-RC][root@xxx]/root: ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
*27.114.150.12 193.190.230.65 2 u 21 64 377 1424.66 -126.52 371.131
Note that there are other pass rules later for IPv6 necessary functions, loopback... that do not have "quick". Those are correct and help to allow various essential IPv6 stuff, but still let someone block it with user rules (which will have quick), in the case when IPv6 Allow is checked.
This one here is just for the special case of IPv6 Allow not set, and in this case this special IPv6 pass-block sequence needs to be done with "quick" so we can be sure it applies regardless of whatever other IPv6 might come later.
Issue reported here: https://forum.pfsense.org/index.php?topic=78356.msg472781#msg472781
Most unbound doc places mention setting it at up to 8m. I'm sure it would be possible to investigate more and find a way to make unbound+FreeBSD be able to go higher than 8m. But probably 8m is sufficient for everyone anyway (judging by what the unbound docs seem to assume will be a good value on a busy system).
Anyway, here is my easy fix for this. Someone else feel free to investigate more if they really need to set so-rcvbuf higher.
- Unbound advanced options may contain double quotes and it breaks the
syntax when a backup is restored because newlines are trimmed. Save it
in base64 format is a safe way to prevent it
- Bump config version to 11.5
- Provide upgrade code to encode current config or the one that came
from unbound package on 2.1.5
When an interface is waiting to get DHCP, but the cable is physically-electrically connected to the upstream device, the interface has an IPv4 address 0.0.0.0 - that was getting past here and, if the interface gateway had a monitor IP specified, that monitor IP was being put into apinger.conf and being monitored. Because the interface has not got a gateway yet, no static route is added to force the traffic for the monitor IP out the particular interface. So the traffic to the monitor IP can follow the default route and perhaps succeed in getting out another WAN to the monitor IP.
The downstream results of this were:
1) Gateway status appears up and reports real RTT and Loss statistics, even though the interface is down.
2) Generation of rules for a gateway group that has this gateway as tier1 will think it is up, and thus try to policy-route traffic to it - which then does not get anywhere.
3) DynDNS status of a gateway group that has this gateway as tier1 shows the cached IP in red - it thinks the interface/gateway is up and tries to find the public IP by trying to get to checkip.dyndns.com through the interface/gateway. That of course fails.
4) I'm sure there are other things that depend on checking gateway and gateway group status that would also be getting it wrong in this condition, because apinger is being told to monitor, and manages to successfully monitor, an interface/gateway that has not yet got DHCP.
When waiting for DHCP, ifconfig shows like this on my system (WAN is on a cable to a VLAN switch):
vr0_vlan70: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 00:0d:b9:24:59:c0
inet6 fe80::20d:b9ff:fe24:59c0%vr0_vlan70 prefixlen 64 scopeid 0xf
inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
vlan: 70 vlanpcp: 0 parent interface: vr0
From what I can see, this little 2-line fix ends up correcting all the downstream effects I listed above.
Should fix RedMine #4094
Reported by forum https://forum.pfsense.org/index.php?topic=86146.0
Also, if there are input validation errors, save the user-entered data and re-display it, making it easier for the user to just correct the data in error and press Test again. It was blanking out all the entered data.
as mentioned in https://forum.pfsense.org/index.php?topic=84527.msg471919#msg471919
This change makes it work like similar if tests in /usr/local/wwwvpn_ipsec.php, and code in /etc/inc/vpn.inc that effectively defaults to ikev1 when iketype is not specified.
This should make the code here be executed and make $ikeid get the correct value to be used in later code.
This bit of code looks like it could do with the same test as https://github.com/pfsense/pfsense/pull/1412
This is executed when the "Connect" button is pressed from Status->IPsec
Somebody with these problematic old IPsec entries could test this - with current code I suspect that disconnect followed by connect - it will not connect. With this change it will (might?) connect again.
when reading response from socket.
Otherwise it would be in a loop and end up like: https://forum.pfsense.org/index.php?topic=86039.msg471848#msg471848
PHP Fatal error: Maximum execution time of 900 seconds exceeded in /etc/inc/ipsec.inc on line 383
This code runs on my system, but I do not know how to induce the possible loop condition to actually test if it would really break out and return nicely.
This works fine - I had not thought about how arrays are compared. Using "==" checks that the key/value pairs match in both arrays, regardless of the order the arrays happen to be in, which is what we want here.
Using "===" would insist that the key/value pairs are also in the same order in the array and that the types and everything match identically, which we do not require.
Fixes redmine #4151
1) Make the naming in shortcuts.inc more clear - forwarder=dnsmasq
resolver=unbound
2) Make the value of $shortcuts_section correct in each dnsmasq and
unbound php code
3) Make diag_logs_resolver.php smarter, so if dnsmasq is enabled, then
show shortcuts for dnsmasq, otherwise show shortcuts for unbound.
4) Fix some references to forwarder in unbound code - should be
resolver.
