Re: Fix pf(4) nat proxy port allocation for manually specified ranges... perhaps?
On Sun, Jul 27, 2003 at 01:48:13AM -0700, Trevor Talbot wrote: Ah, turns out this is a different bug. It's been fixed in -current, but hasn't reached -stable. Yet. Again. Does someone not like Ryan McBride's patches? :) http://www.openbsd.org/cgi-bin/cvsweb/src/sbin/pfctl/ parse.y.diff?r1=1.373r2=1.374 Does Ryan submit his patches for -stable commit? :) This one is clearly non-controversial (bugfix, small, unlikely to break something), so I don't see how it could be refused. But it has to be submitted (repeatedly, if ignored, until it goes through), and that's primarily the burden of whoever commited it to -current. So, harrass Ryan until it's in ;) Daniel
RE: Fix pf(4) nat proxy port allocation for manually specified ranges... perhaps? (Resolved)
On Sunday, July 27, 2003 9:54 AM, Daniel Melameth wrote: The following snippets DO NOT work fine under 3.3 stable (on similar machine): nat on $ext inet proto udp from $ipp port = 5004 to $ipc - $ext port 5004 nat on $ext inet proto udp from $ipp port = 5567 to $ipc - $ext port 5567 # pfctl -s all ... nat on ep1 inet proto udp from 172.30.0.127 port = 5004 to 191.255.255.1 - 223.255.255.1 port 5004:35859 nat on ep1 inet proto udp from 172.30.0.127 port = 5567 to 191.255.255.1 - 223.255.255.1 port 5567:48917 Did you upgrade pfctl too? It had a bug that caused it to set the second port incorrectly. As far as I can tell I did both userland and the kernel via CVS. Ah, turns out this is a different bug. It's been fixed in -current, but hasn't reached -stable. Yet. Again. Does someone not like Ryan McBride's patches? :) http://www.openbsd.org/cgi-bin/cvsweb/src/sbin/pfctl/ parse.y.diff?r1=1.373r2=1.374 Ah. I missed this one... Does look like a fine stable candidate though... For what you're doing, using the static-port option instead of a specific port should also work. I'm not familiar with this, would you please give me an example? nat on $ext inet proto udp from $ipp port = 5004 to $ipc - $ext static-port This option causes nat to keep the source port the same, instead of rewriting it as usual. Appears less complex and exactly what I need (perhaps this what I should have used initially)... I will give this a shot when I am onsite next and report on the results. This did the trick! Thanks Trevor!
RE: Fix pf(4) nat proxy port allocation for manually specified ranges... perhaps?
On Sunday, July 27, 2003 2:48 AM, Trevor Talbot wrote: The following snippets DO NOT work fine under 3.3 stable (on similar machine): nat on $ext inet proto udp from $ipp port = 5004 to $ipc - $ext port 5004 nat on $ext inet proto udp from $ipp port = 5567 to $ipc - $ext port 5567 # pfctl -s all ... nat on ep1 inet proto udp from 172.30.0.127 port = 5004 to 191.255.255.1 - 223.255.255.1 port 5004:35859 nat on ep1 inet proto udp from 172.30.0.127 port = 5567 to 191.255.255.1 - 223.255.255.1 port 5567:48917 Did you upgrade pfctl too? It had a bug that caused it to set the second port incorrectly. As far as I can tell I did both userland and the kernel via CVS. Ah, turns out this is a different bug. It's been fixed in -current, but hasn't reached -stable. Yet. Again. Does someone not like Ryan McBride's patches? :) http://www.openbsd.org/cgi-bin/cvsweb/src/sbin/pfctl/ parse.y.diff?r1=1.373r2=1.374 Ah. I missed this one... Does look like a fine stable candidate though... For what you're doing, using the static-port option instead of a specific port should also work. I'm not familiar with this, would you please give me an example? nat on $ext inet proto udp from $ipp port = 5004 to $ipc - $ext static-port This option causes nat to keep the source port the same, instead of rewriting it as usual. Appears less complex and exactly what I need (perhaps this what I should have used initially)... I will give this a shot when I am onsite next and report on the results. Thanks Trevor...
Re: Fix pf(4) nat proxy port allocation for manually specified ranges... perhaps?
On Saturday, Jul 26, 2003, at 19:55 US/Pacific, Melameth, Daniel D. wrote: Newbie running 3.3 stable with pf, dhcpd and isakmpd... ...recently upgraded to stable in the hopes of curing some ill that I have... and now I ask for peer review... The following snippets DO NOT work fine under 3.3 stable (on similar machine): nat on $ext inet proto udp from $ipp port = 5004 to $ipc - $ext port 5004 nat on $ext inet proto udp from $ipp port = 5567 to $ipc - $ext port 5567 # pfctl -s all ... nat on ep1 inet proto udp from 172.30.0.127 port = 5004 to 191.255.255.1 - 223.255.255.1 port 5004:35859 nat on ep1 inet proto udp from 172.30.0.127 port = 5567 to 191.255.255.1 - 223.255.255.1 port 5567:48917 Did you upgrade pfctl too? It had a bug that caused it to set the second port incorrectly. For what you're doing, using the static-port option instead of a specific port should also work.
RE: Fix pf(4) nat proxy port allocation for manually specified ranges... perhaps?
On Saturday, July 26, 2003 9:49 PM, Trevor Talbot wrote: Newbie running 3.3 stable with pf, dhcpd and isakmpd... ...recently upgraded to stable in the hopes of curing some ill that I have... and now I ask for peer review... The following snippets DO NOT work fine under 3.3 stable (on similar machine): nat on $ext inet proto udp from $ipp port = 5004 to $ipc - $ext port 5004 nat on $ext inet proto udp from $ipp port = 5567 to $ipc - $ext port 5567 # pfctl -s all ... nat on ep1 inet proto udp from 172.30.0.127 port = 5004 to 191.255.255.1 - 223.255.255.1 port 5004:35859 nat on ep1 inet proto udp from 172.30.0.127 port = 5567 to 191.255.255.1 - 223.255.255.1 port 5567:48917 Did you upgrade pfctl too? It had a bug that caused it to set the second port incorrectly. As far as I can tell I did both userland and the kernel via CVS. For what you're doing, using the static-port option instead of a specific port should also work. I'm not familiar with this, would you please give me an example?
