summaryrefslogtreecommitdiffstats
path: root/sys/netpfil/pf
Commit message (Collapse)AuthorAgeFilesLines
* Bring back the ability of passing cached route via nd6_output_ifp().melifaro2015-11-151-1/+1
|
* This fixes several places where callout_stops return is examined. Therrs2015-11-131-2/+2
| | | | | | | | | | new return codes of -1 were mistakenly being considered "true". Callout_stop now returns -1 to indicate the callout had either already completed or was not running and 0 to indicate it could not be stopped. Also update the manual page to make it more consistent no non-zero in the callout_stop or callout_reset descriptions. MFC after: 1 Month with associated callout change.
* pf: Fix broken rule skip calculationkp2015-11-071-2/+2
| | | | | | | | r289932 accidentally broke the rule skip calculation. The address family argument to PF_ANEQ() is now important, and because it was set to 0 the macro always evaluated to false. This resulted in incorrect skip values, which in turn broke the rule evaluations.
* pf: Fix IPv6 checksums with route-to.kp2015-10-291-0/+7
| | | | | | | | | | | | | | 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 MFC after: 1 week
* Eliminate last rtalloc_ign() caller.melifaro2015-10-271-3/+0
| | | | Differential Revision: https://reviews.freebsd.org/D3927
* pf: Fix TSO issueskp2015-10-143-50/+88
| | | | | | | | | | | | | | | | | | | | | 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 Reviewed by: sbruno MFC after: 1 week Relnotes: yes Sponsored by: RootBSD Differential Revision: https://reviews.freebsd.org/D3779
* Simplify the way of attaching IPv6 link-layer header.melifaro2015-09-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem description: How do we currently perform layer 2 resolution and header imposition: For IPv4 we have the following chain: ip_output() -> (ether|atm|whatever)_output() -> arpresolve() Lookup is done in proper place (link-layer output routine) and it is possible to provide cached lle data. For IPv6 situation is more complex: ip6_output() -> nd6_output() -> nd6_output_ifp() -> (whatever)_output() -> nd6_storelladdr() We have ip6_ouput() which calls nd6_output() instead of link output routine. nd6_output() does the following: * checks if lle exists, creates it if needed (similar to arpresolve()) * performes lle state transitions (similar to arpresolve()) * calls nd6_output_ifp() which pushes packets to link output routine along with running SeND/MAC hooks regardless of lle state (e.g. works as run-hooks placeholder). After that, iface output routine like ether_output() calls nd6_storelladdr() which performs lle lookup once again. As a result, we perform lookup twice for each outgoing packet for most types of interfaces. We also need to maintain runtime-checked table of 'nd6-free' interfaces (see nd6_need_cache()). Fix this behavior by eliminating first ND lookup. To be more specific: * make all nd6_output() consumers use nd6_output_ifp() instead * rename nd6_output[_slow]() to nd6_resolve_[slow]() * convert nd6_resolve() and nd6_resolve_slow() to arpresolve() semantics, e.g. copy L2 address to buffer instead of pushing packet towards lower layers * Make all nd6_storelladdr() users use nd6_resolve() * eliminate nd6_storelladdr() The resulting callchain is the following: ip6_output() -> nd6_output_ifp() -> (whatever)_output() -> nd6_resolve() Error handling: Currently sending packet to non-existing la results in ip6_<output|forward> -> nd6_output() -> nd6_output _lle() which returns 0. In new scenario packet is propagated to <ether|whatever>_output() -> nd6_resolve() which will return EWOULDBLOCK, and that result will be converted to 0. (And EWOULDBLOCK is actually used by IB/TOE code). Sponsored by: Yandex LLC Differential Revision: https://reviews.freebsd.org/D1469
* pf: Fix misdetection of forwarding when net.link.bridge.pfil_bridge is setkp2015-09-011-1/+11
| | | | | | | | | | | | | | | | 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 Reviewed by: eri Differential Revision: https://reviews.freebsd.org/D3534
* pf: Remove support for 'scrub fragment crop|drop-ovl'kp2015-08-271-479/+31
| | | | | | | | | | | | | | The crop/drop-ovl fragment scrub modes are not very useful and likely to confuse users into making poor choices. It's also a fairly large amount of complex code, so just remove the support altogether. Users who have 'scrub fragment crop|drop-ovl' in their pf configuration will be implicitly converted to 'scrub fragment reassemble'. Reviewed by: gnn, eri Relnotes: yes Differential Revision: https://reviews.freebsd.org/D3466
* Reapply r196551 which was accidentally reverted by r223637 (update toloos2015-08-241-1/+1
| | | | | | | | | | | | | 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. MFC after: 3 days Sponsored by: Rubicon Communications (Netgate)
* Add ALTQ(9) support for the CoDel algorithm.loos2015-08-211-0/+7
| | | | | | | | | | | | | CoDel is a parameterless queue discipline that handles variable bandwidth and RTT. It can be used as the single queue discipline on an interface or as a sub discipline of existing queue disciplines such as PRIQ, CBQ, HFSC, FAIRQ. Differential Revision: https://reviews.freebsd.org/D3272 Reviewd by: rpaulo, gnn (previous version) Obtained from: pfSense Sponsored by: Rubicon Communications (Netgate)
* Fix the copy of addresses passed from userland in table replace command.loos2015-08-171-2/+1
| | | | | | | | | The size2 is the maximum userland buffer size (used when the addresses are copied back to userland). Obtained from: pfSense MFC after: 3 days Sponsored by: Rubicon Communications (Netgate)
* Use correct src/dst ports when removing states.oshogbo2015-08-111-2/+2
| | | | | | | | | Submitted by: Milosz Kaniewski <m.kaniewski@wheelsystems.com>, UMEZAWA Takeshi <umezawa@iij.ad.jp> (orginal) Reviewed by: glebius Approved by: pjd (mentor) Obtained from: OpenBSD MFC after: 3 days
* pf: Always initialise pf_fragment.fr_flagskp2015-07-291-3/+1
| | | | | | | | | | | | | | | 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. PR: 201879, 201932 MFC after: 5 days
* Simplify logic added in r285945 as suggested by glebiusgarga2015-07-281-4/+2
| | | | | | Approved by: glebius MFC after: 3 days Sponsored by: Netgate
* Respect pf rule log option before log dropped packets with IP options orgarga2015-07-281-2/+4
| | | | | | | | | | | dangerous v6 headers Reviewed by: gnn, eri Approved by: gnn Obtained from: pfSense MFC after: 3 days Sponsored by: Netgate Differential Revision: https://reviews.freebsd.org/D3222
* Fix a typo in r280169. Of course we are interested in deleting nsn onlyglebius2015-07-281-1/+1
| | | | | | if we have just created it and we were the last reference. Submitted by: dhartmei
* ALTQ FAIRQ discipline import from DragonFLYeri2015-06-243-0/+34
| | | | | | | | Differential Revision: https://reviews.freebsd.org/D2847 Reviewed by: glebius, wblock(manpage) Approved by: gnn(mentor) Obtained from: pfSense Sponsored by: Netgate
* pf: Remove frc_directionkp2015-06-111-7/+3
| | | | | | | | | 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/D2773 Approved by: philip (mentor)
* pf: Save the protocol number in the pf_fragmentkp2015-06-111-0/+1
| | | | | | | | | When we try to look up a pf_fragment with pf_find_fragment() we compare (see pf_frag_compare()) addresses (and family), id but also protocol. We failed to save the protocol to the pf_fragment in pf_fragcache(), resulting in failing reassembly. Differential Revision: https://reviews.freebsd.org/D2772
* pf: address family must be set when creating a pf_fragmentkp2015-06-101-0/+1
| | | | | | | | | | | | | | | | | 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). PR: 200330 Differential Revision: https://reviews.freebsd.org/D2769 Approved by: philip (mentor), gnn (mentor)
* CALLOUT_MPSAFE has lost its meaning since r141428, i.e., for more than tenjkim2015-05-221-1/+1
| | | | | | | | | | years for head. However, it is continuously misused as the mpsafe argument for callout_init(9). Deprecate the flag and clean up callout_init() calls to make them more consistent. Differential Revision: https://reviews.freebsd.org/D2613 Reviewed by: jhb MFC after: 2 weeks
* Use MTX_SYSINIT() instead of mtx_init() to separate mutex initializationglebius2015-05-193-17/+9
| | | | | | | from associated structures initialization. The mutexes are global, while the structures are per-vnet. Submitted by: Nikos Vassiliadis <nvass gmx.com>
* During module unload unlock rules before destroying UMA zones, whichglebius2015-05-191-1/+1
| | | | | | | 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. Sponsored by: Nginx, Inc.
* A miss from r283061: don't dereference NULL is pf_get_mtag() fails.glebius2015-05-181-2/+4
| | | | | PR: 200222 Submitted by: Franco Fichtner <franco opnsense.org>
* Don't dereference NULL is pf_get_mtag() fails.glebius2015-05-181-12/+14
| | | | | PR: 200222 Submitted by: Franco Fichtner <franco opnsense.org>
* Move ALTQ from contrib to net/altq. The ALTQ code is for many yearsglebius2015-04-161-1/+1
| | | | | | | | | discontinued by its initial authors. In FreeBSD the code was already slightly edited during the pf(4) SMP project. It is about to be edited more in the projects/ifnet. Moving out of contrib also allows to remove several hacks to the make glue. Reviewed by: net@
* pf: Fix forwarding detectionkp2015-04-141-1/+1
| | | | | | | | | | | | 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/D2286 Approved by: gnn(mentor)
* I can find no reason to allow packets with both SYN and FIN bitsgnn2015-04-141-1/+1
| | | | | | | | | 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)
* pf: Skip firewall for refragmented ip6 packetskp2015-04-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/D2197 Reviewed by: glebius, gnn Approved by: gnn (mentor)
* o Use new function ip_fillid() in all places throughout the kernel,glebius2015-04-012-3/+3
| | | | | | | | | | | | | | | | | where we want to create a new IP datagram. o Add support for RFC6864, which allows to set IP ID for atomic IP datagrams to any value, to improve performance. The behaviour is controlled by net.inet.ip.rfc6864 sysctl knob, which is enabled by default. o In case if we generate IP ID, use counter(9) to improve performance. o Gather all code related to IP ID into ip_id.c. Differential Revision: https://reviews.freebsd.org/D2177 Reviewed by: adrian, cy, rpaulo Tested by: Emeric POUPON <emeric.poupon stormshield.eu> Sponsored by: Netflix Sponsored by: Nginx, Inc. Relnotes: yes
* pf: Deal with runt packetskp2015-04-011-4/+4
| | | | | | | | | | | | | | 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/D2189 Approved by: gnn (mentor)
* Preserve IPv6 fragment IDs accross reassembly and refragmentationkp2015-04-011-1/+7
| | | | | | | | | | | | | 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/D2188 Approved by: gnn (mentor)
* Static'ize pf_fillup_fragment body to match its declaration.pluknet2015-03-261-1/+1
| | | | Missed in 278925.
* Always lock the hash row of a source node when updating its 'states' counter.glebius2015-03-172-66/+59
| | | | | PR: 182401 Sponsored by: Nginx, Inc.
* Reset mbuf pointer to NULL in fastroute case to indicate that mbuf wasae2015-03-121-0/+1
| | | | | | | | consumed by filter. This fixes several panics due to accessing to mbuf after free. Submitted by: Kristof Provost MFC after: 1 week
* Even more fixes to !INET and !INET6 kernels.glebius2015-02-171-17/+14
| | | | In collaboration with: pluknet
* - Improve INET/INET6 scope.glebius2015-02-161-34/+31
| | | | | - style(9) declarations. - Make couple of local functions static.
* Toss declarations to fix regular build and NO_INET6 build.glebius2015-02-161-3/+5
|
* In the forwarding case refragment the reassembled packets with the sameglebius2015-02-164-2/+93
| | | | | | | | | | 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. Submitted by: Kristof Provost Differential Revision: D1767
* Update the pf fragment handling code to closer match recent OpenBSD.glebius2015-02-162-286/+552
| | | | | | | | | That partially fixes IPv6 fragment handling. Thanks to Kristof for working on that. Submitted by: Kristof Provost Tested by: peter Differential Revision: D1765
* Back out r276841, r276756, r276747, r276746. The change in r276747 is veryglebius2015-01-225-93/+145
| | | | | | | | | | | | | very questionable, since it makes vimages more dependent on each other. But the reason for the backout is that it screwed up shutting down the pf purge threads, and now kernel immedially panics on pf module unload. Although module unloading isn't an advertised feature of pf, it is very important for development process. I'd like to not backout r276746, since in general it is good. But since it has introduced numerous build breakages, that later were addressed in r276841, r276756, r276747, I need to back it out as well. Better replay it in clean fashion from scratch.
* Do not initialize pfi_unlnkdkifs_mtx and pf_frag_mtx.rodrigc2015-01-082-8/+0
| | | | | | They are already initialized by MTX_SYSINIT. Submitted by: Nikos Vassiliadis <nvass@gmx.com>
* Reapply previous patch to fix build.rodrigc2015-01-064-39/+23
| | | | PR: 194515
* Instead of creating a purge thread for every vnet, createrodrigc2015-01-061-58/+24
| | | | | | | | a single purge thread and clean up all vnets from this thread. PR: 194515 Differential Revision: D1315 Submitted by: Nikos Vassiliadis <nvass@gmx.com>
* Merge: r258322 from projects/pf branchrodrigc2015-01-065-47/+53
| | | | | | | | | | | | | | Split functions that initialize various pf parts into their vimage parts and global parts. Since global parts appeared to be only mutex initializations, just abandon them and use MTX_SYSINIT() instead. Kill my incorrect VNET_FOREACH() iterator and instead use correct approach with VNET_SYSINIT(). PR: 194515 Differential Revision: D1309 Submitted by: glebius, Nikos Vassiliadis <nvass@gmx.com> Reviewed by: trociny, zec, gnn
* pf(4) needs to have a correct checksum during its processing.eri2014-11-191-6/+6
| | | | | | | | | | | | Calculate checksums for the IPv6 path when needed before delving into pf(4) code as required. PR: 172648, 179392 Reviewed by: glebius@ Approved by: gnn@ Obtained from: pfSense MFC after: 1 week Sponsored by: Netgate
* Finish r274315: remove union 'u' from struct pf_send_entry.melifaro2014-11-091-16/+11
| | | | Suggested by: kib
* Remove unused 'struct route' fields.melifaro2014-11-091-2/+0
|
* Remove SYSCTL_VNET_* macros, and simply put CTLFLAG_VNET where needed.glebius2014-11-071-1/+1
| | | | Sponsored by: Nginx, Inc.
OpenPOWER on IntegriCloud