| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is necessary with firewall4 to avoid a hard-to-diagnose race
condition during boot, causing DNAT rules not to be taken into account
correctly.
The root cause is that, during boot, the ruleset is mostly empty, and
interface-related rules (including DNAT rules) are added incrementally.
If a packet hits the input chain before the DNAT rules are setup, it can
create buggy conntrack entries that will persist indefinitely.
This new default should be safe because firewall4 explicitly accepts
authorized traffic and rejects the rest. Thus, in normal operations, the
default policy is not used.
Fixes: #10749
Ref: https://github.com/openwrt/openwrt/issues/10749
Signed-off-by: Baptiste Jonglez <git@bitsofnetworks.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove restrictions on source and destination addresses, which aren't
specified on RFC8415, and for some reason in openwrt are configured
to allow both link-local and ULA addresses.
As cleared out in issue #5066 there are some ISPs that use Gloabal
Unicast addresses, so fix this rule to allow them.
Fixes: #5066
Signed-off-by: Tiago Gaspar <tiagogaspar8@gmail.com>
[rebase onto firewall3, clarify subject, bump PKG_RELEASE]
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Running your firewall's "wan" zone in REJECT zone (1) exposes the
presence of the router, (2) depending on the sophistication of
fingerprinting tools might identify the OS and release running on
the firewall which then identifies known vulnerabilities with it
and (3) perhaps most importantly of all, your firewall can be
used in a DDoS reflection attack with spoofed traffic generating
ICMP Unreachables or TCP RST's to overwhelm a victim or saturate
his link.
This rule, when enabled, allows traceroute to work even when the
default input policy of the firewall for the wan zone has been
set to DROP.
Signed-off-by: Philip Prindeville <philipp@redfish-solutions.com>
|
| |
|
|
|
|
|
|
|
|
| |
These are recommended practices by REC-22 and REC-24 of RFC6092:
"Recommended Simple Security Capabilities in Customer Premises Equipment
(CPE) for Providing Residential IPv6 Internet Service"
Fixes FS#640
Signed-off-by: Yousong Zhou <yszhou4tech@gmail.com>
|
| |
|
|
|
|
|
|
|
|
| |
There is no RFC requirement that DHCPv6 servers must reply with a link local
address and some ISP servers in the wild appear to using addresses in the ULA
range to send DHCPv6 offers.
Signed-off-by: Jo-Philipp Wich <jow@openwrt.org>
SVN-Revision: 47048
|
| |
|
|
|
|
|
|
|
|
| |
Seems like my second try was again whitespace broken. Sorry for the noise.
Remove src_port from firewall.config to receive dhcpv6 replies. Fixes #20295.
Signed-off-by: Anselm Eberhardt <a.eberhardt@cygnusnetworks.de>
SVN-Revision: 46842
|
| |
|
|
|
|
| |
Signed-off-by: Steven Barth <steven@midlink.org>
SVN-Revision: 46506
|
| |
|
|
|
|
| |
Signed-off-by: Steven Barth <steven@midlink.org>
SVN-Revision: 46478
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The WAN port should at least respond to IGMP and MLD queries as
otherwise a snooping bridge/switch might drop traffic.
RFC4890 recommends to leave IGMP and MLD unfiltered as they are always
link-scoped anyways.
Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
SVN-Revision: 45613
|
| |
|
|
| |
SVN-Revision: 37171
|
| |
|
|
|
|
| |
head with compatibility fixes for AA
SVN-Revision: 36838
|
| |
|
|
| |
SVN-Revision: 36837
|
| |
|
|
| |
SVN-Revision: 36622
|
| |
|
|
|
|
| |
from leaking out to the internet
SVN-Revision: 35012
|
|
|
SVN-Revision: 33688
|