When creating firewallrules or using firewall groups,
it should be possible to select a single IpSec subnet if there is more than one.
This patch has neccessary changes for the firewall-lib. While the network name of the IpSec changes
on save (subnet is added to name) we need to split the name or normalise the field before using it.
Signed-off-by: Alexander Marx <alexander.marx@ipfire.org>
Tested-by: Peter Müller <peter.mueller@link38.eu>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
When an on-demand VPN connection is not up, the packets will
traverse the firewall and be rejected by the IPSECBLOCK chain
which will cause that an ICMP error message will be sent to
the client. If that does not happen and the packet is being
silently dropped, the client will retransmit and by then
the VPN connection will hopefully be up.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Packets destined for the firewall coming in from the blue
device where accepted too early to be processed by the
firewall input chain rules.
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>
When upgrading from a post core-77 installation, the portforwarding
rules seem to get broken. With this patch the sourceports and the
subnetmasks from the rules are converted correctly.
Signed-off-by: Alexander Marx <alexander.marx@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
If an IPsec VPN connections is not established, there are
rare cases when packets are supposed to be sent through
that said tunnel and incorrectly handled.
Those packets are sent to the default gateway an entry
for this connection is created in the connection tracking
table (usually only happens to UDP). All following packets
are sent the same route even after the tunnel has been
brought up. That leads to SIP phones not being able to
register among other things.
This patch adds firewall rules that these packets are
rejected. That will sent a notification to the client
that the tunnel is not up and avoid the connection to
be added to the connection tracking table.
Apart from a small performance penalty there should
be no other side-effects.
Fixes: #10908
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Cc: tomvend@rymes.com
Cc: daniel.weismueller@ipfire.org
Cc: morlix@morlix.de
Reviewed-by: Timo Eissler <timo.eissler@ipfire.org>
P2P networks have come a bit out of fashion. Disabling
the P2P blocker by default will save us some CPU cycles
for each packet that goes through the firewall.
The P2P blocker has also caused lots of false-positives
and has therefore become a bit more of a problem than
a solution.
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.
