#
346205 |
|
14-Apr-2019 |
ae |
MFC r341471: Reimplement how net.inet.ip.fw.dyn_keep_states works.
Turning on of this feature allows to keep dynamic states when parent rule is deleted. But it works only when the default rule is "allow from any to any".
Now when rule with dynamic opcode is going to be deleted, and net.inet.ip.fw.dyn_keep_states is enabled, existing states will reference named objects corresponding to this rule, and also reference the rule. And when ipfw_dyn_lookup_state() will find state for deleted parent rule, it will return the pointer to the deleted rule, that is still valid. This implementation doesn't support O_LIMIT_PARENT rules.
The refcnt field was added to struct ip_fw to keep reference, also next pointer added to be able iterate rules and not damage the content when deleted rules are chained.
Named objects are referenced only when states are going to be deleted to be able reuse kidx of named objects when new parent rules will be installed.
ipfw_dyn_get_count() function was modified and now it also looks into dynamic states and constructs maps of existing named objects. This is needed to correctly export orphaned states into userland.
ipfw_free_rule() was changed to be global, since now dynamic state can free rule, when it is expired and references counters becomes 1.
External actions subsystem also modified, since external actions can be deregisterd and instances can be destroyed. In these cases deleted rules, that are referenced by orphaned states, must be modified to prevent access to freed memory. ipfw_dyn_reset_eaction(), ipfw_reset_eaction_instance() functions added for these purposes.
Obtained from: Yandex LLC Sponsored by: Yandex LLC Differential Revision: https://reviews.freebsd.org/D17532
MFC r341472: Add ability to request listing and deleting only for dynamic states.
This can be useful, when net.inet.ip.fw.dyn_keep_states is enabled, but after rules reloading some state must be deleted. Added new flag '-D' for such purpose.
Retire '-e' flag, since there can not be expired states in the meaning that this flag historically had.
Also add "verbose" mode for listing of dynamic states, it can be enabled with '-v' flag and adds additional information to states list. This can be useful for debugging.
Obtained from: Yandex LLC Sponsored by: Yandex LLC
MFC r344018: Remove `set' field from state structure and use set from parent rule.
Initially it was introduced because parent rule pointer could be freed, and rule's information could become inaccessible. In r341471 this was changed. And now we don't need this information, and also it can become stale. E.g. rule can be moved from one set to another. This can lead to parent's set and state's set will not match. In this case it is possible that static rule will be freed, but dynamic state will not. This can happen when `ipfw delete set N` command is used to delete rules, that were moved to another set. To fix the problem we will use the set number from parent rule.
Obtained from: Yandex LLC Sponsored by: Yandex LLC
MFC r344870: Fix the problem with O_LIMIT states introduced in r344018.
dyn_install_state() uses `rule` pointer when it creates state. For O_LIMIT states this pointer actually is not struct ip_fw, it is pointer to O_LIMIT_PARENT state, that keeps actual pointer to ip_fw parent rule. Thus we need to cache rule id and number before calling dyn_get_parent_state(), so we can use them later when the `rule` pointer is overrided.
PR: 236292
|
#
334836 |
|
08-Jun-2018 |
ae |
MFC r333403: Bring in some last changes in NAT64 implementation:
o Modify ipfw(8) to be able set any prefix6 not just Well-Known, and also show configured prefix6; o relocate some definitions and macros into proper place; o convert nat64_debug and nat64_allow_private variables to be VNET-compatible; o add struct nat64_config that keeps generic configuration needed to NAT64 code; o add nat64_check_prefix6() function to check validness of specified by user IPv6 prefix according to RFC6052; o use nat64_check_private_ip4() and nat64_embed_ip4() functions instead of nat64_get_ip4() and nat64_set_ip4() macros. This allows to use any configured IPv6 prefixes that are allowed by RFC6052; o introduce NAT64_WKPFX flag, that is set when IPv6 prefix is Well-Known IPv6 prefix. It is used to reduce overhead to check this; o modify nat64lsn_cfg and nat64stl_cfg structures to use nat64_config structure. And respectivelly modify the rest of code; o remove now unused ro argument from nat64_output() function; o remove __FreeBSD_version ifdef, NAT64 was not merged to older versions; o add commented -DIPFIREWALL_NAT64_DIRECT_OUTPUT flag to module's Makefile as example.
MFC r333406: Update NAT64 documentation, now we support any IPv6 prefixes.
|
#
332767 |
|
19-Apr-2018 |
ae |
MFC r332457: Use cfg->nomatch_verdict as return value from NAT64LSN handler when given mbuf is considered as not matched.
If mbuf was consumed or freed during handling, we must return IP_FW_DENY, since ipfw's pfil handler ipfw_check_packet() expects IP_FW_DENY when mbuf pointer is NULL. This fixes KASSERT panics when NAT64 is used with INVARIANTS. Also remove unused nomatch_final field from struct nat64lsn_cfg.
Reported by: Justin Holcomb <justin at justinholcomb dot me>
|
#
324046 |
|
27-Sep-2017 |
ae |
MFC r323836: Do not acquire IPFW_WLOCK when a named object is created and destroyed.
Acquiring of IPFW_WLOCK is requried for cases when we are going to change some data that can be accessed during processing of packets flow. When we create new named object, there are not yet any rules, that references it, thus holding IPFW_UH_WLOCK is enough to safely update needed structures. When we destroy an object, we do this only when its reference counter becomes zero. And it is safe to not acquire IPFW_WLOCK, because noone references it. The another case is when we failed to finish some action and thus we are doing rollback and destroying an object, in this case it is still not referenced by rules and no need to acquire IPFW_WLOCK.
This also fixes panic with INVARIANTS due to recursive IPFW_WLOCK acquiring.
Sponsored by: Yandex LLC
|
#
316446 |
|
03-Apr-2017 |
ae |
MFC r304041: Move logging via BPF support into separate file.
* make interface cloner VNET-aware; * simplify cloner code and use if_clone_simple(); * migrate LOGIF_LOCK() to rmlock; * add ipfw_bpf_mtap2() function to pass mbuf to BPF; * introduce new additional ipfwlog0 pseudo interface. It differs from ipfw0 by DLT type used in bpfattach. This interface is intended to used by ipfw modules to dump packets with additional info attached. Currently pflog format is used. ipfw_bpf_mtap2() function uses second argument to determine which interface use for dumping. If dlen is equal to ETHER_HDR_LEN it uses old ipfw0 interface, if dlen is equal to PFLOG_HDRLEN - ipfwlog0 will be used.
Obtained from: Yandex LLC Sponsored by: Yandex LLC
MFC r304043: Add three helper function to manage tables from external modules.
ipfw_objhash_lookup_table_kidx does lookup kernel index of table; ipfw_ref_table/ipfw_unref_table takes and releases reference to table.
Obtained from: Yandex LLC Sponsored by: Yandex LLC
MFC r304046, 304108: Add ipfw_nat64 module that implements stateless and stateful NAT64.
The module works together with ipfw(4) and implemented as its external action module.
Stateless NAT64 registers external action with name nat64stl. This keyword should be used to create NAT64 instance and to address this instance in rules. Stateless NAT64 uses two lookup tables with mapped IPv4->IPv6 and IPv6->IPv4 addresses to perform translation.
A configuration of instance should looks like this: 1. Create lookup tables: # ipfw table T46 create type addr valtype ipv6 # ipfw table T64 create type addr valtype ipv4 2. Fill T46 and T64 tables. 3. Add rule to allow neighbor solicitation and advertisement: # ipfw add allow icmp6 from any to any icmp6types 135,136 4. Create NAT64 instance: # ipfw nat64stl NAT create table4 T46 table6 T64 5. Add rules that matches the traffic: # ipfw add nat64stl NAT ip from any to table(T46) # ipfw add nat64stl NAT ip from table(T64) to 64:ff9b::/96 6. Configure DNS64 for IPv6 clients and add route to 64:ff9b::/96 via NAT64 host.
Stateful NAT64 registers external action with name nat64lsn. The only one option required to create nat64lsn instance - prefix4. It defines the pool of IPv4 addresses used for translation.
A configuration of instance should looks like this: 1. Add rule to allow neighbor solicitation and advertisement: # ipfw add allow icmp6 from any to any icmp6types 135,136 2. Create NAT64 instance: # ipfw nat64lsn NAT create prefix4 A.B.C.D/28 3. Add rules that matches the traffic: # ipfw add nat64lsn NAT ip from any to A.B.C.D/28 # ipfw add nat64lsn NAT ip6 from any to 64:ff9b::/96 4. Configure DNS64 for IPv6 clients and add route to 64:ff9b::/96 via NAT64 host.
Obtained from: Yandex LLC Relnotes: yes Sponsored by: Yandex LLC Differential Revision: https://reviews.freebsd.org/D6434
MFC r304048: Replace __noinline with special debug macro NAT64NOINLINE.
MFC r304061: Use %ju to print unsigned 64-bit value.
MFC r304076: Make statistics nat64lsn, nat64stl an nptv6 output netstat-like: "@value @description" and fix build due to -Wformat errors.
MFC r304378 (by bz): Try to fix gcc compilation errors (which are right). nat64_getlasthdr() returns an int, which can be -1 in case of error, storing the result in an uint8_t and then comparing to < 0 is not helpful. Do what is done in the rest of the code and make proto an int here as well.
MFC r309187: Fix ICMPv6 Time Exceeded error message translation.
MFC r314718: Use new ipfw_lookup_table() in the nat64 too.
MFC r315204,315233: Use memset with structure size.
|