[8.172][BUG][NOT A BUG] Spoof is still broken for IPv6

Ian, can you please write a short summary of the problem in this thread? I cannot really say from the threads you posted above which information is relevant and which isn't.

Hi Kai,
1/. this only happens with freenet6
2/. with one interface IPv6 works fine
3/. enable IPv6 on another interface - doesn't matter whether vlan or real - IPv6 stops working. No packets pass the HTTP proxy
4/. All devices have IPv6 addresses, the tunnel is up as shown by the logs
5/. HTTP proxy in either transparent or full transparent doesn't make any difference
6/. remove IPv6 from all but one internal interface and IPv6 passes through the ASG
7/. Packet filter log shows the packets as spoofed - as shown in the attachment with the original post in this thread.

I have tried this on a number of beta builds and upgrades on 2 differently configured ASGs.

I hope that helps

Ian

Hi,
please find attached 2 files with the data requested.

Ian[:)]

Hi,
please find attached 2 files with the data requested.

Thanks, but ip6t.txt is iptables-save output, not ip6tables-save

:-)

Hi,
sorry, just checking to see if I was awake and obviously I wasn't.

Ian[:$][:$][:$]

sorry, just checking to see if I was awake and obviously I wasn't.

I am not awake either... 
I see ipv6 configured on eth0.10, but not on any other interface (except the tunnelbroker inerface,
but that is fine).

Is this in the "working" or "ipv6 does not work" condition? If its the former, could you post the output
of those commands again when ipv6 is in "it gets dropped by spoof protection" condition?

Thanks!

Hi,
that will be tomorrow night my time (about 1830). It is a 2330 and I have had a very long day.

Ian

Hi,
I was able to extract the data this morning.

07:37:30 Spoofed packet 58 2406:a000:f005:9b00:a::a5     → ff02::1:ffb1:c755     len=72 srcmac=1c:6f:65:85:29:33 dstmac=0:1b:21:b1:c7:55[FONT=monospace]07:37:31 Spoofed packet 58 2406:a000:f005:9b00:a::a5     → ff02::1:ffb1:c755     len=72 srcmac=1c:6f:65:85:29:33 dstmac=0:1b:21:b1:c7:55
[/FONT]
07:37:31 Spoofed packet TCP 2406:a000:f005:9b00:a::a5 : 49280 → 2404:6800:4006:802::1011 : 80 [SYN] len=68 srcmac=1c:6f:65:85:29:33 dstmac=0:1b:21:b1:c7:55
With spoof enabled and set to normal, I cannot access IPv6 sites. Spoof disabled all works okay.

Ian

A DHCP server needs to be enabled on the second address range as far as I can tell.

Hi,
I was able to extract the data this morning.

With spoof enabled and set to normal, I cannot access IPv6 sites. Spoof disabled all works okay.

Thanks.  As far as I can see this is not a bug in spoofing protection per se.
In this configuration, eth0.10 and eth0.111 have addresses within the
same subnet range; namely  2406:a000:f005:9b00::/64.

Spoofing protection then creates these rules:
SPOOFING_ROTECTION -s 2406:a000:f005:9b00::/64 ! -i eth0.10 -j SPOOF_DROP 

(i.e., drop packets claiming to come from the subnet configured on eth0.10 that arrive via a different interface) and
SPOOFING_PROTECTION -s 2406:a000:f005:9b00::/64 ! -i eth0.111 -j SPOOF_DROP 

(i.e., drop ackets claiming to come from the subnet configured on eth0.111 that
arrive via a different interface)

Packets from 2406:a000:f005:9b00::/64 via eth0.10 will be dropped by
the 2nd rule...

Similar things should happen with ipv4 as well with e.g.
192.168.1.1/24 on eth0  and 192.168.1.2/24 on eth1.

I'll discuss with the powers-that-be on how we should proceed.

Hi,
I am a little bit puzzled by this. The IPv6 address range provided is 2406:a000:f005:9b00/56

This would imply that there is bug because it has allowed subnetting in the incorrect format.

Please advise how I subnet a /56 so that it doesn't cause spoofing?

2406:a000:f005:9b00:a:0/64 and 2406:a000:f005:9b00:b:0/64?

Ian

Hi,
I am a little bit puzzled by this. The IPv6 address range provided is 2406:a000:f005:9b00/56

Ah, I see.  In this case the subnetting went wrong.

This would imply that there is bug because it has allowed subnetting in the incorrect format.
2406:a000:f005:9b00:a:0/64 and 2406:a000:f005:9b00:b:0/64?

No, both describe the network 2406:a000:f005:9b00::/64,
Just like 2406:a000:f005:9bff::1/56 would describe an address within
2406:a000:f005:9b00::/56.

Try this instead:
2406:a000:f005:9b01::/64
2406:a000:f005:9b02::/64

Hi,
thank you for the explanation.

I will try the changes in the morning my time when I don't create too much chaos for the rest of the family.

Ian

Should have used the subnetting chart.

Hi,
thank you for the explanation.

I will try the changes in the morning my time when I don't create too much chaos for the rest of the family.

Ian

Should have used the subnetting chart.