|
From: François K. <fk...@tu...> - 2021-08-06 10:51:00
|
On 06.08.21 11:20, Gert Doering wrote: > Hi, Hi Gert, > On Fri, Aug 06, 2021 at 10:38:36AM +0200, François Kooman wrote: >> However, it does not explain how it exactly would rewrite --server-ipv6 >> fd42::/112 to those three statements. >> >> --ifconfig-ipv6 fd42::1/112 <????> >> --ifconfig-ipv6-pool fd42::1000/112 >> --push "tun-ipv6" > > This should work. And you can leave off the "push" bit :-) Ah right, that is implicit now (OpenVPN >= 2.4): "All tun devices on all platforms are always considered to be IPv6 capable. The --tun-ipv6 option is ignored (behaves like it is always on)." > A random IP in that subnet, like "fd42::1/112 fd42::2" - this is a > somewhat unlucky artefact of the implementation of --ifconfig-ipv6, > which insists on having a "remote" even if that is not used in > many cases. Right, I'll set it to the same IP as the tun0 device itself, i.e. fd42::1 if it can be random anyway ;-) > Without having tested it, I would agree that this is what it is. Actually I did test it now properly and it does work! > (The reason it was changed from :1000 to ::2 is "small pool size" - > if you have only a /112 or smaller, starting from :1000 reduces the pool > size significantly. If you use a /111 or bigger, it will actually stick > to the old behaviour - see helper.c, around line 200) Right, thanks for the explanation! > The log snippet is too short to give meaningful advice. Please show > the "ifconfig" or "ip address" statements, and what (if anything) is > pushed to clients. I actually screwed up my iptables rules that made it break because of different pool configuration (duh). So stupid :-( Thanks for your reply and confirming it works like this! :-) Regards, François |