On 2009-04-06, Peter N. M. Hansteen <[email protected]> wrote:
> Aaron Stellman <[email protected]> writes:
>
>> By commenting out half the ruleset, and doing that recursively until
>> finding which rule causes it, I found it it be:
>>
>> nat on $ext_if from !self to any -> ($ext_if:0)
>
> The perils of doing both ipv4 and ipv6 at the same time, I see. Then
> again, if you narrow its scope to inet only (not inet6) you can
> probably put it back in, ie
>
> nat on $ext_if inet from !self to any -> ($ext_if:0)
>
at the risk of making Claudio sigh ... the first IPv6 address configured
on an interface (as returned by iface:0) is usually (always?) the link-local
address.
$ ifconfig pppoe0
pppoe0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1492
priority: 0
dev: vr1 state: session
sid: 0xade PADI retries: 0 PADR retries: 0 time: 3d 09:12:06
sppp: phase network authproto chap
groups: pppoe egress
inet6 fe80::200:24ff:fec9:26dc%pppoe0 -> prefixlen 64 scopeid 0x9
inet 85.158.45.32 --> 193.178.223.245 netmask 0xffffffff
inet6 2001:4b10:1002:ff::1 -> prefixlen 64
$ pfctl -nvf -
nat on pppoe0 inet6 -> pppoe0:0
nat on pppoe0 inet6 all -> fe80::200:24ff:fec9:26dc
this is totally invalid unless scoped (the %iface qualifier), and I think
it should be dropped from address expansion for nat. how this is going to pan
out when nat is integrated into the main ruleset, I'm not quite sure...
