In order to use the highest two bits for surciata bypass, we will need
to make sure that whenever we compare any other marks, we do not care
about anything else.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
This patch now proper allows to create rules for redirecting requests of a
given host, group or network(s) to a specified port or service to the
local IPFire system.
So it implements a very generic and easy to use feature to redirect
(for example all DNS, NTP, or whatever) requests to the a local running
instance and so to force usage of that local hosted service.
* The feature supports specifiying a single port and redirect the requests to another given one.
( For example requests to UDP 123 can be redirected to local UDP 1234
if you run an NTP server on that port.)
* It also supports direct usage of services or even service groups.
( So you can create a service group for DNS and redirect them to the
local recursor, or create a "redirected services" group which easily
can be managed...)
Signed-off-by: Stefan Schantl <stefan.schantl@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
In order to prevent collateral damage to internal traffic, commit
c69c820025 introduced applying location
block on red0 as a sanity check.
On systems configured to use PPPoE, however, traffic appears on the ppp0
interface instead. This patch checks if a system is configured to use
this connection method, and applies the location filter to this
interface. red0 is used otherwise.
Fixes: #12519
Cc: Michael Tremer <michael.tremer@ipfire.org>
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Since libloc is built as a tree we cannot simply exclude any address
space in the middle of it. Therefore we create some firewall rules
which simply avoid checking non-globally routable address space.
Fixes: #12499
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This commit adds flags which will are applied if SNAT should be used on
the red address or any configured alias.
They prevent doing the SNAT when tranismitting packet through a VPN over the red interface.
Fixes#12162.
Signed-off-by: Stefan Schantl <stefan.schantl@ipfire.org>
Tested-by: Michael Tremer <michael.tremer@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
Having raised the overall log rate limit to 10 packet per second
in Core Update 136, this did not affected rules generated by the
user. In order to stay consistent, this patch also raises log rate
limit for these.
In order to avoid side effects on firewalls with slow disks, it
was probably better touch these categories separately, so testing
users won't be DoSsed instantly. :-)
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Reviewed-by: Michael Tremer <michael.tremer@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
When a forwarding rule is being created, we sometimes create
INPUT/OUTPUT rules, too. Those were slightly invalid because
the source and destination interfaces where passed, too.
This could render some rules in certain circumstances useless.
This patch fixes this and only adds -i for INPUT and -o for
OUTPUT rules.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
The special_input/output_targets array assumed that firewall access
will always be denied. However, rules also need to be created when
access is granted. Therefore the ACCEPT target needs to be included
in this list and rules must be created in INPUTFW/OUTGOINGFW too
when ACCEPT rules are created in FORWARDFW.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
When creating SNAT rules, the outgoing interface is not set. As a side
effect, traffic that should be send unnatted to a vpn tunnel can be
natted which is a BUG.
With this patch the SNAT rules are getting a outgoing interface
according to the configuration. When selecting the RED Target network,
all SNAT rules will be configured with "-o red0". Otherwise if "all" is
selected, there is no interface in the rule, which matches all networks.
Signed-off-by: Alexander Marx <alexander.marx@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This commit adds support to the rules.pl and firewall-lib.pl to generate
correct iptables commands for inserting GeoIP-based firewall rules
into the kernel.
In the POSTROUTING chain using -i intf0 does not work at all.
We now only use the -s parameter to figure out if the rule applied.
The filter chain still uses -i and -o to match patches not only
by the network address, but also by the incoming/outgoing interface.
The configuration parser determines how many comma-separated
values there are in a line. If new values are added we need
to check first if those are set in every line to avoid any
undefined behaviour. A wrong comparison parameter was used
which caused that the limit feature was never enabled in
the rule generation.
The state of some code especially in general-functions.pl
is in such a bad shape and faulty.
This is a first step that replaces some of the network
functions with those who have been tested and work for
undefined inputs.
The old functions have been left in place as stubs
and must be removed at some time.
We added RED to the standard networks and now portforwardings are only
useable from the selected source. If selected "all" the portforwarding
can be used from any internal network. Else the access is only grnated
from the selected source network.
If the firewall is part of a local network (e.g. GREEN),
we automatically add rules that grant/forbid access for the firewall,
too.
This has been broken for various default policies other than ALLOWED.
Example:
my @as = (1, 2, 3);
foreach my $a (@as) {
$a += 1;
print "$a\n";
}
$a will be a reference to the number in the array and not
copied. Therefore $a += 1 will change the numbers in the
array as well, so that after the loop the content of @as
would be (2, 3, 4).
To avoid that, the number needs to be copied into a new
variable like: my $b = $a; and we are fine.
This caused that the content of the @sources and @destinations
array has been altered for the second run of the loop and
incorrect (i.e. no) rules were created.
