| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Conflicts:
usr/local/www/vpn_ipsec_phase1.php
|
|
|
|
| |
vpn.inc for callers there that haven't already included it.
|
| |
|
| |
|
| |
|
|
|
|
| |
them too.
|
| |
|
|\ |
|
|/
|
| |
To be consistent with the checks in the rest of this code.
|
|
|
|
|
| |
LAN subnet to LAN IP. Same end result except it'll work for VIPs on same
interface now.
|
| |
|
| |
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If the Advanced Settings are saved before any other IPsec is set up then $config['ipsec'] can be just the empty string. As a result you can get:
a) If you select some debug settings then those are not saved. The code to save those settings was only executed when $config['ipsec'] was already an array. Actually the code already did the necessary "if isset() then unset()" stuuf. So I just took the the "if is_array()" away from the code block.
b) Some potential unset() can go wrong with errors like:
Fatal error: Cannot unset string offsets in /usr/local/www/vpn_ipsec_settings.php on line 168
This is corrected by adding more "if (isset())" checks.
Fixes Redmine #4865
|
|/ |
|
|\ |
|
|/
|
|
|
| |
when acquiring the interface data. In particular the media information
can have commas in it already as reported in Redmine bug #4859
|
|\ |
|
| |
| |
| | |
Unset any old CA and Cert in the system section that might still be there from when upgrade_066_to_067 did not unset them. That will tidy up old configs that had the conversion done originally but these old sections were left behind.
|
| |
| |
| |
| |
| | |
This looked odd. Why would we leave behind the old "ca" and "cert" section in $config["system"]?
I guess it would do no harm, but seems confusing for the future to have some unused entries like this remaining in the config.
Should a piece of code be put into the latest upgrade function to clean out these in any current config?
|
|\ \ |
|
| |/
| |
| | |
It would be quite unusual to have no filter rules array, but if that is indeed the case then the first part of this code that sets dnpipe and dnqueue numbers should execute anyway.
|
|\ \
| |/
|/| |
|
|/
|
| |
With the typo, this empty() test would always have been true. So maybe on upgrade some existing captive portal zoneid values have been getting overwritten by this even number counter? Or?
|
| |
|
|
|
|
| |
exec.php. Setup a link to download the status output.tgz in status.php
|
|
|
|
|
|
| |
Opening redmine ticket. Revert "sync up rc.carpmaster with RELENG_2_2. Ticket #4854, plus removal of unnecessary loop that'll amplify notifications unnecessarily."
This reverts commit 401adacfefbc6006bc2270ccc1640e1b15f767c1.
|
|
|
|
|
|
| |
an earlier commit."
This reverts commit 948bbc9baf77b47e636c904faf677a698c13a293.
|
| |
|
|
|
|
| |
already added suffices for Windows clients, though strongswan docs suggest setting this as well.
|
| |
|
|\ |
|
| | |
|
| |
| |
| | |
Clarify that this applies to DNS Resolver as well. Update the translations template.
|
| |
| |
| | |
Clarify that this applies to DNS Resolver as well.
|
|/
|
| |
Clarify that this applies to DNS Resolver as well.
|
|\ |
|
| | |
|
| |
| |
| |
| | |
As suggested by Renato.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
1) A disabled gateway can always be enabled - no extra validation
needed.
2) When disabling an enabled gateway, check to see that the gateway is
not used in any gateway group or enabled static route (similar tests to
what is already checked before deleting a gateway).
3) A static route can always be disabled - no extra checks needed.
4) When enabling a static route, check that the selected gateway is
enabled - you cannot have a static route enabled on a disabled gateway.
5) Do the address family cross-check between static route and gateway
even when the static route is disabled - we do not want to save
mismatched IP address families in any case.
This covers all the cases I can see to ensure that the enable/disable
status combinations of Gateways and Static Routes is always valid.
|
|\ \ |
|
| | |
| | |
| | | |
... so that people can get useful descriptions in the System Logs - Firewall GUI, instead of useless tracker numbers. This is for master branch.
|
|\ \ \ |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Create a host-type alias. Put just a number in "IP or FQDN" - e.g. I made alias name "Zqw" and a single host "23". The webGUI reports:
There were error(s) loading the rules: /tmp/rules.debug:44: syntax error - The line in question reads [44]: table { 23 }
and /tmp/rules.debug has:
table { 23 }
Zqw = ""
which pf does not cope with.
This change will differentiate between a number in the context of a port alias and a number that is_hostname.
This time I think it really works :) The call to alias_get_type() needed to send the alias name as parameter. alias_get_type() is a bit expensive - it scans through the whole list of aliases looking for a match on the name. So I made this code just call it once for the name and then use that $alias_type var each time as it loops through all the addresses in an alias.
I have tried this successfully with a few combinations of nested port/host/network aliases. But maybe there is some wacky combination of nested aliases possible that could still break this? I don't see how, but it needs testing on some configs that have all sorts of nested alias types.
|
|\ \ \ \
| |_|/ /
|/| | | |
|
| | | |
| | | |
| | | | |
The GUI should show descriptions according to what's selected from the dropdown, but currently does not for URL Table (IPs) and URL Table (Ports) type of aliases.
|
|/ / /
| | |
| | |
| | | |
unnecessary loop that'll amplify notifications unnecessarily.
|
| | |
| | |
| | |
| | |
| | |
| | | |
- Do not add leftid to confir when value is empty
- When asn1dn param is in binary form, explicit type
- Always add double quotes for asn1dn
|
|/ / |
|
| |
| |
| |
| |
| | |
- Add a upgrade code to fix asn1dn string format to match strongSwan needs
- Bump config version to 11.8
|