Re: recent change of nat-to behavior
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 correctly AFAICS. So you should consider this bug closeable. - Peter -- 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.
Re: recent change of nat-to behavior
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 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 egress all flags S/SA keep state nat-to (egress) round-robin i386-49$ The interface may have more than one address... --- CVSROOT:/cvs Module name:src Changes by: mcbr...@cvs.openbsd.org 2010/01/11 20:20:52 Modified files: libexec/tftp-proxy: filter.c sbin/pfctl : parse.y pfctl.c pfctl_optimize.c pfctl_parser.c pfctl_parser.h pfctl_table.c share/man/man4 : pf.4 share/man/man5 : pf.conf.5 sys/net: pf.c pf_if.c pf_ioctl.c pf_lb.c pf_table.c pfvar.h usr.sbin/ftp-proxy: filter.c usr.sbin/relayd: pfe_filter.c Log message: First pass at removing the 'pf_pool' mechanism for translation and routing actions. Allow interfaces to be specified in special table entries for the routing actions. Lists of addresses can now only be done using tables, which pfctl will generate automatically from the existing syntax. Functionally, this deprecates the use of multiple tables or dynamic interfaces in a single nat or rdr rule. ok henning dlg claudio --- but NATed traffic is handled correctly AFAICS. So you should consider this bug closeable. Thanks for confirming that it's fixed.
Re: recent change of nat-to behavior
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 egress all flags S/SA keep state nat-to (egress) round-robin i386-49$ 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 address: peter@skapet:~$ ifconfig xl0 xl0: flags=8843UP,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 0xfffc 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 But anyway, with this snapshot I don't need to rewrite the NAT parts of my tutorial :) - 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.
Re: recent change of nat-to behavior
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 address: The point of using a dynamic interface is to handle possible future situations as well. So even if you only have one address now, how does PF know that you'll never do ifconfig xl0 inet alias ...? Basically, when you use ( ifname ), internally in PF it's handled as a table that's managed by the kernel, and 1) pfctl has no idea what's in that table, so it has to assume that there might be multiple addresses 2) all tables get implicit round-robin load-balancing unless you specify something else (I think the only other valid option for tables at the moment is 'least-states') Anyhow, the behaviour is the same as what you're expecting: round-robin on a single address means you always get that address selected.
Re: recent change of nat-to behavior
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 round-robin was the result, but this part is accurate: - meaning that return traffic wasn't necessarily seen. Changing the rule to match out log on $ext_if inet nat-to $ext_addr where $ext_addr is defined as the IPv4 address, restored the config to a working state. -- 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.
Re: recent change of nat-to behavior
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=8843UP,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 0xfffc 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. --
Re: recent change of nat-to behavior
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/ 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.
