Please try a newer snapshot, this bug was fixed in the following commit:
----------------------------
CVSROOT: /cvs
Module name: src
Changes by: mcbr...@cvs.openbsd.org 2011/07/29 04:48:35
Modified files:
sys/net : pf_lb.c
Log message:
Make sure we use the right tbl/dyn pointer to check the pfrkt_refcntcost;
improved debugging for error cases inside the weighted round-robin loop.
original diff from claudio, ok henning
----------------------------
On Sat, Jul 30, 2011 at 05:17:44PM +0200, Peter N. M. Hansteen wrote:
> I finally got around to upgrading my home gateway from 4.9-current
> (late snapshot) to 5.0-beta (jul 27 snapshot), and I stumbled across
> what appears to be a subtle but significant change in nat-to behavior.
>
> my $ext_if is
>
> xl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> lladdr 00:50:da:21:cb:c9
> priority: 0
> groups: egress
> media: Ethernet autoselect (100baseTX full-duplex)
> status: active
> inet 213.187.179.198 netmask 0xfffffffc broadcast 213.187.179.199
> inet6 fe80::250:daff:fe21:cbc9%xl0 prefixlen 64 scopeid 0x3
> inet6 2001:16d8:ccbc:dead:beef::1 prefixlen 64
>
> and the nat-to line was
>
> match out log on $ext_if inet nat-to ($ext_if)
>
> AFter upgrading, this was loaded as
>
> match out log on $ext_if inet nat-to $ext_addr round-robin
>
> - meaning that return traffic wasn't necessarily seen.
>
> Changing the rule to
>
> match out log on $ext_if inet nat-to $ext_addr
>
> restored the config to a working state.
>
> Does this count as a buglet (or something that should be documented, at
> least)?
>
> - P
>
> --
> Peter N. M. Hansteen, member of the first RFC 1149 implementation team
> http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
> "Remember to set the evil bit on all malicious network traffic"
> delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
>
--
