2017-01-28 17:47:32	slypknot	UPDATE to that thread: adding ifconfig-ipv6 add/bits resolves the problem .. but it looks like openvpn does not recognise that the TAP has got an ipv6 via RA's over tap bridge vpn
2017-01-28 17:52:36	@cron2	in tap mode, openvpn has no idea about ip or ipv6 addresses left or right - it will ifconfig them, if told, but for "what goes left, what goes right", only ethernet packets are looked at
2017-01-28 17:54:47	slypknot	dhi cron2 , did you take a look at the thread .. are you happy that it is expected behaviour for v6, it would not behave that way for v4 ?
2017-01-28 17:54:52	slypknot	hi*
2017-01-28 17:56:37	slypknot	i presume it is something to do with openvpn uses dhcp for v4 but not the same for v6 so it does not realise the TAP has a v6 if it was not assigned by openvpn
2017-01-28 17:57:27	slypknot	also, the OP has not given full details of what they actually added yet ..
2017-01-28 18:00:49	@cron2	slypknot: openvpn does not *care* what address the tap adapter has in *bridging tap* mode
2017-01-28 18:00:58	@cron2	it is only interested in ethernet packets
2017-01-28 18:01:31	@cron2	you can run OSPF over a bridged tap link, learning dynamic routes and everything, *because* openvpn is not interested in IP(v6) addresses in tap mode
2017-01-28 18:01:43	@cron2	so the description so far does not make sense - but as I said, I'm not reading forums
2017-01-28 18:04:01	slypknot	FYI: the failure was on the client side .. openvpn did not recognise the TAP adapter recieved a v6 add at all
2017-01-28 18:04:14	slypknot	but 2.3.x worked ok
2017-01-28 18:04:23	slypknot	apparently
2017-01-28 18:05:29	slypknot	the only reason I have bought this to your attention is because it looks like something has changed with v6 in 2.4
2017-01-28 18:06:11	slypknot	for general user errors i can handle 99% .. but this one feels different
2017-01-28 18:08:30	slypknot	one other question: the OS can learn all it needs with ipv6 without openvpn doing anything in tap mode ?
2017-01-28 18:10:38	ordex	slypknot: in tap mode the interface is exactly like your standard eth0 - the OS or whatever running on top won't notice any difference because openvpn only forwards the ethrnet frames without doing anything else. I think this is what cron2 was referring to earlier
2017-01-28 18:12:56	slypknot	ordex: thanks .. i guess this is where my knowledge gets a bit too thin to understand properly
2017-01-28 18:13:00	@cron2	slypknot: on the risk of sounding repetitive: why should openvpn recognize whether the tap adapter has a v6 address or not?
2017-01-28 18:13:44	@cron2	it will not display it on the management interface - that much is true :-) - but regarding "will the v6 packets be forwarded" openvpn really isn't caring
2017-01-28 18:14:46	slypknot	cron2: I don't know .. if you read the thread you would know what the situation is .. I do not expect any help or an answer on the thread .. I just bought it to your attention should it be of interest to you .. if it is not then forhey about it
2017-01-28 18:14:47	ordex	btw I see the code change that changed this behaviour. I think it used to work before "by accident"
2017-01-28 18:15:14	slypknot	ordex: that was what i was thinking "worked before by accident" ..
2017-01-28 18:15:58	ordex	now the logic is more meticolous and prevents from adding IPv6 routes is not IPv6 was staticanlly configured in the config
2017-01-28 18:16:01	ordex	and it makes sense
2017-01-28 18:16:04	slypknot	cron2: forget* about it
2017-01-28 18:16:16	ordex	slypknot: if the addres is coming from radvd, why not injecting the route through it as well? doesn't it work like that ?
2017-01-28 18:16:29	ordex	in this case it is not openvpn's role to set that route up
2017-01-28 18:16:36	ordex	or
2017-01-28 18:16:44	ordex	the guy can do that in an up.sh script (?)
2017-01-28 18:17:26	slypknot	the route being added is a partial --redirect-gateway v5 type thing .. so not specific to the adapter subnet
2017-01-28 18:17:50	slypknot	v6*
2017-01-28 18:17:55	ordex	well, that works when openvpn is configured in a way that it knows all the IPs being used
2017-01-28 18:18:11	ordex	in this case openvpn is not instructed to take care of it
2017-01-28 18:19:56	slypknot	I learned something today ;)
2017-01-28 18:20:00	ordex	:D
2017-01-28 18:20:06	ordex	that happens to everybody everyday :P
2017-01-28 18:23:54	slypknot	not everybody or everyday
2017-01-28 18:28:53	ordex	:)
2017-01-28 18:32:36	slypknot	ordex: as you understand the code .. for that particular thread, openvpn literally does not know the TAP adapter has a v6 address and so throws the error it throws ?
2017-01-28 18:32:55	@cron2	ordex: oh, thanks for looking this up.  Which commit was that?
2017-01-28 18:33:05	ordex	cron2: 86e2fa5597fd1ad8e0102f134c63d6bc8cb7c291
2017-01-28 18:33:36	ordex	slypknot: openvpn does not know about IPv6, therefore it accepts to work with the ipv6 route only if it knows that it was itself to assign an ipv6 (i.e. via ifconfig)
2017-01-28 18:33:51	ordex	(did I make it too complicated? :D)
2017-01-28 18:33:53	@cron2	ordex: ah, thanks.  Indeed, that makes sense - we used to check "tun_ipv6" as a flag for "does it have v6?" and since that flag is gone...
2017-01-28 18:33:59	ordex	right
2017-01-28 18:34:06	ordex	now we check if we have "configured" it
2017-01-28 18:34:12	ordex	so the behaviour is changed a little bit
2017-01-28 18:34:30	ordex	but the current logic makes sense, because openvpn does knot know anything, except for what it configured by itself
2017-01-28 18:34:40	slypknot	ahh .. now i see :) -- not pushing tun-ipv6 etc
2017-01-28 18:34:52	@cron2	the combination "we did not set up ifconfig, but we're tasked to set up routing" was never a really supported feature, more like "a forgotten check"
2017-01-28 18:35:06	ordex	tun-ipv6 does not exist anymore :P
2017-01-28 18:35:22	ordex	cron2: guessed so, this is why I said that it probably "worked by accident"
2017-01-28 18:35:31	ordex	couldn't imagine it was wanted:D
2017-01-28 18:36:04	slypknot	TYVM for your input :)
2017-01-28 18:36:17	ordex	np
2017-01-28 18:36:32	slypknot	and cron2 too
2017-01-28 18:37:13	@cron2	hrmph, I can see cases where this actually makes sense
2017-01-28 18:37:23	ordex	argh
2017-01-28 18:37:28	ordex	like ?
2017-01-28 18:37:54	@cron2	RA with dynamic addresses (so you don't *know* the address), but sort of "some *other* gateway than the (bridged) default router needs to be target of the route"
2017-01-28 18:38:28	@cron2	OTOH, an up.sh script receives the name of the tap adapter, so there's nothing which would prevent it from installing the route (except, maybe, lack of permission...)
2017-01-28 18:38:47	ordex	right, I still see ths as something to be addresses outside of openvpn
2017-01-28 18:38:50	ordex	*this
2017-01-28 18:39:15	@cron2	"it can be made work by means of up.sh" = "not devastating brokenness, just puzzling"
2017-01-28 18:40:51	ordex	OTOH, if you think about that, when an interface comes up it already has its own local ipv6, therefore something is always configured. Thus openvpn may assume that some IPv6 is always there and configure the route anyway
2017-01-28 18:41:22	@cron2	on a tap adapter, you need a valid next-hop, which (if not fe80) needs to be in the configured subnet to work...
2017-01-28 18:41:54	@cron2	so, routes with fe80:: next-hops could always work (nowadays), while global addresses need a configured subnet
2017-01-28 18:42:14	@cron2	we could twist the check slightly...
2017-01-28 18:42:16	ordex	right
2017-01-28 18:43:53	ordex	although .. this is a new feature :) supporting routes via fe80:: even when no ip is assigned
2017-01-28 18:43:56	ordex	eheh
2017-01-28 18:44:22	@cron2	on a tun device, we really don't care about nexthops - I always install the route towards "tun1" (etc)
2017-01-28 18:44:28	ordex	what to do with the other router is still an open question (?) but, like you said before, the up script is probaly a better place for them
2017-01-28 18:44:32	@cron2	so this is only really relevant for tap mode
2017-01-28 18:44:36	ordex	yap
2017-01-28 18:45:15	@cron2	maybe we just turn this into a warning - "WARNING: openvpn did not configure an IPv6 address, IPv6 route installation might not work right"
2017-01-28 18:45:40	ordex	and then we let openvpn try to install the routes ?
2017-01-28 18:45:43	@cron2	yes
2017-01-28 18:45:52	ordex	it will still print an error when the command will fail - maybe the warning is not even required
2017-01-28 18:45:55	ordex	no?
2017-01-28 18:46:12	ordex	but the reason might not be clear though
2017-01-28 18:46:15	@cron2	we have the habit of warning users that their choice of option combinations might not do the right thing
2017-01-28 18:46:22	ordex	oky
2017-01-28 18:46:35	@cron2	so a warning might be good (so you can see it right away in the log without going hunting for "did it do ifconfig?")
2017-01-28 18:46:44	ordex	sounds more like a DISCLAIMER than a WARNING ehehehe
2017-01-28 18:46:48	ordex	yup
2017-01-28 18:46:52	ordex	sounds good
2017-01-28 18:46:54	@cron2	well, we call them WARNING elsewhere :)
2017-01-28 18:46:58	ordex	xD
2017-01-28 18:46:59	ordex	yeah
2017-01-28 18:47:04	ordex	just teasing
2017-01-28 18:50:19	slypknot	don't poke the bear ;)
2017-01-28 18:50:52	@cron2	slypknot: the original poster could open a trac ticket on this, with the result of ordex' and my discussion here...  it's not really a bug, more a "make this a supported feature, which happened to work in 2.3"
2017-01-28 18:51:50	slypknot	sure
2017-01-28 18:52:06	slypknot	i'll do it
2017-01-28 18:52:38	ordex	that would be nice, thanks :)
2017-01-28 18:52:50	slypknot	np
2017-01-28 18:53:00	slypknot	and thanks to you both for your tie :)
2017-01-28 18:53:06	slypknot	time*