[GLLUG] radvd and vlans

[Tim Woodall]

On Tue, 6 Feb 2018, Chris Bell wrote:

>
> Hello Tim,
> I have been trying to learn how to do things using shorewall/shorewall6 in a
> box with four ethernet interfaces. I do not have native IPv6, and do not know
> when it will appear without warning, but I am trying to use 6to4 for testing.
> The various facilities such as SixXS all appear to have been discontinued
> within the last year.

I can highly recommend AAISP. When I was having an IPv6 routing problem
and tearing my hair out when it made no sense I dropped them an email
and same day they came back saying they'd checked their routing tables
and had I tried adding a static route? (which I hadn't - and going to do
that uncovered the real issue of a presumably old but automatically
added static route that was garbage. (I definitely hadn't added it so it
must have been automatic or added when AAISP supplied the router)

(I ought to have tried it without prompting but when ping is working one
way but any attempt to connect the other way gets "no route to host"
including ping and ssh doesn't work even the way ping works but
ipv6scanner.com says that the port is open and both machines (on
different /48s) can connect everywhere else, it's easy to forget to
try the easy things.)

My biggest IPv6 criticism is that the UI lets you add a random /64 or
/60 route in your /48. Or you can get the entire /48 routed (which is
how I've ended up with two /48s on two lines.) But no way to route a
particular /64 if you want a specific one.

Turns out that you can email support and they'll change the random /64
into a particular one - meaning that I didn't need to route the entire
/48 down a line to get specific /64s available. At some point I'll work
out what I am using and get my allocation reduced to a single /48 (which
I'll treat as two /49s)

> I found that multiple physical interfaces appeared in random order in /etc/
> network/interfaces until I included the workaround to pre-up check MAC
> addresses in Debian Jessie, but the system has been modified in Stretch so that
No idea what is happening here. I've not seen this issue. I know there
were changes to how interfaces were named. Have you tried
70-persistent-net-rules? (the changes to cdrom device naming caused me
grief - I think they were trying to cater for people who plug in
different cdrom drives so that the one that is plugged in is always
/dev/cdrom but that's not the way I wanted to work - particularly as I
sonetimes had two connected and I wanted them consistently named)


> each interface is named according to its location as found using lspci.
> I tried to configure everything in shorewall6 but nothing worked as expected,
> so I started from scratch setting things manually step by step. I have not
> managed to use radvd to set an auto default plus a different prefix for some
> interfaces using correctly allocated 64bit addresses based on fd00::/8
> according to RFC4193,
> ## ip address add
> appears to accept additional addresses but they did not appear in
> ## ip address show
> while
> ## ip route add
> has simply rejected all attempts at routing between the interfaces using any
> preferred prefix.  Everything was as configured in (local only) Bind9.

Are you using busybox? I think the ip command is crippled in that. Also,
I'd always use ip -6 addr add ...  I don't know if the -6 is optional as
I've not tried without it.

Are you using LL address for the gateway? This was probably the hardest
thing to get my head around.

Are you allowing all the neighbour discovery ICMP messages?

I have the following on my firewall
     ${IP6TABLES} -t filter -A INPUT  -p icmpv6 -s fe80::/10 -j ACCEPT
     ${IP6TABLES} -t filter -A OUTPUT -p icmpv6 -s fe80::/10 -j ACCEPT
     ${IP6TABLES} -t filter -A INPUT  -p icmpv6 -d fe80::/10 -j ACCEPT
     ${IP6TABLES} -t filter -A OUTPUT -p icmpv6 -d fe80::/10 -j ACCEPT
     ${IP6TABLES} -t filter -A INPUT  -p icmpv6 -s 2001:08b0:xxxx::/48 -j
ACCEPT
     ${IP6TABLES} -t filter -A OUTPUT -p icmpv6 -s 2001:08b0:xxxx::/48 -j
ACCEPT
     ${IP6TABLES} -t filter -A INPUT  -p icmpv6 -d 2001:08b0:xxxx::/48 -j
ACCEPT
     ${IP6TABLES} -t filter -A OUTPUT -p icmpv6 -d 2001:08b0:xxxx::/48 -j
ACCEPT

These allow more than strictly required. Particularly lines 6 and 7. I
think there's a ff00:: address involved in this that would probably be
better than my entire /48 to/from anywhere.

(and obfscating my /48 is probably futile - might even be visible in the
header of the enail - but I'm hopefully now using privacy addressing)

Tim.