Ryan McBride mcbr...@openbsd.org writes:
Please try a newer snapshot, this bug was fixed in the following commit:
Latest snapshot (date Jul 31) still loads
match out log on $ext_if inet nat-to ($ext_if)
as
match out log on xl0 inet all nat-to (xl0) round-robin
but NATed traffic is handled
On Sun, Jul 31, 2011 at 02:04:35PM +0200, Peter N. M. Hansteen wrote:
Ryan McBride mcbr...@openbsd.org writes:
Please try a newer snapshot, this bug was fixed in the following commit:
Latest snapshot (date Jul 31) still loads
match out log on $ext_if inet nat-to ($ext_if)
as
match
Ryan McBride mcbr...@openbsd.org writes:
match out log on xl0 inet all nat-to (xl0) round-robin
This part of the behaviour is normal and has not changed (since the
commit below, I believe). On 4.9 I get the following:
i386-49$ echo pass out on egress nat-to (egress) | pfctl -vnf -
pass out
On Sun, Jul 31, 2011 at 02:30:05PM +0200, Peter N. M. Hansteen wrote:
Ryan McBride mcbr...@openbsd.org writes:
The interface may have more than one address...
That's probably just me not noticing, but the odd part is that while
this interface has several addresses, it only has one IPv4
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=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
Not the most precise description I see -
pe...@bsdly.net (Peter N. M. Hansteen) writes:
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
Actually
match out log on $ext_if inet nat-to $ext_if
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
Ryan McBride mcbr...@openbsd.org writes:
Please try a newer snapshot, this bug was fixed in the following commit:
Trying a newer snapshot is exactly what I plan to do, no worries
- P
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/