Hi, On 06/06/18 23:40, Selva Nair wrote: >> I am not sure why you get those 2 routes. Do you have a more extensive >> log to show? It may help clearing up some doubts. > > Don't have access to those logs right now -- will post later. > > I had looked into it further and noticed that there was one other v4 > route being pushed from the server. On taking that out the error still > persisted but with "TEST ROUTES: 0/1...". > > That one remaining route was from redirect-gateway: even with > "redirect-gateway !ipv4", the direct v4 route to the server is being > set (redundant but shouldn't hurt). That route did succeed but our > logic for testing routes involves waiting for the interface to come up > with a v4 address which needs some tweaking. > > On Windows, v4-only works as long as a ifconfig address is in the > config (or pushed) as the address/mask is required for the tap driver. > Adding some v6 routes doesn't break it (I think) although those routes > may fail with warnings if there is no v6 address. I would like to see > v6-only work with minimal caveats as well. So, some > suggestions/comments for Windows: > > - Require either a v4 or a v6 address must be specified (this is not > essential for v6-only tunnels but makes the logic easier) >
The check you already suggested to modify in open_tun() should do the trick, no? Apparently that should be enough to ensure that at least of address family was configured (but I haven't tested on windows yet). > - The tap ioctl appears to work with 0/0 as address/mask, so no > special treatment needed there --- (improve the logging in this case). > This may need more testing > ok > - Wait for the interface to come up only if a v4 address is specified > (this wait is needed as the address may be set asynchronously by dhcp, > unlike other platforms) > ok > - Skip the above wait if there is no v4 address. As v6 address is set > synchronously no wait needed -- or change the logic used for deciding > whether the interface is up or not > ok > - Make sure v4 routes do not break a v6-only connection -- either > filter out and warn about v4 routes via the tun interface or just let > them fail with a warning but proceed with the rest of the tasks. > Setting v4 routes via other adapters should work > Do you think it makes sense to install other v4 routes (i.e. routes using the LAN gateway as next-hop) even though we have no IPv4 on tun? It feels like they would be totally unrelated. Gert? what do you think? > - Redirect-gateway with no v4 address: mutate to !ipv4 and also omit > the bypass route to the server. Or leaving that route in could be an > easier option and should work once the logic for checking the adpater > mentioned above is fixed > Yeah, this is actually happening also on linux, but it's applied externally to the route list. This is why I hadn't seen it before. I have a fix that prevents setting that route in the pipe. > - Test block-outside-dns (just to be sure as failure there is FATAL). > oh, thanks for this. >> >> On Linux the route_list is empty when there is no v4 and >> "gateway-redirect !ipv4" is set. > > Some how on Windows the bypass route gets set even with !ipv4. But > as said above that and any other non-tap routes should just work. > this relates to the comments above. Thanks! Cheers, -- Antonio Quartulli
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
