nat-to may fail to insert state due to conflict on chosen source
port number. This is typically indicated by 'wire key attach failed on...'
message when pf(4) debugging is enabled. The problem is cau

nat-to may fail to insert state due to conflict on chosen source
port number. This is typically indicated by 'wire key attach failed on...'
message when pf(4) debugging is enabled. The problem is caused by
glitch in pf_get_sport() which fails to discover conflict in advance.
In order to fix it we must also calculate toeplitz hash in
pf_get_sport() to initialize look up key properly.

the bug has been kindly reported by joosepm _von_ gmail _dot_ com

OK dlg@

show more ...

move the pf_state_tree_id type from pfvar.h to pfvar_priv.h.

the pf_state_tree_id type is private to the kernel.

while here, move it from being an RB tree to an RBT tree. this saves
about 12k in pf

move the pf_state_tree_id type from pfvar.h to pfvar_priv.h.

the pf_state_tree_id type is private to the kernel.

while here, move it from being an RB tree to an RBT tree. this saves
about 12k in pf.o on amd64.

ok sashan@

show more ...

make kernel build without INET6 again
ok sashan@

Bug was reported by Chriss Cappucio. It has turned out my earlier change
to pf_lb.c was not complete. We must add a test to determine number of
addresses defined by pool, so we don't treat pool defin

Bug was reported by Chriss Cappucio. It has turned out my earlier change
to pf_lb.c was not complete. We must add a test to determine number of
addresses defined by pool, so we don't treat pool definition
172.16.0.0/16 as a single IP address in pool. If pool is defined as
172.16.0.0/16, then we don't want to fall back to PF_POOL_NONE. Missing
this measure in pf_map_addr() may cause pf_get_sport() to enter infinite
loop when source ports translation become depleted for the first address
found in pool (like 172.16.0.1), because the bug prevents pf_map_addr()
to move to next address in pool (like 172.16.0.2).

while investigating issue I've also noticed an oddity for small random
pools such as 192.168.1.32/28. One would expect the addresses for nat
will be randomly picked from range .32 - .47 in this case. however the
random selection yield significantly more (like 20%) addresses ending by .32
In order to fix it we make random pool to use arc4random_uniform(~mask + 1)
instead of current arc4random().

feedback by claudio@
tested by hrvoje@

show more ...

nat-to round-robin without a pool should fallback to POOL_NONE
bug reported by giovanni@

OK giovanni@

fix zero division found by syzkaller. The sanity checks in pf(4) ioctls
are not powerful enough to detect invalid port ranges (or even invalid
rules). syzkaller does not use pfctl(8), it uses ioctl(2

fix zero division found by syzkaller. The sanity checks in pf(4) ioctls
are not powerful enough to detect invalid port ranges (or even invalid
rules). syzkaller does not use pfctl(8), it uses ioctl(2) to pass some
random chunk of memory as a rule to pf(4). Fix adds explicit check
for 0 divider to pf_get_transaddr(). It should make syzkaller happy
without disturbing anyone else.

OK gnezdo@

Reported-by: syzbot+d1f00da48fa717e171f3@syzkaller.appspotmail.com

show more ...

Correct wrong type of variable and remove useless casts.

OK bluhm@

Fix previous commit which referred wrong address and returned wrong
value.

ok sashan

Use the table on root always if current table is not active.

ok sashan

Increase state counter for least-states when the address is selected
by sticky-address. Also fix the problem that the interface which is
specified by the selected table entry is not used properly.

Increase state counter for least-states when the address is selected
by sticky-address. Also fix the problem that the interface which is
specified by the selected table entry is not used properly.

ok jung sashan

show more ...

When source address tracking record is used for "route-to", the next
hop interface configured with "route-to" was not used. Keep the
interface within the pf_src_node and use it when the record is us

When source address tracking record is used for "route-to", the next
hop interface configured with "route-to" was not used. Keep the
interface within the pf_src_node and use it when the record is used.

OK sashan

show more ...

Remove useless macros

These are just unhelpful case conversion.

OK sashan henning

some finger muscle workout:
bzero -> memset and (very few) bcopy -> memcpy/memmove

Use a 32 bit variable to detect integer overflow when searching for
an unused nat port. Prevents a possible endless loop if high port
is 65535 or low port is 0.
report and analysis Jingmin Zhou; OK

Use a 32 bit variable to detect integer overflow when searching for
an unused nat port. Prevents a possible endless loop if high port
is 65535 or low port is 0.
report and analysis Jingmin Zhou; OK sashan@ visa@

show more ...

Some of the LOG_NOTICE messages from PF were seen in normal operations
with certain rulesets and excessively noisy; move them to LOG_INFO (which was
previously unused). ok benno@

Remove an uneeded NULL test which was after a deref.
ok mpi@ henning@ sashan@

Put union pf_headers and struct pf_pdesc into separate header file
pfvar_priv.h. The pf_headers had to be defined in multiple .c files
before. In pfvar.h it would have unknown storage size, this fi

Put union pf_headers and struct pf_pdesc into separate header file
pfvar_priv.h. The pf_headers had to be defined in multiple .c files
before. In pfvar.h it would have unknown storage size, this file
is included in too many places. The idea is to have a private pf
header that is only included in the pf part of the kernel. For now
it contains pf_pdesc and pf_headers, it may be extended later.
discussion, input and OK henning@ procter@ sashan@

show more ...

roll back turning RB into RBT until i get better at this process.

move pf from the RB macros to the RBT functions.

remove wrong and misleading comment, ok phessler

The function pf_get_sport() did work for out rules only. Make it
aware of the direction of the packet. Now nat-to can be used by
in rules and together with divert-to. Collisions with existing
stat

The function pf_get_sport() did work for out rules only. Make it
aware of the direction of the packet. Now nat-to can be used by
in rules and together with divert-to. Collisions with existing
states are found and produce a "NAT proxy port allocation failed"
message.
OK henning@ mikeb@

show more ...

There's no need to convert values returned by arc4random to the network
byte order. Spotted by Gleb Smirnoff (glebius@FreeBSD.org), thanks!

ok tedu

No need for <net/if_types.h>

As a bonus this removes a "#if NCARP > 0", say yeah!

When using a pf rule with both nat-to and rdr-to, it could happen
that the nated source port was reused as destination port. Do not
initialize nport at the beginning of the function, but where it is

When using a pf rule with both nat-to and rdr-to, it could happen
that the nated source port was reused as destination port. Do not
initialize nport at the beginning of the function, but where it is
needed.
OK sashan@

show more ...

- pf_insert_src_node(): global argument (arg6) is useless, function
always gets pointer to rule.

- pf_remove_src_node(): function should always remove matching src node,
regardless the sn->rule.

- pf_insert_src_node(): global argument (arg6) is useless, function
always gets pointer to rule.

- pf_remove_src_node(): function should always remove matching src node,
regardless the sn->rule.ptr being NULL or valid rule

- sn->rule.ptr is never NULL, spotted by mpi and Richard Procter _von_ gmail.com

OK mpi@, OK mikeb@

show more ...