| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|\ |
|
| |
| |
| |
| |
| |
| |
| | |
If for some reason the bogons file/s do not exist then this code creates
empty ones before making any use of them in the rule set.
On nanoBSD this can fail if the file system is mount RO.
Protect against this possibility by use conf_mount_rw and conf_mount_ro
|
|/ |
|
|
|
|
| |
Captive Portal. Fixes #4903
|
| |
|
|
|
|
| |
This time I have typed url_ports correctly.
|
|\ |
|
| |
| |
| | |
... 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.
|
|
|
|
| |
This reverts commit 81a73bcba3b3a79bb3a7add2e14a46e6af748f50.
|
|
|
|
|
|
|
|
|
|
| |
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 <Zqw> { 23 }
Zqw = "<Zqw>"
which pf does not cope with.
It is possible to have a host name that is a number, and end up with a domain name like 23.mycompany.com - unfortunately some Wally allowed such things in standards many years ago, so it can be rather difficult to tell the difference between a number and a host name.
This change improves the check when looking through alias entries and deciding if they are meant to be a name or a "bottom-level" value (address, subnet, port, port range). Anything that ends up looking like a host name gets given to filterdns to sort out. "Names" like "23" now get given to filterdns instead of being put directly into the table in pf. This makes things happier. Even if filterdns cannot resolve "23", at least it tries and nothing barfs.
|
| |
|
|
|
|
| |
and cause rule errors. Fixes #4772
|
|
|
|
|
|
|
| |
and other random stuff I noticed.
I think this finishes messing with code style. The codebase should match
the developer style guide closely enough that 99.9% of changes will not
feel the need to also massage the formatting.
|
| |
|
| |
|
|
|
|
|
|
| |
String replacement:
s/Ermal L.../Ermal Luçi/g
|
| |
|
| |
|
| |
|
|
|
|
| |
necessary or desirable, but Amazon VPC VPNs use that as their tunnel subnet with BGP setups.
|
| |
|
|
|
| |
When generating policy-routing rules there was no check if a gateway had force-down set, so gateway with force_down set would still get policy-routing rules written for it, even if skip_rules_gw_down was enabled.
|
|
|
|
|
|
|
|
| |
Example: LAN IP 10.0.1.1/24 OPT1 IP 10.0.2.1/24
Rules with SRC or DST LANnet correctly have 10.0.0.0/24 (the subnet base address) in /tmp/rules.debug
Rules with SRC or DST OPT1net have 10.0.2.1/24 (the OPT1 IP address with OPT1 net mask) in /tmp/rules.debug
It still works (I think) because actually 10.0.2.1/24 and 10.0.2.0/24 interpreted as a subnet still describes the same set of IP addresses, but it looks odd, as reported by: https://forum.pfsense.org/index.php?topic=90096.msg498474#msg498474
Same issue with IPv6 for OPT1net rules.
This fixes the rule generation to that OPT1net uses the base subnet address in the rule, in the same way that LANnet and WANnet does.
|
| |
|
| |
|
|
|
|
|
| |
Conflicts:
etc/inc/filter.inc
|
|
|
|
| |
limit, respectively) if not user-overridden.
|
|
|
|
| |
who configured them on previous versions where that was allowed. Ticket
|
|
|
| |
This is the changes to filter.inc as per the commits in https://github.com/pfsense/pfsense/pull/1521 but done in just 1 clean commit.
|
| |
|
|\ |
|
| |
| |
| |
| |
| |
| | |
and I "corrected" function names that had "_choosen_" in them.
That is not technically an error - function names do not have to be
English words. But it does look nicer to read.
|
|/
|
|
| |
sticks out so this stops getting broken. Ticket #3395
|
|
|
|
|
| |
releases since it specifically notes RFC 1918 and CGN is more bogon.
Ticket #4379
|
| |
|
|
|
|
| |
a string to be parsed.
|
| |
|
|
|
|
| |
changes and upgrade code
|
| |
|
| |
|
| |
|
|
|
|
| |
previous behavior of setting it to the interface IP.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
and NAT. Ticket #4169
|
|
|
|
| |
that feature is to prevent IPv6 from communicating on the network. Blocking it on localhost can result in issues and is unnecessary. Ticket #4074
|
|
|
|
| |
endpoint is not within the parent interface's subnet. Ticket #4157
|
|
|
|
| |
#4157
|