| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
ipfw: Fix dynamic IPv6 rules showing junk for non-specified address masks.
Relnotes: yes
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pf: Fix IPv6 checksums with route-to.
When using route-to (or reply-to) pf sends the packet directly to the output
interface. If that interface doesn't support checksum offloading the checksum
has to be calculated in software.
That was already done in the IPv4 case, but not for the IPv6 case. As a result
we'd emit packets with pseudo-header checksums (i.e. incorrect checksums).
This issue was exposed by the changes in r289316 when pf stopped performing full
checksum calculations for all packets.
Submitted by: Luoqi Chen
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pf: Fix TSO issues
In certain configurations (mostly but not exclusively as a VM on Xen) pf
produced packets with an invalid TCP checksum.
The problem was that pf could only handle packets with a full checksum. The
FreeBSD IP stack produces TCP packets with a pseudo-header checksum (only
addresses, length and protocol).
Certain network interfaces expect to see the pseudo-header checksum, so they
end up producing packets with invalid checksums.
To fix this stop calculating the full checksum and teach pf to only update TCP
checksums if TSO is disabled or the change affects the pseudo-header checksum.
PR: 154428, 193579, 198868
Relnotes: yes
Sponsored by: RootBSD
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix wrong formatting of 0.0.0.0/X table records in ipfw(8).
Add `flags` u16 field to the hole in ipfw_table_xentry structure.
Kernel has been guessing address family for supplied record based
on xent length size.
Userland, however, has been getting fixed-size ipfw_table_xentry structures
guessing address family by checking address by IN6_IS_ADDR_V4COMPAT().
Fix this behavior by providing specific IPFW_TCF_INET flag for IPv4 records.
PR: bin/189471,kern/200169
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pf: Fix misdetection of forwarding when net.link.bridge.pfil_bridge is set
If net.link.bridge.pfil_bridge is set we can end up thinking we're forwarding
in pf_test6() because the rcvif and the ifp (output interface) are different.
In that case we're bridging though, and the rcvif the the bridge member on
which the packet was received and ifp is the bridge itself.
If we'd set dir to PF_FWD we'd end up calling ip6_forward() which is
incorrect.
Instead check if the rcvif is a member of the ifp bridge. (In other words, the
if_bridge is the ifp's softc). If that's the case we're not forwarding but
bridging.
PR: 202351
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reapply r196551 which was accidentally reverted by r223637 (update to
OpenBSD pf 4.5).
Fix argument ordering to memcpy as well as the size of the copy in the
(theoretical) case that pfi_buffer_cnt should be greater than ~_max.
This fix the failure when you hit the self table size and force it to be
resized.
Sponsored by: Rubicon Communications (Netgate)
|
|
|
|
|
|
|
|
|
|
| |
Fix the copy of addresses passed from userland in table replace command.
The size2 is the maximum userland buffer size (used when the addresses are
copied back to userland).
Obtained from: pfSense
Sponsored by: Rubicon Communications (Netgate)
|
|
|
|
|
|
|
|
|
|
|
| |
Respect pf rule log option before log dropped packets with IP options or
dangerous v6 headers
Reviewed by: gnn, eri
Approved by: gnn, glebius
Obtained from: pfSense
Sponsored by: Netgate
Differential Revision: https://reviews.freebsd.org/D3222
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pf: Always initialise pf_fragment.fr_flags
When we allocate the struct pf_fragment in pf_fillup_fragment() we
forgot to initialise the fr_flags field. As a result we sometimes
mistakenly thought the fragment to not be a buffered fragment.
This resulted in panics because we'd end up freeing the pf_fragment
but not removing it from V_pf_fragqueue (believing it to be part of
V_pf_cachequeue). The next time we iterated V_pf_fragqueue we'd use
a freed object and panic.
While here also fix a pf_fragment use after free in pf_normalize_ip().
pf_reassemble() frees the pf_fragment, so we can't use it any more.
X-MFS-To: releng/10.2
Sponsored by: The FreeBSD Foundation
|
| |
|
|
|
|
|
|
| |
During module unload unlock rules before destroying UMA zones, which
may sleep in uma_drain(). It is safe to unlock here, since we are already
dehooked from pfil(9) and all pf threads had quit.
|
|
|
|
| |
PR: 200222
|
|
|
|
|
|
| |
its 'states' counter.
PR: 182401
|
|
|
|
|
|
| |
- Provide a sleepable lock to protect against ioctl() vs ioctl() races.
- Use the new lock to protect against simultaneous DIOCSTART and/or
DIOCSTOP ioctls.
|
|
|
|
|
|
|
|
|
|
|
| |
pf: Remove frc_direction
We don't use the direction of the fragments for anything. The frc_direction
field is assigned, but never read.
Just remove it.
Differential Revision: https://reviews.freebsd.org/D2825
Reviewed by: gnn
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pf: address family must be set when creating a pf_fragment
Fix a panic when handling fragmented ip4 packets with 'drop-ovl' set.
In that scenario we take a different branch in pf_normalize_ip(), taking us to
pf_fragcache() (rather than pf_reassemble()). In pf_fragcache() we create a
pf_fragment, but do not set the address family. This leads to a panic when we
try to insert that into pf_frag_tree because pf_addr_cmp(), which is used to
compare the pf_fragments doesn't know what to do if the address family is not
set.
Simply ensure that the address family is set correctly (always AF_INET in this
path).
When we try to look up a pf_fragment with pf_find_fragment() we compare (see
pf_frag_compare()) addresses (and family), but also protocol. We failed to
save the protocol to the pf_fragment in pf_fragcache(), resulting in failing
reassembly.
PR: 200330
Differential Revision: https://reviews.freebsd.org/D2824
Reviewed by: gnn
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Improve INET/INET6 scope.
- style(9) declarations.
- Make couple of local functions static.
- Even more fixes to !INET and !INET6 kernels.
In collaboration with pluknet
- Toss declarations to fix regular build and NO_INET6 build.
Differential Revision: https://reviews.freebsd.org/D2823
Reviewed by: gnn
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pf: Fix forwarding detection
If the direction is not PF_OUT we can never be forwarding. Some input packets
have rcvif != ifp (looped back packets), which lead us to ip6_forward() inbound
packets, causing panics.
Equally, we need to ensure that packets were really received and not locally
generated before trying to ip6_forward() them.
Differential Revision: https://reviews.freebsd.org/D2822
Reviewed by: gnn
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pf: Skip firewall for refragmented ip6 packets
In cases where we scrub (fragment reassemble) on both input and output
we risk ending up in infinite loops when forwarding packets.
Fragmented packets come in and get collected until we can defragment. At
that point the defragmented packet is handed back to the ip stack (at
the pfil point in ip6_input(). Normal processing continues.
Eventually we figure out that the packet has to be forwarded and we end
up at the pfil hook in ip6_forward(). After doing the inspection on the
defragmented packet we see that the packet has been defragmented and
because we're forwarding we have to refragment it.
In pf_refragment6() we split the packet up again and then ip6_forward()
the individual fragments. Those fragments hit the pfil hook on the way
out, so they're collected until we can reconstruct the full packet, at
which point we're right back where we left off and things continue until
we run out of stack.
Break that loop by marking the fragments generated by pf_refragment6()
as M_SKIP_FIREWALL. There's no point in processing those packets in the
firewall anyway. We've already filtered on the full packet.
Differential Revision: https://reviews.freebsd.org/D2819
Reviewed by: gnn
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pf: Deal with runt packets
On Ethernet packets have a minimal length, so very short packets get padding
appended to them. This padding is not stripped off in ip6_input() (due to
support for IPv6 Jumbograms, RFC2675).
That means PF needs to be careful when reassembling fragmented packets to not
include the padding in the reassembled packet.
While here also remove the 'Magic from ip_input.' bits. Splitting up and
re-joining an mbuf chain here doesn't make any sense.
Differential Revision: https://reviews.freebsd.org/D2818
Reviewed by: gnn
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Preserve IPv6 fragment IDs accross reassembly and refragmentation
When forwarding fragmented IPv6 packets and filtering with PF we
reassemble and refragment. That means we generate new fragment headers
and a new fragment ID.
We already save the fragment IDs so we can do the reassembly so it's
straightforward to apply the incoming fragment ID on the refragmented
packets.
Differential Revision: https://reviews.freebsd.org/D2817
Reviewed by: gnn
|
|
|
|
|
|
|
|
|
|
|
| |
In the forwarding case refragment the reassembled packets with the same
size as they arrived in. This allows the sender to determine the optimal
fragment size by Path MTU Discovery.
Roughly based on the OpenBSD work by Alexander Bluhm.
Differential Revision: https://reviews.freebsd.org/D2816
Reviewed by: gnn
|
|
|
|
|
|
|
|
| |
Update the pf fragment handling code to closer match recent OpenBSD.
That partially fixes IPv6 fragment handling.
Differential Revision: https://reviews.freebsd.org/D2814
Reviewed by: gnn
|
|
|
|
|
|
|
| |
- Fix pf(4) to build with MAXCPU set to 256. MAXCPU is actually a count,
not a maximum ID value (so it is a cap on mp_ncpus, not mp_maxid).
- Bump MAXCPU on amd64 from 64 to 256. In practice APIC only permits 255
CPUs (IDs 0 through 254). Getting above that limit requires x2APIC.
|
|
|
|
|
|
|
|
|
|
| |
I can find no reason to allow packets with both SYN and FIN bits
set past this point in the code. The packet should be dropped and
not massaged as it is here.
Differential Revision: https://reviews.freebsd.org/D2266
Submitted by: eri
Sponsored by: Rubicon Communications (Netgate)
|
|
|
|
|
|
| |
Reset mbuf pointer to NULL in fastroute case to indicate that mbuf was
consumed by filter. This fixes several panics due to accessing to mbuf
after free.
|
|
|
|
|
|
| |
the checksum before entering pf_test6().
PR: 172648, 179392
|
|
|
|
|
|
|
|
|
| |
Change the PF hash from Jenkins to Murmur3. In forwarding tests
this showed a conservative 3% incrase in PPS.
Original Differential Revision: https://reviews.freebsd.org/D461
Submitted by: des
Reviewed by: emaste
|
|
|
|
|
|
|
| |
- De-vnet hash sizes and hash masks.
- Fix multiple issues related to arguments passed to SYSCTL macros.
Sponsored by: Mellanox Technologies
|
|
|
|
| |
Use rn_detachhead() instead of direct free(9) for radix tables.
|
|
|
|
|
|
|
| |
rule with "route-to" may still forward it.
PR: 177808
Approved by: re (gjb)
|
|
|
|
| |
Reported by: kib
|
|
|
|
|
|
|
|
| |
Do not lookup source node twice when pf_map_addr() is used.
PR: 184003
Submitted by: Kajetan Staszkiewicz <vegeta tuxpowered.net>
Sponsored by: InnoGames GmbH
|
|
|
|
|
|
|
|
|
|
|
|
| |
pf_map_addr() can fail and in this case we should drop the packet,
otherwise bad consequences including a routing loop can occur.
Move pf_set_rt_ifp() earlier in state creation sequence and
inline it, cutting some extra code.
PR: 183997
Submitted by: Kajetan Staszkiewicz <vegeta tuxpowered.net>
Sponsored by: InnoGames GmbH
|
|
|
|
|
|
|
|
| |
Fix synproxy with IPv6. pf_test6() was missing a check for M_SKIP_FIREWALL.
PR: 127920
Submitted by: Kajetan Staszkiewicz <vegeta tuxpowered.net>
Sponsored by: InnoGames GmbH
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Count global pf(4) statistics in counter(9).
- Do not count global number of states and of src_nodes,
use uma_zone_get_cur() to obtain values.
- Struct pf_status becomes merely an ioctl API structure,
and moves to netpfil/pf/pf.h with its constants.
- V_pf_status is now of type struct pf_kstatus.
Submitted by: Kajetan Staszkiewicz <vegeta tuxpowered.net>
Sponsored by: InnoGames GmbH
|
|
|
|
|
|
|
| |
On machines with strict alignment copy pfsync_state_key from packet
on stack to avoid unaligned access.
PR: 187381
|
|
|
|
|
|
|
|
| |
Since ipfw nat configures all options in one step, we should set all bits
in the mask when calling LibAliasSetMode() to properly clear unneeded
options.
PR: 189655
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r258708:
Check ipfw table numbers in both user and kernel space before rule addition.
Found by: Saychik Pavel <umka@localka.net>
r258711:
Simplify O_NAT opcode handling.
r260247:
Use rnh_matchaddr instead of rnh_lookup for longest-prefix match.
rnh_lookup is effectively the same as rnh_matchaddr if called with
empy network mask.
r261117:
Reorder struct ip_fw_chain:
* move rarely-used fields down
* move uh_lock to different cacheline
* remove some usused fields
|
|
|
|
| |
Define startup order the same way as it is in dummynet.
|
|
|
|
|
|
|
|
|
| |
De-virtualize UMA zone pf_mtag_z and move to global initialization part.
The m_tag struct does not know about vnet context and the pf_mtag_free()
callback is called unaware of current vnet. This causes a panic.
PR: kern/182964
|
|
|
|
|
|
| |
Set oif only for outgoing packets.
PR: 188543
|
|
|
|
|
|
|
| |
Free resources in error cases; re-indent a curly brace while here.
CID: 1199366
Found with: Coverity Prevent(tm)
|
|
|
|
|
|
| |
Execute pf_overload_task() in vnet context. Fixes a vnet kernel panic.
Reviewed by: trociny
|
|
|
|
| |
PR: kern/187665
|
|
|
|
|
|
|
|
|
|
| |
- Remove rt_metrics_lite and simply put its members into rtentry.
- Use counter(9) for rt_pksent (former rt_rmx.rmx_pksent). This
removes another cache trashing ++ from packet forwarding path.
- Create zini/fini methods for the rtentry UMA zone. Via initialize
mutex and counter in them.
- Fix reporting of rmx_pksent to routing socket.
- Fix netstat(1) to report "Use" both in kvm(3) and sysctl(3) mode.
|
|
|
|
|
|
|
|
|
| |
made in r263029.
Merge r257186,257215,257349,259736,261797.
These changesets split pfvar.h into several smaller headers and make
userland utilities to include only some of them.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Once pf became not covered by a single mutex, many counters in it became
race prone. Some just gather statistics, but some are later used in
different calculations.
A real problem was the race provoked underflow of the states_cur counter
on a rule. Once it goes below zero, it wraps to UINT32_MAX. Later this
value is used in pf_state_expires() and any state created by this rule
is immediately expired.
Thus, make fields states_cur, states_tot and src_nodes of struct
pf_rule be counter(9)s.
|
| |
|
| |
|