> On Thu, Jul 28, 2011 at 08:51:41PM +0200, Claudio Jeker wrote:
>> On Wed, Jul 27, 2011 at 10:37:30PM +0200, Christopher Zimmermann wrote:
>> > Hi,
>> >
>> > pppoe0 has 92.203.101.134.
>> > this works fine:
>> >
>> > match out log on egress inet from 192.168.23.0/24 nat-to pppoe0
>> >
>> > tcpdump while pinging:
>> > 92.203.101.134 > 74.125.39.147: icmp: echo request
>> > 74.125.39.147 > 92.203.101.134: icmp: echo reply
>> > 92.203.101.134 > 74.125.39.147: icmp: echo request
>> > 74.125.39.147 > 92.203.101.134: icmp: echo reply
>> >
>> >
>> > But this doesn't:
>> >
>> > match out log on egress inet from 192.168.23.0/24 nat-to (pppoe0)
>> >
>> > tcpdump while pinging:
>> > 92.203.101.135 > 74.125.39.147: icmp: echo request
>> > 92.203.101.135 > 74.125.39.147: icmp: echo request
>> >
>> > in the (pppoe0) mode the IP address is always incremented by one.
>> > This also happens to other ips, not just 92.203.101.134.
>> >
>> >
>> > pppoe0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1492
>> >         priority: 0
>> >         dev: ep1 state: session
>> >         sid: 0x166f PADI retries: 1 PADR retries: 0 time: 00:11:21
>> >         sppp: phase network authproto pap
>> >         groups: pppoe egress
>> >         status: active
>> >         inet6 fe80::211:25ff:feae:e0c%pppoe0 ->  prefixlen 64 scopeid
>> 0x6
>> >         inet 92.203.101.134 --> 213.148.133.4 netmask 0xffffffff
>>
>> What kernel did you use? A few things happend lately in pf(4) that could
>> affect nat-to. Please include a dmesg so we have an idea how old your
>> kernel is.
>>
>> I will play a bit tonight and see if I see the porblem as well.
>
> Yup. The weighted round-robin stuff broke it. Here is a diff to fix the
> problem. To be honest, I'm not even sure it makes sense to enter the
> weight loop in the PF_ADDR_DYNIFTL case since there is no way to specify
> a weight on a dynamic table. Ryan, Hennning, Jorg what is you're opinion?

I had a firewall die on me last night, so I rebuilt with the
current i386 snapshot.  I also experienced NAT failure - it parsed
and loaded my pf.conf, but refused to NAT anything.  And yes, I
had net.inet.ip.forwarding enabled.  :)

I found a Soekris in my lab that had the following snapshot on it:

OpenBSD 4.9-current (GENERIC) #8: Wed Jul 13 09:47:42 MDT 2011

Putting that one into service *worked*, I have my internet
connection back.  So, that narrows it down a bit hopefully - it
broke between July 13th and July 27th.

Hope this helps.  If not, sorry for the noise.

Benny


-- 
"Open your door, or I open your wall."
                                 -- Seen on an image on fukung.net

Reply via email to