| 1 | 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 |
|---|
| 2 | 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 |
|---|
| 3 | 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 ? |
|---|
| 4 | 2017-01-28 17:54:52 slypknot hi* |
|---|
| 5 | 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 |
|---|
| 6 | 2017-01-28 17:57:27 slypknot also, the OP has not given full details of what they actually added yet .. |
|---|
| 7 | 2017-01-28 18:00:49 @cron2 slypknot: openvpn does not *care* what address the tap adapter has in *bridging tap* mode |
|---|
| 8 | 2017-01-28 18:00:58 @cron2 it is only interested in ethernet packets |
|---|
| 9 | 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 |
|---|
| 10 | 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 |
|---|
| 11 | 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 |
|---|
| 12 | 2017-01-28 18:04:14 slypknot but 2.3.x worked ok |
|---|
| 13 | 2017-01-28 18:04:23 slypknot apparently |
|---|
| 14 | 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 |
|---|
| 15 | 2017-01-28 18:06:11 slypknot for general user errors i can handle 99% .. but this one feels different |
|---|
| 16 | 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 ? |
|---|
| 17 | 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 |
|---|
| 18 | 2017-01-28 18:12:56 slypknot ordex: thanks .. i guess this is where my knowledge gets a bit too thin to understand properly |
|---|
| 19 | 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? |
|---|
| 20 | 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 |
|---|
| 21 | 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 |
|---|
| 22 | 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" |
|---|
| 23 | 2017-01-28 18:15:14 slypknot ordex: that was what i was thinking "worked before by accident" .. |
|---|
| 24 | 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 |
|---|
| 25 | 2017-01-28 18:16:01 ordex and it makes sense |
|---|
| 26 | 2017-01-28 18:16:04 slypknot cron2: forget* about it |
|---|
| 27 | 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 ? |
|---|
| 28 | 2017-01-28 18:16:29 ordex in this case it is not openvpn's role to set that route up |
|---|
| 29 | 2017-01-28 18:16:36 ordex or |
|---|
| 30 | 2017-01-28 18:16:44 ordex the guy can do that in an up.sh script (?) |
|---|
| 31 | 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 |
|---|
| 32 | 2017-01-28 18:17:50 slypknot v6* |
|---|
| 33 | 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 |
|---|
| 34 | 2017-01-28 18:18:11 ordex in this case openvpn is not instructed to take care of it |
|---|
| 35 | 2017-01-28 18:19:56 slypknot I learned something today ;) |
|---|
| 36 | 2017-01-28 18:20:00 ordex :D |
|---|
| 37 | 2017-01-28 18:20:06 ordex that happens to everybody everyday :P |
|---|
| 38 | 2017-01-28 18:23:54 slypknot not everybody or everyday |
|---|
| 39 | 2017-01-28 18:28:53 ordex :) |
|---|
| 40 | 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 ? |
|---|
| 41 | 2017-01-28 18:32:55 @cron2 ordex: oh, thanks for looking this up. Which commit was that? |
|---|
| 42 | 2017-01-28 18:33:05 ordex cron2: 86e2fa5597fd1ad8e0102f134c63d6bc8cb7c291 |
|---|
| 43 | 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) |
|---|
| 44 | 2017-01-28 18:33:51 ordex (did I make it too complicated? :D) |
|---|
| 45 | 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... |
|---|
| 46 | 2017-01-28 18:33:59 ordex right |
|---|
| 47 | 2017-01-28 18:34:06 ordex now we check if we have "configured" it |
|---|
| 48 | 2017-01-28 18:34:12 ordex so the behaviour is changed a little bit |
|---|
| 49 | 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 |
|---|
| 50 | 2017-01-28 18:34:40 slypknot ahh .. now i see :) -- not pushing tun-ipv6 etc |
|---|
| 51 | 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" |
|---|
| 52 | 2017-01-28 18:35:06 ordex tun-ipv6 does not exist anymore :P |
|---|
| 53 | 2017-01-28 18:35:22 ordex cron2: guessed so, this is why I said that it probably "worked by accident" |
|---|
| 54 | 2017-01-28 18:35:31 ordex couldn't imagine it was wanted:D |
|---|
| 55 | 2017-01-28 18:36:04 slypknot TYVM for your input :) |
|---|
| 56 | 2017-01-28 18:36:17 ordex np |
|---|
| 57 | 2017-01-28 18:36:32 slypknot and cron2 too |
|---|
| 58 | 2017-01-28 18:37:13 @cron2 hrmph, I can see cases where this actually makes sense |
|---|
| 59 | 2017-01-28 18:37:23 ordex argh |
|---|
| 60 | 2017-01-28 18:37:28 ordex like ? |
|---|
| 61 | 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" |
|---|
| 62 | 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...) |
|---|
| 63 | 2017-01-28 18:38:47 ordex right, I still see ths as something to be addresses outside of openvpn |
|---|
| 64 | 2017-01-28 18:38:50 ordex *this |
|---|
| 65 | 2017-01-28 18:39:15 @cron2 "it can be made work by means of up.sh" = "not devastating brokenness, just puzzling" |
|---|
| 66 | 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 |
|---|
| 67 | 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... |
|---|
| 68 | 2017-01-28 18:41:54 @cron2 so, routes with fe80:: next-hops could always work (nowadays), while global addresses need a configured subnet |
|---|
| 69 | 2017-01-28 18:42:14 @cron2 we could twist the check slightly... |
|---|
| 70 | 2017-01-28 18:42:16 ordex right |
|---|
| 71 | 2017-01-28 18:43:53 ordex although .. this is a new feature :) supporting routes via fe80:: even when no ip is assigned |
|---|
| 72 | 2017-01-28 18:43:56 ordex eheh |
|---|
| 73 | 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) |
|---|
| 74 | 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 |
|---|
| 75 | 2017-01-28 18:44:32 @cron2 so this is only really relevant for tap mode |
|---|
| 76 | 2017-01-28 18:44:36 ordex yap |
|---|
| 77 | 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" |
|---|
| 78 | 2017-01-28 18:45:40 ordex and then we let openvpn try to install the routes ? |
|---|
| 79 | 2017-01-28 18:45:43 @cron2 yes |
|---|
| 80 | 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 |
|---|
| 81 | 2017-01-28 18:45:55 ordex no? |
|---|
| 82 | 2017-01-28 18:46:12 ordex but the reason might not be clear though |
|---|
| 83 | 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 |
|---|
| 84 | 2017-01-28 18:46:22 ordex oky |
|---|
| 85 | 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?") |
|---|
| 86 | 2017-01-28 18:46:44 ordex sounds more like a DISCLAIMER than a WARNING ehehehe |
|---|
| 87 | 2017-01-28 18:46:48 ordex yup |
|---|
| 88 | 2017-01-28 18:46:52 ordex sounds good |
|---|
| 89 | 2017-01-28 18:46:54 @cron2 well, we call them WARNING elsewhere :) |
|---|
| 90 | 2017-01-28 18:46:58 ordex xD |
|---|
| 91 | 2017-01-28 18:46:59 ordex yeah |
|---|
| 92 | 2017-01-28 18:47:04 ordex just teasing |
|---|
| 93 | 2017-01-28 18:50:19 slypknot don't poke the bear ;) |
|---|
| 94 | 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" |
|---|
| 95 | 2017-01-28 18:51:50 slypknot sure |
|---|
| 96 | 2017-01-28 18:52:06 slypknot i'll do it |
|---|
| 97 | 2017-01-28 18:52:38 ordex that would be nice, thanks :) |
|---|
| 98 | 2017-01-28 18:52:50 slypknot np |
|---|
| 99 | 2017-01-28 18:53:00 slypknot and thanks to you both for your tie :) |
|---|
| 100 | 2017-01-28 18:53:06 slypknot time* |
|---|
| 101 | |
|---|
