UTM vs IPv6

Further to this, I assigned my outbound interface an IP with the correct prefix, and at that point i did get connectivity over IPv6, suggesting that the only question to answer is the one about why the outbound interface didn't get an address assigned automatically.

Happy Thanksgiving.

Further to this, I assigned my outbound interface an IP with the correct prefix, and at that point i did get connectivity over IPv6, suggesting that the only question to answer is the one about why the outbound interface didn't get an address assigned automatically.

Happy Thanksgiving.

And I have the answer. my ISP (BT) does not assign IPv6 addresses via DHCP, so the outbound interface will never get one. UTM will not let me enable prefix delegation without an assigned IPv6 address (which I will never get, although I can make up a valid one), and UTM will not let me configure a static IPv6 address without a static IPv4 address (which I don't have). When i assign my assigned IPV4 address and a made-up valid ipv6 address, everything works. Unfortunately BT doesn't offer a static IP address for IPv4, and the one i have changes most weeks. 

I also found this statement - "BT does not allocate IA_NA addresses for the WAN port on the CPE interface, BT expects the link local addresses to be used for this communication. Any request for an IA_NA will always result in a response of no addresses available for IA_NA. This has always been the case from day one of the IPv6 implementation on the platform."

Right now, it looks like i can have either IPv6 or UTM, but not both.

Are you getting a delegated prefix in the ipv6/global tab?   What is the subnet, /48, /60, /64?

Pic below is from my att fiber connection.  Due to the way they have ipv6 set up, I had to use a manual dhclient6 command line to get things going.

Adjust interface name as necessary for your wan interface.  The 60 is the PD subnet range. Various with isp.

I tried that command, and i got this:

dchfw1:/root # chroot /var/sec/chroot-dhcpc /usr/sbin/dhclient6 -6 -P --prefix-len-hint 56 -d -D LLT -cf /etc/ppp0.conf6 -lf /var/db/ppp0_na.leases6 -pf /var/run/dhclient6_na_ppp0.pid ppp0
Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit www.isc.org/.../

Listening on Socket/ppp0
Sending on Socket/ppp0
PRC: Soliciting for leases (INIT).
XMT: Forming Solicit, 0 ms elapsed.
XMT: X-- IA_PD 00:00:00:00
XMT: | X-- Request renew in +3600
XMT: | X-- Request rebind in +5400
XMT: | | X-- Request prefix ::/56.
XMT: Solicit on ppp0, interval 1010ms.
RCV: Advertise message on ppp0 from fe80::22e0:9cff:fe4b:2801.
RCV: X-- IA_PD 00:00:00:00
RCV: | X-- starts 1587636372
RCV: | X-- t1 - renew +604800
RCV: | X-- t2 - rebind +1209600
RCV: | X-- [Options]
RCV: | | X-- IAPREFIX 2a00:23c7:xxxx.xxxx::/56
RCV: | | | X-- Preferred lifetime 315360000.
RCV: | | | X-- Max lifetime 315360000.
RCV: X-- Server ID: 00:03:00:01:20:e0:9c:4b:28:01
RCV: Advertisement recorded.
PRC: Selecting best advertised lease.
PRC: Considering best lease.
PRC: X-- Initial candidate 00:03:00:01:20:e0:9c:4b:28:01 (s: 10103, p: 0).
XMT: Forming Request, 0 ms elapsed.
XMT: X-- IA_PD 00:00:00:00
XMT: | X-- Requested renew +3600
XMT: | X-- Requested rebind +5400
XMT: | | X-- IAPREFIX 2a00:23c7:xxxx.xxxx::/56
XMT: | | | X-- Preferred lifetime +7200
XMT: | | | X-- Max lifetime +7500
XMT: V IA_PD appended.
XMT: Request on ppp0, interval 970ms.
RCV: Reply message on ppp0 from fe80::22e0:9cff:fe4b:2801.
RCV: X-- IA_PD 00:00:00:00
RCV: | X-- starts 1587636373
RCV: | X-- t1 - renew +604800
RCV: | X-- t2 - rebind +1209600
RCV: | X-- [Options]
RCV: | | X-- IAPREFIX 2a00:23c7:xxxx.xxxx::/56
RCV: | | | X-- Preferred lifetime 315360000.
RCV: | | | X-- Max lifetime 315360000.
RCV: X-- Server ID: 00:03:00:01:20:e0:9c:4b:28:01
PRC: Bound to lease 00:03:00:01:20:e0:9c:4b:28:01.
connecting...
connected.
done.
PRC: Renewal event scheduled in 604799 seconds, to run for 604800 seconds.
PRC: Depreference scheduled in 315359999 seconds.
PRC: Expiration scheduled in 315359999 seconds.
RCV: Advertise message on ppp0 from fe80::22e0:9cff:fe4b:2801.
Packet received, but nothing done with it.
RCV: Advertise message on ppp0 from fe80::22e0:9cff:fe4b:2801.
Packet received, but nothing done with it.
RCV: Advertise message on ppp0 from fe80::22e0:9cff:fe4b:2801.
Packet received, but nothing done with it.

I had the prefix without that, but what I can't get is an IP assigned to the external interface.  

Do you have an IPv6 address next to the IPv4 one? as you can see, I don't. 

if i use -N i get this:

RCV: Advertise message on ppp0 from fe80::22e0:9cff:fe4b:2801.
RCV: X-- IA_NA 00:00:00:00
RCV: | X-- starts 1587640321
RCV: | X-- t1 - renew +0
RCV: | X-- t2 - rebind +0
RCV: | X-- [Options]
RCV: | !-- Status code of no addrs, IA_NA discarded.
RCV: X-- Server ID: 00:03:00:01:20:e0:9c:4b:28:01
PRC: Lease failed to satisfy.

I did find a route in the table to an old ipv6 prefix that was assigned, and I have removed that. Then i tried this:

dchfw1:/root # ip6 route get 2a00:1450:4001:820::2004  <-- www.google.com
2a00:1450:4001:820::2004 from :: via fe80::22e0:9cff:fe4b:2801 dev ppp0 src fd32:5a88:8e98:2::1 metric 0
cache hoplimit 64

the route there is via the right interface, with a link local address as BT expect me to be using, but the source address is tun0, related to the Cisco VPN service which I do use. that alone i suspect would stop ipv6 working. i've deleted the route, but no change.

I can't do anything statically, as BT mess with things at least once a week. The IPv6 prefix changed yesterday and today.

Appreciate the help, thanks.

After that command, you are getting a "delegated prefix" in utm?

2a00:23c7:xxxx.xxxx/56

Set that as a static ip for the wan interface - ie 2a00:23c7:xxxx.xxxx::1/64, and gateway as

fe80::22e0:9cff:fe4b:2801 (ip default gw checked)

In my set up, I have web filtering enabled, even on ipv6, so for the local lan, using your ip #'s, the interface ip would be

2a00:23c7:xxxx.xxx(x+1)::1/64

There's a local dhcp serving out ipv6 addresses based on the lan ipv6 subnet

Ipv6/prefix advertisements contains 1 entry with managed and other config checked.  Renumbering tab is checked too.

You mention not being able to set anything static.  What specific portion of the PD changes? I'm no expert in this and fumbled my way into making it work eventually.

Thanks, I have done exactly that, a few months back and since you posted, and the result is the same - no connectivity. if i use the BT kit as they intend, everything works fine.

I have found two stupid things today, which may be related. Scenario:

• I have IPv6 addresses configured automatically from my delegated prefix on my UTM and my test client.
• test client is physically connected to UTM's eth2 which is part of a 3-port bridge, br0.
• ppp0 has a link-local address on the far end, and it is the default route (although UTM gui doesn't always show the address). I can ping it from the UTM 
• all ICMP checkboxes are checked on the ICMP tab.

First, I have a firewall rule to accept all IPv6 traffic from any network to any other network. I have set that to log, and the rule is being hit dozens of times a minute. if i change it to either drop or reject, the rule does not log any more. no clue about that, as the traffic was hitting the rule before, and I can still see it being sent.

Second, I have 12 interfaces listed on my UTM. if i use tcpdump -i any proto 58 I see ICMPv6 traffic that my test client generates. i cannot see that traffic if I monitor any other interface, even eth2 to which it is directly connected. Edit:  my UTM calls me a liar, by now seeing the traffic on eth2 but only after 460 pings.

From the console:

dchfw1:/root # ip addr show ppp0
148: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc pfifo_fast state UNKNOWN group default qlen 3
link/ppp
inet 86.x.y.z peer 172.16.12.118/32 scope global ppp0
valid_lft forever preferred_lft forever
inet6 2a00:23c7:xxxx:yyyy::1/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::20d5:899e:f842:eecb/10 scope link
valid_lft forever preferred_lft forever

dchfw1:/root # ip6 route
2a00:23c7:c60a:5100::/64 dev ppp0 proto kernel metric 256
2a00:23c7:c60a:5101::/64 dev br0 proto static metric 5
2a00:23c7:c60a:5101::/64 dev br0 proto kernel metric 256
fd32:5a88:8e98:2::/64 dev tun0 proto kernel metric 256
fe80::/64 dev eth1 proto kernel metric 256
fe80::/64 dev wifi1 proto kernel metric 256
fe80::/64 dev eth2 proto kernel metric 256
fe80::/64 dev br0 proto kernel metric 256
fe80::/64 dev eth0 proto kernel metric 256
fe80::/64 dev eth3 proto kernel metric 256
fe80::/64 dev wlan1 proto kernel metric 256
fe80::/10 dev ppp0 metric 1
fe80::/10 dev ppp0 proto kernel metric 256

dchfw1:/root # ping6 fe80::22e0:9cff:fe4b:2801%ppp0  <-- remote default gateway
PING fe80::22e0:9cff:fe4b:2801(fe80::22e0:9cff:fe4b:2801) from fe80::20d5:899e:f842:eecb ppp0: 56 data bytes
64 bytes from fe80::22e0:9cff:fe4b:2801: icmp_seq=1 ttl=255 time=1.48 ms

dchfw1:/root # ping6 fe80::5c89:ef3b:2acd:1dde%br0   <-- test client
PING fe80::5c89:ef3b:2acd:1dde(fe80::5c89:ef3b:2acd:1dde) from fe80::230:18ff:fecd:7619 br0: 56 data bytes
64 bytes from fe80::5c89:ef3b:2acd:1dde: icmp_seq=1 ttl=64 time=0.384 ms

There must be something I've missed, and it may even be that I need to ask BT. As I have set my UTM as they set their device though, I think UTM or my config of it is the issue. I may do a fresh install on a spare HDD and see if it works out of the box, just to eliminate anything I may have done with it.

Be interesting to see what your working system shows.

Well, yesterday was fun (not!).  I spent 12 hours messing with this. The *first* time i did it, with a fresh install of the UTM, I made a specific set of changes:

1. add <prefix>00::1 as the IP address on the WAN interface (64-bit mask) (WAN interface connects to the ONT)
2. add <prefix>01::1 as the IP on my LAN interface (i.e. the interface that is realistically the client's default gateway) (64-bit mask again)
3. advertise the prefix on the LAN interface
4. set static PPPoE addresses for IPv4 and IPv6 on the WAN interface (bad form and i know it isn't a long-term answer, but this is just testing)
5. force the UTM to request a prefix, and watch all the clients correctly obtain an IPv6 address.

and it worked. This was at 8am on Sunday morning. I backed up the good config, made the setup look like it should for me (the firewall has 4 ports, 3 of which I have in a bridge, and that is what I changed at this point), and it broke. 

Backed up that 'bad' config, reloaded the good one and....it broke.

Wiped the UTM again, fresh install from USB, identical config to the first try (apart from a different prefix) and it did not work.

I reloaded configs, wiped the UTM several times and generally messed for 12 hours yesterday, and the only time it worked was the very first time.

At each stage, I always tested IPv4 first (the WAN IP changed almost every time), and had to change the static IP on the WAN interface. the UTM automatically renumbers the IPv6 settings. 

The only conclusion i can draw is that there is something odd going on beyond the PPPoE connection. I can see my IPv6 traffic leave over it, but nothing comes back. No idea what to do next, as BT tell me that's Openreach magic at that point.

i just do not understand. I had TCP v6 disabled on my desktop since the weekend, and i just re-enabled it. 10/10 on test-ipv6.com.  For the record, this is all I did, and this was on my pre-existing config, i.e. not a fresh install:

1. enable IPv6
2. force the UTM to request a prefix (not sure why I needed to do it)
3. add <prefix>00::1 as the IP address on the LAN interface (64-bit mask)
4. advertise the prefix on the LAN interface using stateless integrated server
5. enable automatic renumbering

That's it. I have no clue why a 3-day gap makes any difference, but clearly it did. I consider this resolved, and not UTM's fault. 

I appreciate the suggestions :-)