Test pfsync in a more realistic scenario with carp and route_to rules.
Build this topology and initiate a single ping session from client to
server:
┌──────┐
│client│
└───┬──┘
│
┌───┴───┐
│bridge0│
└┬─────┬┘
│ │
┌────────────────┴─┐ ┌─┴────────────────┐
│gw_route_to_master├─┤gw_route_to_backup│
└────────────────┬─┘ └─┬────────────────┘
│ │
┌┴─────┴┐
│bridge1│
└┬─────┬┘
│ │
┌────────────────┴─┐ ┌─┴────────────────┐
│gw_reply_to_master├─┤gw_reply_to_backup│
└────────────────┬─┘ └─┬────────────────┘
│ │
┌┴─────┴┐
│bridge2│
└───┬───┘
│
┌───┴──┐
│server│
└──────┘
gw* jails forward traffic through pf route-to rules, not fib lookups.
If backup_promotion arg is given (as in the pfsync_pbr test case), a
carp failover event occurs during the ping session on both gateways.
Verify that ping messages still go where we expect them to go.
MFC after: 2 weeks
Sponsored by: Orange Business Services
Extend the existing ethernet dummynet test to also test dummynet on the
outbound direction.
This used to be a problem as traffic shaping wasn't done in the ethernet
code. It merely tagged the packet and left shaping up to the layer 3 pf
code. This works in the inbound direction, but not for outbound traffic
where we hit the L3 code first and only then the L2 code.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D35258
Allow tables to be used for the l3 source/destination matching.
This requires taking the PF_RULES read lock.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D34917
Disallow the use of tables in ethernet rules. Using tables requires
taking the PF_RULES lock. Moreover, the current table code isn't ready
to deal with ethernet rules.
Disallow their use for now.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Combine anchor, dummynet and rdr to produce a more complex captive
portal setup.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D32484
Teach the 'ether' rules to accept { mac1, mac2, ... } lists, similar to
the lists of interfaces or IP addresses we already supported for layer 3
filtering.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D32481
Ensure that the 'match' keyword works with dummynet
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D32480
Test that we can set dummynet information on L2, which is processed by
L3 later (assuming it's not overruled by L3 rules, of course).
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D32223
Test that we correctly match inbound ('in') or outbound ('out') Ethernet
packets.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D31747
Use the ether rules to selectively (i.e. per MAC address) redirect
certain connections. Test that tags carry over to the layer-3 pf code.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D31746
Test that we can express 'ether block from ! 00:01:02:03:04:05'.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D31744
Test the MAC address filtering capability in the new 'ether' feature in
pf.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D31743
The ability to set VLAN PCP from pf was introduced in 3e248e0fb4, but
never had a test added.
Create a basic setup to set the PCP to an arbitrary value and use
tcpdump to check it's actually set.
MFC after: 1 week
The pf tests have the ability to log state information (pf rules, pf
states, interfaces, ...) on exit (i.e. on success or on error).
This is useful, but only in specific cases. When it's not needed it may
get in the way of clear output.
Test scripts can add 'debug' to the pft_init call to enable this for the
specified test.
Reviewed by: brd
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D34133
There are some error paths in ioctl handlers that will call
pf_krule_free() before the rule's rpool.mtx field is initialized,
causing a panic with INVARIANTS enabled.
Fix the problem by introducing pf_krule_alloc() and initializing the
mutex there. This does mean that the rule->krule and pool->kpool
conversion functions need to stop zeroing the input structure, but I
don't see a nicer way to handle this except perhaps by guarding the
mtx_destroy() with a mtx_initialized() check.
Constify some related functions while here and add a regression test
based on a syzkaller reproducer.
Reported by: syzbot+77cd12872691d219c158@syzkaller.appspotmail.com
Reviewed by: kp
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D34115
These had been disabled due to panics with queued packets keeping
pointers (in m->m_pkthdr.rcvif) to removed interfaces.
This issue has been resolved in 165746f4e4, so the tests can be run
again.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Dummynet queues packets with an associated struct ifnet pointer. Ensure
that things do not explode if that interface goes away with packets
still in the queue.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D33065
There is no guarentee that upon return of 'jail -r' all jail resources
will be released. The test suite used to rely on that. Recent changes
to the PCB zones made jails delay releasing their resources, which ended
with interface leak in the test suite.
Fix that by executing 'ifconfig foo0 destroy' inside the jail, instead
of doing 'jail -r' and expecting interfaces to pop up back immediately
in the parent jail.
Reviewed by: kp
Differential revision: https://reviews.freebsd.org/D33942
Log information from the running jails (routing, interfaces and pf) as
well as interfaces on the host.
This information is expected to be useful in debugging test failures.
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
Disable the dummynet tests when running the ci tests. This avoids
running into the panic described in https://reviews.freebsd.org/D33064
(where an interface is removed but a dummynet queued packet still has a
pointer to it).
These tests can be re-enabled when the work in
https://reviews.freebsd.org/D33267 lands.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Add a somewhat more extensive pfsync defer mode test. Ensure that pfsync
actually delays the state creating packet until after it has sent the
pfsync update and given the peer time to create the state.
Ideally the test should validate the pfsync state update and generate an
ack message, but to keep the test simple we rely on the timeout of the
deferred packet instead.
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D33245
We didn't populate dyncnt/tblcnt, so `pfctl -sr -vv` might not have the
table element count.
PR: 259689
MFC after: 3 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D32893
Ensure that NAT still works as expected when combined with dummynet.
MFC after: 3 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D32666
Ensure that the ICMP error is returned with the correct
source and destination addresses.
MFC after: 3 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D32572
Test the $nr expansion in labels is correct, even if the optimiser
reduces the rule count.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D32489
