Allow IPv6-only tunnels
cover Allow IPv6-only tunnels
This patchset allows clients and servers to work with a tunnel configured with IPv6 only.
Patches 2 and 3 are mere cosmetic changes and could be merged regardless of the rest (note that 3 depends on 2).
With this change a server can be configured by using only the '--server-ipv6' directive.
This will result in clients receiving only 'ifconfig-ipv6' setting in their push-reply (and no IPv4 at all).
Given that different components required changes in order to achieve this goal, the patchset has been organized as follows:
- patch 1 alters the tun logic (client & server side)
- patch 4 alters the ifconfig-pool logic (server side)
- patch 5 alters the server config logic (server side)
Although I have tested the patchset with different configurations and with our buildbots, such change would definitely benefit from a broader testing campaign (even before being merged).
Cheers,
Trac: #208
Antonio Quartulli (5):
tun: ensure interface can be configured with IPv6 only
pool: restyle ipv4/ipv6 members to improve readability
pool: convert pool 'type' to enum
pool: allow to configure an IPv6-only ifconfig-pool make server capable of starting with an IPv6-only tunnel
src/openvpn/helper.c | 8 +- src/openvpn/multi.c | 10 +- src/openvpn/pool.c | 179 ++++++++++++++-------- src/openvpn/pool.h | 31 ++-- src/openvpn/tun.c | 357 +++++++++++++++++++------------------------ 5 files changed, 308 insertions(+), 277 deletions(-)
Signature · 1 line
2.17.1
PATCH 1/5 tun: ensure interface can be configured with IPv6 only
From: Antonio Quartulli <[email protected]...>
This change ensures that an interface is properly brought up even when only IPv6 settings are configured.
This can be useful on a client that wants to ignore the IPv4 settings pushed by the server and configure only IPv6. To achieve the above, a client can usepull-filter ignore "ifconfig " (thanks Gert for this hint).
Trac: #208
--- src/openvpn/tun.c | 357 ++++++++++++++++++++-------------------------- 1 file changed, 158 insertions(+), 199 deletions(-)
src/openvpn/tun.c +158 -199
@@ -871,6 +871,161 @@ create_arbitrary_remote( struct tuntap *tt ) }#endif +/** +* do_ifconfig_ipv6 - perform platform specific ifconfig6 commands +* +* @param tt the tuntap interface context +* @param actual the human readable interface name +* @param mtu the MTU value to set the interface to +* @param es the environment to be used when executing the commands +* @param gc previously allocated garbage collector +*/ +static void +do_ifconfig_ipv6 (struct tuntap *tt,const char *actual,int tun_mtu, +const struct env_set *es,struct gc_arena *gc) +{ +const char *ifconfig_ipv6_local =NULL ; +struct argv argv; + +if (!tt->did_ifconfig_ipv6_setup) + { +return ; + } + + argv =argv_new (); + ifconfig_ipv6_local =print_in6_addr (tt->local_ipv6,0 , gc); + +#if defined(TARGET_LINUX ) +#ifdef ENABLE_IPROUTE +/* set the MTU for the device and bring it up */ +argv_printf (&argv,"%s link set dev %s up mtu %d" , iproute_path, actual, + tun_mtu); +argv_msg (M_INFO , &argv); +openvpn_execve_check (&argv, es,S_FATAL ,"Linux ip link set failed" ); + +argv_printf (&argv,"%s -6 addr add %s/%d dev %s" , iproute_path, + ifconfig_ipv6_local, tt->netbits_ipv6, actual); +argv_msg (M_INFO , &argv); +openvpn_execve_check (&argv, es,S_FATAL ,"Linux ip -6 addr add failed" ); +#else +argv_printf (&argv,"%s %s add %s/%d mtu %d up" ,IFCONFIG_PATH , actual, + ifconfig_ipv6_local, tt->netbits_ipv6, tun_mtu); +argv_msg (M_INFO , &argv); +openvpn_execve_check (&argv, es,S_FATAL ,"Linux ifconfig inet6 failed" ); +#endif +#elif defined(TARGET_ANDROID ) +char out6[64 ]; + +openvpn_snprintf (out6,sizeof (out6),"%s/%d" , + ifconfig_ipv6_local,tt->netbits_ipv6); +management_android_control (management,"IFCONFIG6" , out6); +#elif defined(TARGET_SOLARIS ) +argv_printf (&argv,"%s %s inet6 unplumb" ,IFCONFIG_PATH , actual); +argv_msg (M_INFO , &argv); +openvpn_execve_check (&argv, es,0 ,NULL ); + +if (tt->type ==DEV_TYPE_TUN ) + { +const char *ifconfig_ipv6_remote =print_in6_addr (tt->remote_ipv6,0 , + gc); + +argv_printf (&argv,"%s %s inet6 plumb %s/%d %s mtu %d up" , +IFCONFIG_PATH , actual, ifconfig_ipv6_local, + tt->netbits_ipv6, ifconfig_ipv6_remote, tun_mtu); + } +else /* tap mode */ + { +/* base IPv6 tap interface needs to be brought up first */ +argv_printf (&argv,"%s %s inet6 plumb up" ,IFCONFIG_PATH , actual); +argv_msg (M_INFO , &argv); + +if (!openvpn_execve_check (&argv, es,0 , +"Solaris ifconfig IPv6 (prepare) failed" )) + { +solaris_error_close (tt, es, actual, true); + } + +/* we might need to do "ifconfig %s inet6 auto-dhcp drop" +* after the system has noticed the interface and fired up +* the DHCPv6 client - but this takes quite a while, and the +* server will ignore the DHCPv6 packets anyway. So we don't. +*/ + +/* static IPv6 addresses need to go to a subinterface (tap0:1) */ +argv_printf (&argv,"%s %s inet6 addif %s/%d mtu %d up" ,IFCONFIG_PATH , + actual, ifconfig_ipv6_local, tt->netbits_ipv6, tun_mtu); + } +argv_msg (M_INFO , &argv); + +if (!openvpn_execve_check (&argv, es,0 ,"Solaris ifconfig IPv6 failed" )) + { +solaris_error_close (tt, es, actual, true); + } +#elif defined(TARGET_OPENBSD ) || defined(TARGET_NETBSD ) \ + || defined(TARGET_DARWIN ) || defined(TARGET_FREEBSD ) \ + || defined(TARGET_DRAGONFLY ) || defined(TARGET_AIX ) +argv_printf (&argv,"%s %s inet6 %s/%d mtu %d up" ,IFCONFIG_PATH , actual, + ifconfig_ipv6_local, tt->netbits_ipv6, tun_mtu); +argv_msg (M_INFO , &argv); + +#if defined(TARGET_AIX ) +/* AIX ifconfig will complain if it can't find ODM path in env */ + es =env_set_create (NULL ); +env_set_add (es,"ODMDIR=/etc/objrepos" ); +#endif + +openvpn_execve_check (&argv, es,S_FATAL , +"generic BSD ifconfig inet6 failed" ); + +#if defined(TARGET_AIX ) +env_set_destroy (es); +#endif + +#if !defined(TARGET_FREEBSD ) && !defined(TARGET_DRAGONFLY ) \ + && !defined(TARGET_AIX ) +/* and, hooray, we explicitely need to add a route... */ +add_route_connected_v6_net (tt, es); +#endif +#elif defined (_WIN32) +if (tt->options.ip_win32_type ==IPW32_SET_MANUAL ) + { +msg (M_INFO ,"******** NOTE: Please manually set the v6 IP of '%s' to %s (if it is not already set)" , + actual, ifconfig_ipv6_local); + } +else if (tt->options.msg_channel) + { +do_address_service (true,AF_INET6 , tt); +do_dns6_service (true, tt); + } +else + { +/* example: netsh interface ipv6 set address interface=42 +* 2001:608:8003::d store=active +*/ +char iface[64 ]; + +openvpn_snprintf (iface,sizeof (iface),"interface=%lu" , + tt->adapter_index); +argv_printf (&argv,"%s%sc interface ipv6 set address %s %s store=active" , +get_win_sys_path (),NETSH_PATH_SUFFIX , iface, + ifconfig_ipv6_local); +netsh_command (&argv,4 ,M_FATAL ); +/* set ipv6 dns servers if any are specified */ +netsh_set_dns6_servers (tt->options.dns6, tt->options.dns6_len, actual); + } + +/* explicit route needed */ +if (tt->options.ip_win32_type !=IPW32_SET_MANUAL ) + { +add_route_connected_v6_net (tt, es); + } +#else /* if defined(TARGET_LINUX) */ +msg (M_FATAL ,"Sorry, but I don't know how to do IPv6 'ifconfig' commands on this operating system. You should ifconfig your TUN/TAP device manually or use an --up script." ); +#endif /* if defined(TARGET_LINUX) */ + +argv_reset (&argv); +} +/* execute the ifconfig command through the shell */ void do_ifconfig(struct tuntap *tt,
@@ -886,8 +1041,6 @@ do_ifconfig(struct tuntap *tt,const char *ifconfig_local =NULL ;const char *ifconfig_remote_netmask =NULL ;const char *ifconfig_broadcast =NULL ; -const char *ifconfig_ipv6_local =NULL ; -bool do_ipv6 = false;struct argv argv =argv_new (); msg( M_DEBUG, "do_ifconfig, tt->did_ifconfig_ipv6_setup=%d",
@@ -904,12 +1057,6 @@ do_ifconfig(struct tuntap *tt, ifconfig_local =print_in_addr_t (tt->local,0 , &gc); ifconfig_remote_netmask =print_in_addr_t (tt->remote_netmask,0 , &gc); -if (tt->did_ifconfig_ipv6_setup) - { - ifconfig_ipv6_local =print_in6_addr (tt->local_ipv6,0 , &gc); - do_ipv6 = true; - } -/* * If TAP-style device, generate broadcast address. */
@@ -975,18 +1122,6 @@ do_ifconfig(struct tuntap *tt,argv_msg (M_INFO , &argv); openvpn_execve_check(&argv, es, S_FATAL, "Linux ip addr add failed"); } -if (do_ipv6) - { -argv_printf ( &argv, -"%s -6 addr add %s/%d dev %s" , - iproute_path, - ifconfig_ipv6_local, - tt->netbits_ipv6, - actual - ); -argv_msg (M_INFO , &argv); -openvpn_execve_check (&argv, es,S_FATAL ,"Linux ip -6 addr add failed" ); - } tt->did_ifconfig = true;#else /* ifdef ENABLE_IPROUTE */ if (tun)
@@ -1014,30 +1149,10 @@ do_ifconfig(struct tuntap *tt, }argv_msg (M_INFO , &argv);openvpn_execve_check (&argv, es,S_FATAL ,"Linux ifconfig failed" ); -if (do_ipv6) - { -argv_printf (&argv, -"%s %s add %s/%d" , -IFCONFIG_PATH , - actual, - ifconfig_ipv6_local, - tt->netbits_ipv6 - ); -argv_msg (M_INFO , &argv); -openvpn_execve_check (&argv, es,S_FATAL ,"Linux ifconfig inet6 failed" ); - } tt->did_ifconfig = true;#endif /*ENABLE_IPROUTE*/ #elif defined(TARGET_ANDROID) - -if (do_ipv6) - { -char out6[64 ]; -openvpn_snprintf (out6,sizeof (out6),"%s/%d" , ifconfig_ipv6_local,tt->netbits_ipv6); -management_android_control (management,"IFCONFIG6" , out6); - } -char out[64 ];char *top;
@@ -1120,59 +1235,6 @@ do_ifconfig(struct tuntap *tt,solaris_error_close (tt, es, actual, false); } -if (do_ipv6) - { -argv_printf (&argv,"%s %s inet6 unplumb" , -IFCONFIG_PATH , actual ); -argv_msg (M_INFO , &argv); -openvpn_execve_check (&argv, es,0 ,NULL ); - -if (tt->type ==DEV_TYPE_TUN ) - { -const char *ifconfig_ipv6_remote = -print_in6_addr (tt->remote_ipv6,0 , &gc); - -argv_printf (&argv, -"%s %s inet6 plumb %s/%d %s up" , -IFCONFIG_PATH , - actual, - ifconfig_ipv6_local, - tt->netbits_ipv6, - ifconfig_ipv6_remote - ); - } -else /* tap mode */ - { -/* base IPv6 tap interface needs to be brought up first -*/ -argv_printf (&argv,"%s %s inet6 plumb up" , -IFCONFIG_PATH , actual ); -argv_msg (M_INFO , &argv); -if (!openvpn_execve_check (&argv, es,0 ,"Solaris ifconfig IPv6 (prepare) failed" )) - { -solaris_error_close (tt, es, actual, true); - } - -/* we might need to do "ifconfig %s inet6 auto-dhcp drop" -* after the system has noticed the interface and fired up -* the DHCPv6 client - but this takes quite a while, and the -* server will ignore the DHCPv6 packets anyway. So we don't. -*/ - -/* static IPv6 addresses need to go to a subinterface (tap0:1) -*/ -argv_printf (&argv, -"%s %s inet6 addif %s/%d up" , -IFCONFIG_PATH , actual, - ifconfig_ipv6_local, tt->netbits_ipv6 ); - } -argv_msg (M_INFO , &argv); -if (!openvpn_execve_check (&argv, es,0 ,"Solaris ifconfig IPv6 failed" )) - { -solaris_error_close (tt, es, actual, true); - } - } -if (!tun && tt->topology ==TOP_SUBNET ) {/* Add a network route for the local tun interface */
@@ -1250,21 +1312,6 @@ do_ifconfig(struct tuntap *tt, add_route(&r, tt, 0, NULL, es); } -if (do_ipv6) - { -argv_printf (&argv, -"%s %s inet6 %s/%d" , -IFCONFIG_PATH , - actual, - ifconfig_ipv6_local, - tt->netbits_ipv6 - ); -argv_msg (M_INFO , &argv); -openvpn_execve_check (&argv, es,S_FATAL ,"OpenBSD ifconfig inet6 failed" ); - -/* and, hooray, we explicitely need to add a route... */ -add_route_connected_v6_net (tt, es); - } tt->did_ifconfig = true;#elif defined(TARGET_NETBSD)
@@ -1312,21 +1359,6 @@ do_ifconfig(struct tuntap *tt,argv_msg (M_INFO , &argv);openvpn_execve_check (&argv, es,S_FATAL ,"NetBSD ifconfig failed" ); -if (do_ipv6) - { -argv_printf (&argv, -"%s %s inet6 %s/%d" , -IFCONFIG_PATH , - actual, - ifconfig_ipv6_local, - tt->netbits_ipv6 - ); -argv_msg (M_INFO , &argv); -openvpn_execve_check (&argv, es,S_FATAL ,"NetBSD ifconfig inet6 failed" ); - -/* and, hooray, we explicitely need to add a route... */ -add_route_connected_v6_net (tt, es); - } tt->did_ifconfig = true;#elif defined(TARGET_DARWIN )
@@ -1398,22 +1430,6 @@ do_ifconfig(struct tuntap *tt, add_route(&r, tt, 0, NULL, es); } -if (do_ipv6) - { -argv_printf (&argv, -"%s %s inet6 %s/%d" , -IFCONFIG_PATH , - actual, - ifconfig_ipv6_local, - tt->netbits_ipv6 - ); -argv_msg (M_INFO , &argv); -openvpn_execve_check (&argv, es,S_FATAL ,"MacOS X ifconfig inet6 failed" ); - -/* and, hooray, we explicitely need to add a route... */ -add_route_connected_v6_net (tt, es); - } -#elif defined(TARGET_FREEBSD) || defined(TARGET_DRAGONFLY)in_addr_t remote_end;/* for "virtual" subnet topology */
@@ -1471,19 +1487,6 @@ do_ifconfig(struct tuntap *tt, add_route(&r, tt, 0, NULL, es); } -if (do_ipv6) - { -argv_printf (&argv, -"%s %s inet6 %s/%d" , -IFCONFIG_PATH , - actual, - ifconfig_ipv6_local, - tt->netbits_ipv6 - ); -argv_msg (M_INFO , &argv); -openvpn_execve_check (&argv, es,S_FATAL ,"FreeBSD ifconfig inet6 failed" ); - } -#elif defined(TARGET_AIX) {/* AIX ifconfig will complain if it can't find ODM path in env */
@@ -1509,18 +1512,6 @@ do_ifconfig(struct tuntap *tt,openvpn_execve_check (&argv, aix_es,S_FATAL ,"AIX ifconfig failed" ); tt->did_ifconfig = true; -if (do_ipv6) - { -argv_printf (&argv, -"%s %s inet6 %s/%d" , -IFCONFIG_PATH , - actual, - ifconfig_ipv6_local, - tt->netbits_ipv6 - ); -argv_msg (M_INFO , &argv); -openvpn_execve_check (&argv, aix_es,S_FATAL ,"AIX ifconfig inet6 failed" ); - } env_set_destroy(aix_es); }#elif defined (_WIN32)
@@ -1548,46 +1539,14 @@ do_ifconfig(struct tuntap *tt, tt->did_ifconfig = true; } -if (do_ipv6) - { -if (tt->options.ip_win32_type ==IPW32_SET_MANUAL ) - { -msg (M_INFO ,"******** NOTE: Please manually set the v6 IP of '%s' to %s (if it is not already set)" , - actual, - ifconfig_ipv6_local); - } -else if (tt->options.msg_channel) - { -do_address_service (true,AF_INET6 , tt); -do_dns6_service (true, tt); - } -else - { -/* example: netsh interface ipv6 set address interface=42 2001:608:8003::d store=active */ -char iface[64 ]; -openvpn_snprintf (iface,sizeof (iface),"interface=%lu" , tt->adapter_index ); -argv_printf (&argv, -"%s%sc interface ipv6 set address %s %s store=active" , -get_win_sys_path (), -NETSH_PATH_SUFFIX , - iface, - ifconfig_ipv6_local ); -netsh_command (&argv,4 ,M_FATAL ); -/* set ipv6 dns servers if any are specified */ -netsh_set_dns6_servers (tt->options.dns6, tt->options.dns6_len, actual); - } - -/* explicit route needed */ -if (tt->options.ip_win32_type !=IPW32_SET_MANUAL ) - { -add_route_connected_v6_net (tt, es); - } - }#else /* if defined(TARGET_LINUX) */ msg (M_FATAL ,"Sorry, but I don't know how to do 'ifconfig' commands on this operating system. You should ifconfig your TUN/TAP device manually or use an --up script." );#endif /* if defined(TARGET_LINUX) */ argv_reset (&argv); } + +do_ifconfig_ipv6 (tt, actual, tun_mtu, es, &gc); +gc_free (&gc); }
Signature · 1 line
2.17.1
PATCH 2/5 pool: restyle ipv4/ipv6 members to improve readability
In reply to Antonio QuartulliFrom: Antonio Quartulli <[email protected]...>
(This is only code refactoring)
IPv4 and IPv6 members are all part of the same flat hierarchy in the pool data structure, without a proper name convention.
Create 2 sub-structures to properly saperate IPv4 from IPv6 relate members. This should make the structure more organized and also slightly improve code readability.
--- src/openvpn/pool.c | 72 +++++++++++++++++++++++----------------------- src/openvpn/pool.h | 16 +++++++---- 2 files changed, 46 insertions(+), 42 deletions(-)
src/openvpn/pool.c +36 -36
@@ -66,7 +66,7 @@ ifconfig_pool_find(struct ifconfig_pool *pool, const char *common_name)int previous_usage =-1 ;int new_usage =-1 ; -for (i =0 ; i < pool->size; ++i) +for (i =0 ; i < pool->ipv4.size; ++i) {struct ifconfig_pool_entry *ipe = &pool->list[i];if (!ipe->in_use)
@@ -158,19 +158,19 @@ ifconfig_pool_init(int type, in_addr_t start, in_addr_t end,ASSERT (start <= end && end - start <IFCONFIG_POOL_MAX ); ALLOC_OBJ_CLEAR(pool, struct ifconfig_pool); - pool->type = type; + pool->ipv4.type = type; pool->duplicate_cn = duplicate_cn; -switch (type) +switch (pool->ipv4.type) {case IFCONFIG_POOL_30NET : - pool->base = start & ~3 ; - pool->size = (((end |3 ) +1 ) - pool->base) >>2 ; + pool->ipv4.base = start & ~3 ; + pool->ipv4.size = (((end |3 ) +1 ) - pool->ipv4.base) >>2 ;break ;case IFCONFIG_POOL_INDIV : - pool->base = start; - pool->size = end - start +1 ; + pool->ipv4.base = start; + pool->ipv4.size = end - start +1 ;break ;default :
@@ -178,30 +178,30 @@ ifconfig_pool_init(int type, in_addr_t start, in_addr_t end, }/* IPv6 pools are always "INDIV" type */ - pool->ipv6 = ipv6_pool; + pool->ipv6.enabled = ipv6_pool; -if (pool->ipv6) +if (pool->ipv6.enabled) { - pool->base_ipv6 = ipv6_base; - pool->size_ipv6 = ipv6_netbits>96 ? (1 <<(128 -ipv6_netbits) ) + pool->ipv6.base = ipv6_base; + pool->ipv6.size = ipv6_netbits >96 ? (1 << (128 - ipv6_netbits)) :IFCONFIG_POOL_MAX ;msg (D_IFCONFIG_POOL ,"IFCONFIG POOL IPv6: (IPv4) size=%d, size_ipv6=%d, netbits=%d, base_ipv6=%s" , - pool->size, pool->size_ipv6, ipv6_netbits, -print_in6_addr ( pool->base_ipv6,0 , &gc )); + pool->ipv4.size, pool->ipv6.size, ipv6_netbits, +print_in6_addr (pool->ipv6.base,0 , &gc));/* the current code is very simple and assumes that the IPv6 * pool is at least as big as the IPv4 pool, and we don't need * to do separate math etc. for IPv6 */ -ASSERT ( pool->size < pool->size_ipv6 ); +ASSERT (pool->ipv4.size < pool->ipv6.size); } - ALLOC_ARRAY_CLEAR(pool->list, struct ifconfig_pool_entry, pool->size); + ALLOC_ARRAY_CLEAR(pool->list, struct ifconfig_pool_entry, pool->ipv4.size);msg (D_IFCONFIG_POOL ,"IFCONFIG POOL: base=%s size=%d, ipv6=%d" , -print_in_addr_t (pool->base,0 , &gc), - pool->size, pool->ipv6 ); +print_in_addr_t (pool->ipv4.base,0 , &gc), + pool->ipv4.size, pool->ipv6.enabled);gc_free (&gc);return pool;
@@ -213,7 +213,7 @@ ifconfig_pool_free(struct ifconfig_pool *pool)if (pool) {int i; -for (i =0 ; i < pool->size; ++i) +for (i =0 ; i < pool->ipv4.size; ++i) {ifconfig_pool_entry_free (&pool->list[i], true); }
@@ -239,11 +239,11 @@ ifconfig_pool_acquire(struct ifconfig_pool *pool, in_addr_t *local, in_addr_t *r ipe->common_name =string_alloc (common_name,NULL ); } -switch (pool->type) +switch (pool->ipv4.type) {case IFCONFIG_POOL_30NET : { -in_addr_t b = pool->base + (i <<2 ); +in_addr_t b = pool->ipv4.base + (i <<2 ); *local = b +1 ; *remote = b +2 ;break ;
@@ -251,7 +251,7 @@ ifconfig_pool_acquire(struct ifconfig_pool *pool, in_addr_t *local, in_addr_t *rcase IFCONFIG_POOL_INDIV : { -in_addr_t b = pool->base + i; +in_addr_t b = pool->ipv4.base + i; *local =0 ; *remote = b;break ;
@@ -262,9 +262,9 @@ ifconfig_pool_acquire(struct ifconfig_pool *pool, in_addr_t *local, in_addr_t *r }/* IPv6 pools are always INDIV (--linear) */ -if (pool->ipv6 && remote_ipv6) +if (pool->ipv6.enabled && remote_ipv6) { - *remote_ipv6 =add_in6_addr ( pool->base_ipv6, i ); + *remote_ipv6 =add_in6_addr (pool->ipv6.base, i); } }return i;
@@ -274,7 +274,7 @@ bool ifconfig_pool_release(struct ifconfig_pool *pool, ifconfig_pool_handle hand, const bool hard) { bool ret = false; -if (pool && hand >=0 && hand < pool->size) +if (pool && hand >=0 && hand < pool->ipv4.size) {ifconfig_pool_entry_free (&pool->list[hand], hard); ret = true;
@@ -291,17 +291,17 @@ ifconfig_pool_ip_base_to_handle(const struct ifconfig_pool *pool, const in_addr_ {ifconfig_pool_handle ret =-1 ; -switch (pool->type) +switch (pool->ipv4.type) {case IFCONFIG_POOL_30NET : { - ret = (addr - pool->base) >>2 ; + ret = (addr - pool->ipv4.base) >>2 ;break ; }case IFCONFIG_POOL_INDIV : { - ret = (addr - pool->base); + ret = (addr - pool->ipv4.base);break ; }
@@ -309,7 +309,7 @@ ifconfig_pool_ip_base_to_handle(const struct ifconfig_pool *pool, const in_addr_ASSERT (0 ); } -if (ret <0 || ret >= pool->size) +if (ret <0 || ret >= pool->ipv4.size) { ret =-1 ; }
@@ -322,19 +322,19 @@ ifconfig_pool_handle_to_ip_base(const struct ifconfig_pool *pool, ifconfig_pool_ {in_addr_t ret =0 ; -if (hand >=0 && hand < pool->size) +if (hand >=0 && hand < pool->ipv4.size) { -switch (pool->type) +switch (pool->ipv4.type) {case IFCONFIG_POOL_30NET : { - ret = pool->base + (hand <<2 ); + ret = pool->ipv4.base + (hand <<2 );break ; }case IFCONFIG_POOL_INDIV : { - ret = pool->base + hand; + ret = pool->ipv4.base + hand;break ; }
@@ -352,9 +352,9 @@ ifconfig_pool_handle_to_ipv6_base(const struct ifconfig_pool *pool, ifconfig_poostruct in6_addr ret = in6addr_any;/* IPv6 pools are always INDIV (--linear) */ -if (hand >=0 && hand < pool->size_ipv6) +if (hand >=0 && hand < pool->ipv6.size) { - ret =add_in6_addr ( pool->base_ipv6, hand ); + ret =add_in6_addr ( pool->ipv6.base, hand ); }return ret; }
@@ -382,13 +382,13 @@ ifconfig_pool_list(const struct ifconfig_pool *pool, struct status_output *out)struct gc_arena gc =gc_new ();int i; -for (i =0 ; i < pool->size; ++i) +for (i =0 ; i < pool->ipv4.size; ++i) {const struct ifconfig_pool_entry *e = &pool->list[i];if (e->common_name) {const in_addr_t ip =ifconfig_pool_handle_to_ip_base (pool, i); -if (pool->ipv6) +if (pool->ipv6.enabled) {struct in6_addr ip6 =ifconfig_pool_handle_to_ipv6_base (pool, i); status_printf(out, "%s,%s,%s",
src/openvpn/pool.h +10 -6
@@ -47,13 +47,17 @@ struct ifconfig_pool_entrystruct ifconfig_pool { -in_addr_t base; -int size; -int type;bool duplicate_cn; -bool ipv6; -struct in6_addr base_ipv6; -unsigned int size_ipv6; +struct { +int type; +in_addr_t base; +int size; + } ipv4; +struct { +bool enabled; +struct in6_addr base; +unsigned int size; + } ipv6;struct ifconfig_pool_entry *list; };
Signature · 1 line
2.17.1
PATCH 3/5 pool: convert pool 'type' to enum
In reply to Antonio QuartulliFrom: Antonio Quartulli <[email protected]...>
The pool 'type' member is actually an enumered type, therefore declare it as 'enum' to improve static code analisys and readability.
--- src/openvpn/pool.c | 2 +- src/openvpn/pool.h | 11 +++++++---- 2 files changed, 8 insertions(+), 5 deletions(-)
src/openvpn/pool.c +1 -1
@@ -147,7 +147,7 @@ ifconfig_pool_verify_range(const int msglevel, const in_addr_t start, const in_a }struct ifconfig_pool * -ifconfig_pool_init (int type,in_addr_t start,in_addr_t end, +ifconfig_pool_init (enum pool_type type,in_addr_t start,in_addr_t end,const bool duplicate_cn,const bool ipv6_pool,const struct in6_addr ipv6_base,const int ipv6_netbits )
src/openvpn/pool.h +7 -4
@@ -34,8 +34,11 @@#define IFCONFIG_POOL_MAX 65536#define IFCONFIG_POOL_MIN_NETBITS 16 -#define IFCONFIG_POOL_30NET 0 -#define IFCONFIG_POOL_INDIV 1 +enum pool_type +{ +IFCONFIG_POOL_30NET , +IFCONFIG_POOL_INDIV +};struct ifconfig_pool_entry {
@@ -49,7 +52,7 @@ struct ifconfig_pool {bool duplicate_cn;struct { -int type; +enum pool_type type;in_addr_t base;int size; } ipv4;
@@ -69,7 +72,7 @@ struct ifconfig_pool_persisttypedef int ifconfig_pool_handle ; -struct ifconfig_pool *ifconfig_pool_init (int type,in_addr_t start,in_addr_t end,const bool duplicate_cn,const bool ipv6_pool,const struct in6_addr ipv6_base,const int ipv6_netbits ); +struct ifconfig_pool *ifconfig_pool_init (enum pool_type type,in_addr_t start,in_addr_t end,const bool duplicate_cn,const bool ipv6_pool,const struct in6_addr ipv6_base,const int ipv6_netbits );void ifconfig_pool_free (struct ifconfig_pool *pool);
Signature · 1 line
2.17.1
PATCH 4/5 pool: allow to configure an IPv6-only ifconfig-pool
In reply to Antonio QuartulliFrom: Antonio Quartulli <[email protected]...>
With this change a server is allowed to allocate an IPv6-only pool. This is required to make it capable of managing an IPv6-only tunnel.
Trac: #208
--- src/openvpn/multi.c | 7 ++- src/openvpn/pool.c | 139 ++++++++++++++++++++++++++++++-------------- src/openvpn/pool.h | 8 ++- 3 files changed, 107 insertions(+), 47 deletions(-)
src/openvpn/multi.c +5 -2
@@ -397,7 +397,8 @@ multi_init(struct multi_context *m, struct context *t, bool tcp_mode, int thread pool_type =IFCONFIG_POOL_30NET ; } - m->ifconfig_pool = ifconfig_pool_init(pool_type, + m->ifconfig_pool = ifconfig_pool_init(t->options.ifconfig_pool_defined, + pool_type, t->options.ifconfig_pool_start, t->options.ifconfig_pool_end, t->options.duplicate_cn,
@@ -1497,7 +1498,9 @@ multi_select_virtual_addr(struct multi_context *m, struct multi_instance *mi)const int tunnel_topology =TUNNEL_TOPOLOGY (mi->context.c1.tuntap);msg (M_INFO ,"MULTI_sva: pool returned IPv4=%s, IPv6=%s" , -print_in_addr_t ( remote,0 , &gc ), + (mi->context.options.ifconfig_pool_defined + ?print_in_addr_t (remote,0 , &gc) + :"(Not enabled)" , (mi->context.options.ifconfig_ipv6_pool_defined ?print_in6_addr ( remote_ipv6,0 , &gc ) : "(Not enabled)") );
src/openvpn/pool.c +95 -44
224 lines not on this page · raw message
src/openvpn/pool.h +7 -1
@@ -52,6 +52,7 @@ struct ifconfig_pool {bool duplicate_cn;struct { +bool enabled;enum pool_type type;in_addr_t base;int size;
@@ -72,7 +73,12 @@ struct ifconfig_pool_persisttypedef int ifconfig_pool_handle ; -struct ifconfig_pool *ifconfig_pool_init (enum pool_type type,in_addr_t start,in_addr_t end,const bool duplicate_cn,const bool ipv6_pool,const struct in6_addr ipv6_base,const int ipv6_netbits ); +struct ifconfig_pool *ifconfig_pool_init (const bool ipv4_pool, +enum pool_type type,in_addr_t start, +in_addr_t end,const bool duplicate_cn, +const bool ipv6_pool, +const struct in6_addr ipv6_base, +const int ipv6_netbits);void ifconfig_pool_free (struct ifconfig_pool *pool);
Signature · 1 line
2.17.1
PATCH 5/5 make server capable of starting with an IPv6-only tunnel
In reply to Antonio QuartulliFrom: Antonio Quartulli <[email protected]...>
Due to the current logic it is not possible for a server to create an IPv6-only tunnel, because OpenVPN mandates the existance of an IPv4 configuration (even if fake).
This change relaxes this constraint and allows servers to bring up tunnels without any IPv4 setting at all.
For the user this means that a server can be configured with just the "--server-ipv6" directive and no "--server" at all.
Trac: #208
--- src/openvpn/helper.c | 8 ++++++-- src/openvpn/multi.c | 3 ++- 2 files changed, 8 insertions(+), 3 deletions(-)
src/openvpn/helper.c +6 -2
@@ -177,10 +177,11 @@ helper_client_server(struct options *o)*/ if (o->server_ipv6_defined) { -if (!o->server_defined) +if (o->client) { -msg (M_USAGE ,"--server-ipv6 must be used together with --server" ); +msg (M_USAGE ,"--server and --client cannot be used together" ); } +if (o->server_flags &SF_NOPOOL ) {msg (M_USAGE ,"--server-ipv6 is incompatible with 'nopool' option" );
@@ -190,6 +191,9 @@ helper_client_server(struct options *o)msg (M_USAGE ,"--server-ipv6 already defines an ifconfig-ipv6-pool, so you can't also specify --ifconfig-pool explicitly" ); } + o->mode =MODE_SERVER ; + o->tls_server = true; +/* local ifconfig is "base address + 1" and "+2" */ o->ifconfig_ipv6_local =print_in6_addr (add_in6_addr ( o->server_network_ipv6,1 ),0 , &o->gc );
src/openvpn/multi.c +2 -1
@@ -388,7 +388,8 @@ multi_init(struct multi_context *m, struct context *t, bool tcp_mode, int thread* differently based on whether a tun or tap style * tunnel. */ -if (t->options.ifconfig_pool_defined) +if (t->options.ifconfig_pool_defined + || t->options.ifconfig_ipv6_pool_defined) {int pool_type =IFCONFIG_POOL_INDIV ;
Signature · 1 line
2.17.1
PATCH v2 4/5 pool: allow to configure an IPv6-only ifconfig-pool
In reply to Antonio QuartulliFrom: Antonio Quartulli <[email protected]...>
With this change a server is allowed to allocate an IPv6-only pool. This is required to make it capable of managing an IPv6-only tunnel.
Trac: #208
---
v2:
- fix syntax error by adding missing ')'
src/openvpn/multi.c | 7 ++- src/openvpn/pool.c | 139 ++++++++++++++++++++++++++++++-------------- src/openvpn/pool.h | 8 ++- 3 files changed, 107 insertions(+), 47 deletions(-)
src/openvpn/multi.c +5 -2
@@ -397,7 +397,8 @@ multi_init(struct multi_context *m, struct context *t, bool tcp_mode, int thread pool_type =IFCONFIG_POOL_30NET ; } - m->ifconfig_pool = ifconfig_pool_init(pool_type, + m->ifconfig_pool = ifconfig_pool_init(t->options.ifconfig_pool_defined, + pool_type, t->options.ifconfig_pool_start, t->options.ifconfig_pool_end, t->options.duplicate_cn,
@@ -1497,7 +1498,9 @@ multi_select_virtual_addr(struct multi_context *m, struct multi_instance *mi)const int tunnel_topology =TUNNEL_TOPOLOGY (mi->context.c1.tuntap);msg (M_INFO ,"MULTI_sva: pool returned IPv4=%s, IPv6=%s" , -print_in_addr_t ( remote,0 , &gc ), + (mi->context.options.ifconfig_pool_defined + ?print_in_addr_t (remote,0 , &gc) + :"(Not enabled)" ), (mi->context.options.ifconfig_ipv6_pool_defined ?print_in6_addr ( remote_ipv6,0 , &gc ) :"(Not enabled)" ) );
src/openvpn/pool.c +95 -44
224 lines not on this page · raw message
src/openvpn/pool.h +7 -1
@@ -52,6 +52,7 @@ struct ifconfig_pool {bool duplicate_cn;struct { +bool enabled;enum pool_type type;in_addr_t base;int size;
@@ -72,7 +73,12 @@ struct ifconfig_pool_persisttypedef int ifconfig_pool_handle ; -struct ifconfig_pool *ifconfig_pool_init (enum pool_type type,in_addr_t start,in_addr_t end,const bool duplicate_cn,const bool ipv6_pool,const struct in6_addr ipv6_base,const int ipv6_netbits ); +struct ifconfig_pool *ifconfig_pool_init (const bool ipv4_pool, +enum pool_type type,in_addr_t start, +in_addr_t end,const bool duplicate_cn, +const bool ipv6_pool, +const struct in6_addr ipv6_base, +const int ipv6_netbits);void ifconfig_pool_free (struct ifconfig_pool *pool);
Signature · 1 line
2.17.1
Hi,
I have applied these 5 patches to master on ubuntu 18.04LTS The resulting binary gave server+client ipv6 *only* tunnel over ipv4 network. 100% success
Using only: --server-ipv6 12fc:1918::10:186:0:0/112
I am sure buildbot runs more extensive tests than my single test but I would be happy to ACK this if i could work out how to.
Thanks
Quoted 41 lines · Antonio Quartulli
This patchset allows clients and servers to work with a tunnel configured with IPv6 only.
Patches 2 and 3 are mere cosmetic changes and could be merged regardless of the rest (note that 3 depends on 2).
With this change a server can be configured by using only the '--server-ipv6' directive.
This will result in clients receiving only 'ifconfig-ipv6' setting in their push-reply (and no IPv4 at all).Given that different components required changes in order to achieve this goal, the patchset has been organized as follows:
- patch 1 alters the tun logic (client & server side)
- patch 4 alters the ifconfig-pool logic (server side)
- patch 5 alters the server config logic (server side)Although I have tested the patchset with different configurations and with our buildbots, such change would definitely benefit from a broader testing campaign (even before being merged).
Cheers,
Trac: #208
Antonio Quartulli (5):
tun: ensure interface can be configured with IPv6 only
pool: restyle ipv4/ipv6 members to improve readability
pool: convert pool 'type' to enum
pool: allow to configure an IPv6-only ifconfig-pool make server capable of starting with an IPv6-only tunnelsrc/openvpn/helper.c | 8 +- src/openvpn/multi.c | 10 +- src/openvpn/pool.c | 179 ++++++++++++++-------- src/openvpn/pool.h | 31 ++-- src/openvpn/tun.c | 357 +++++++++++++++++++------------------------ 5 files changed, 308 insertions(+), 277 deletions(-)
Sorry, that should be:
server Ubuntu 18.04
client arch linux
but the resulting vpn is ipv6 only and works well.
Quoted 56 lines · tincanteksup
Hi,
I have applied these 5 patches to master on ubuntu 18.04LTS The resulting binary gave server+client ipv6 *only* tunnel over ipv4 network. 100% success
Using only: --server-ipv6 12fc:1918::10:186:0:0/112
I am sure buildbot runs more extensive tests than my single test but I would be happy to ACK this if i could work out how to.
Thanks
Quoted 41 lines · Antonio Quartulli
This patchset allows clients and servers to work with a tunnel configured with IPv6 only.
Patches 2 and 3 are mere cosmetic changes and could be merged regardless of the rest (note that 3 depends on 2).
With this change a server can be configured by using only the '--server-ipv6' directive.
This will result in clients receiving only 'ifconfig-ipv6' setting in their push-reply (and no IPv4 at all).Given that different components required changes in order to achieve this goal, the patchset has been organized as follows:
- patch 1 alters the tun logic (client & server side)
- patch 4 alters the ifconfig-pool logic (server side)
- patch 5 alters the server config logic (server side)Although I have tested the patchset with different configurations and with our buildbots, such change would definitely benefit from a broader testing campaign (even before being merged).
Cheers,
Trac: #208
Antonio Quartulli (5):
tun: ensure interface can be configured with IPv6 only
pool: restyle ipv4/ipv6 members to improve readability
pool: convert pool 'type' to enum
pool: allow to configure an IPv6-only ifconfig-pool make server capable of starting with an IPv6-only tunnel
src/openvpn/helper.c| 8 +-
src/openvpn/multi.c | 10 +-
src/openvpn/pool.c | 179 ++++++++++++++-------- src/openvpn/pool.h | 31 ++--
src/openvpn/tun.c | 357 +++++++++++++++++++------------------------5 files changed, 308 insertions(+), 277 deletions(-)
Re: [Openvpn-devel] [PATCH 1/5] tun: ensure interface can be configured with IPv6 only
In reply to Antonio QuartulliHi,
Prelimiaries: I think this whole series should only go to 2.5, as it has the potential to be fairly intrusive and uncover hidden bugs - I've discussed this with Antonio already (and we're in agreement) but for the sake of the list.
Quoted 5 lines · Antonio Quartulli
From: Antonio Quartulli <[email protected]...>
This change ensures that an interface is properly brought up even when only IPv6 settings are configured.
Quoted 8 lines
This can be useful on a client that wants to ignore the IPv4 settings pushed by the server and configure only IPv6. To achieve the above, a client can use
pull-filter ignore "ifconfig "(thanks Gert for this hint).Trac: #208
Cc Gert Doering <[email protected]...>Signed-off-by Antonio Quartulli <[email protected]...>
ACK on the feature, but NAK on "we can do this more nicely" reasons :-)
First, I'd leave off the bits about "this can be useful" of the commit message - because that's not the point of this patch, you can *ignore*
the settings already today. Maybe word this
"This patch enables the client to run IPv6-only on the tun/tap interface,
but will not make it ignore a pushed IPv4 config. To achieve that, one can use 'pull-filter ignore "ifconfig "' on the client or 'push-filter' on the server".
(if we want to go into this here at all)
Then, splitting do_ifconfig() in a "we do all in here, except for IPv6, which is in do_ifconfig_ipv6()" is not looking right - if we do it, do it right, as in "split out do_ifconfig_ipv4() as well", make things fully symmetric wrt ipv4/ipv6, and have do_ifconfig() look something like this:
do_ifconfig()
{
msg (M_DEBUG, "do_ifconfig, ipv4=%d, ipv6=%d", u
tt->did_ifconfig_setup, tt->did_ifconfig_ipv6_setup );
if (tt->did_ifconfig_setup)
do_ifconfig_ipv4()
if (tt->did_ifconfig_ipv6_setup)
do_ifconfig_ipv6() if (management)
management_set_state()
}
... and get rid of the "if (tt->did_ifconfig_setup)" extra nesting level in do_ifconfig() and do_ifconfig_ipv6().
Of course we'll also need to check if typical consumers of the management interface explode if you're not giving an IPv4 address to them...
Selva, Jonathan, how will our GUI and Tunnelblick handle that?
gert
Signature · 6 lines
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany [email protected]...Re: [Openvpn-devel] [PATCH v2 4/5] pool: allow to configure an IPv6-only ifconfig-pool
In reply to Antonio QuartulliHI,
Quoted 5 lines · Antonio Quartulli
From: Antonio Quartulli <[email protected]...>
With this change a server is allowed to allocate an IPv6-only pool. This is required to make it capable of managing an IPv6-only tunnel.
Without having done much review here, just one initial caveat: did you test this with --ifconfig-pool-persist? What happens?
gert
Signature · 6 lines
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany [email protected]...Re: [Openvpn-devel] [PATCH 1/5] tun: ensure interface can be configured with IPv6 only
In reply to Gert DoeringHi,
Quoted 30 lines · Gert Doering
Hi,
Prelimiaries: I think this whole series should only go to 2.5, as it has the potential to be fairly intrusive and uncover hidden bugs - I've discussed this with Antonio already (and we're in agreement) but for the sake of the list.
Quoted 5 lines · Antonio Quartulli
From: Antonio Quartulli <[email protected]...>
This change ensures that an interface is properly brought up even when only IPv6 settings are configured.
Quoted 8 lines
This can be useful on a client that wants to ignore the IPv4 settings pushed by the server and configure only IPv6. To achieve the above, a client can use
pull-filter ignore "ifconfig "(thanks Gert for this hint).Trac: #208
Cc Gert Doering <[email protected]...>Signed-off-by Antonio Quartulli <[email protected]...>ACK on the feature, but NAK on "we can do this more nicely" reasons :-)
First, I'd leave off the bits about "this can be useful" of the commit message - because that's not the point of this patch, you can *ignore*
the settings already today. Maybe word this
Quoted 6 lines
"This patch enables the client to run IPv6-only on the tun/tap interface,
but will not make it ignore a pushed IPv4 config. To achieve that, one can use 'pull-filter ignore "ifconfig "' on the client or 'push-filter' on the server".(if we want to go into this here at all)
I don't think this belongs here and such advice could include other details like what
to do with routes, redirect gateway etc. Better add it to the howto.
A more serious thing:
- On windows we require that ifconfig is required with --dev tun. This has to change. Could be tricky as TAP_WIN_IOCTL_CONFIG_TUN requires a v4 address.
Minor stuff:
- If no v4 address is set but still v4 routes are specified we should at least print a warning as we do with ipv6.
- redirect-gateway : we may want to force !ipv4 if ifconfig is missing or should we mutate it to "ipv6 !ipv4" ?
May be there are more such nuances -- this patch will need some thoroug testing before being ready for review.
Quoted 5 lines
Of course we'll also need to check if typical consumers of the management interface explode if you're not giving an IPv4 address to them...
Selva, Jonathan, how will our GUI and Tunnelblick handle that?
Windows GUI uses configured IPs only for logging and display so I don't think it will complain, let alone explode. If any changes are needed, likely to be minimal. We have to just keep the format of reporting configured IPs unchanged even if some elements may be blank.
Selva
Re: [Openvpn-devel] [PATCH v2 4/5] pool: allow to configure an IPv6-only ifconfig-pool
In reply to Gert DoeringHi,
Quoted 11 lines · Gert Doering
HI,
Quoted 5 lines · Antonio Quartulli
From: Antonio Quartulli <[email protected]...>
With this change a server is allowed to allocate an IPv6-only pool. This is required to make it capable of managing an IPv6-only tunnel.
Without having done much review here, just one initial caveat: did you test this with --ifconfig-pool-persist? What happens?
It should just be ignored.
At the moment pool-persist works only for IPv4 and there is no support for IPv6. This has not been changed by this patchset.
I added a check about it in ifconfig_pool_read():
521 /* IPv6 logic not implemented yet, therefore bail out if no IPv4
pool was
522 * configured
523 */
524 if (pool && !pool->ipv4.enabled)
525 {
526 return;
527 }
However, I will test to see it if works as expected.
Cheers,
Signature · 1 line
Antonio Quartulli
Re: [Openvpn-devel] [PATCH 1/5] tun: ensure interface can be configured with IPv6 only
In reply to Selva NairHi,
On 05/06/18 23:54, Selva Nair wrote:
[cut]
Quoted 11 lines
Quoted 11 lines
ACK on the feature, but NAK on "we can do this more nicely" reasons :-)
First, I'd leave off the bits about "this can be useful" of the commit message - because that's not the point of this patch, you can *ignore*
the settings already today. Maybe word this"This patch enables the client to run IPv6-only on the tun/tap interface,
but will not make it ignore a pushed IPv4 config. To achieve that, one can use 'pull-filter ignore "ifconfig "' on the client or 'push-filter' on the server".
Quoted 7 lines
Quoted 1 line
(if we want to go into this here at all)
I don't think this belongs here and such advice could include other details like what
to do with routes, redirect gateway etc. Better add it to the howto.
Agreed to both comments. I'll trim the commit and make it more objective.
Quoted 5 lines
A more serious thing:
- On windows we require that ifconfig is required with --dev tun. This has to change. Could be tricky as
TAP_WIN_IOCTL_CONFIG_TUNrequires a v4 address.
Is 0.0.0.0 a valid address for this ioctl?
Or does it need to be meaningful?
I think this could be tested by applying only this patch and ignoring the pushed 'ifconfig ' directive (as explained in the commit).
Quoted 6 lines
Minor stuff:
- If no v4 address is set but still v4 routes are specified we should at least print a warning as we do with ipv6.
Right. Will add the warning.
Quoted 3 lines
- redirect-gateway : we may want to force !ipv4 if ifconfig is missing or should we mutate it to "ipv6 !ipv4" ?
This is more about changing the current default behaviour.
Why is it !ipv6 by default in the first place?
I'd rather keep default behaviours as they are now, to avoid messing up the user experience.
However, I also understand that if there is no IPv4 and gateway-redirect is specified, then the user wants a default route for IPv6.
Maybe we should keep the current behaviour as it is (!ipv6 by default) but print a warning when only ifconfig-ipv6 is provided?
Quoted 7 lines
May be there are more such nuances -- this patch will need some thoroug testing before being ready for review.
Quoted 4 lines
Of course we'll also need to check if typical consumers of the management interface explode if you're not giving an IPv4 address to them...
Quoted 9 lines
Quoted 1 line
Selva, Jonathan, how will our GUI and Tunnelblick handle that?
Windows GUI uses configured IPs only for logging and display so I don't think it will complain, let alone explode. If any changes are needed, likely to be minimal. We have to just keep the format of reporting configured IPs unchanged even if some elements may be blank.
Selva
Cheers,
Signature · 1 line
Antonio Quartulli
Re: [Openvpn-devel] [PATCH 1/5] tun: ensure interface can be configured with IPv6 only
Hi,
Quoted 25 lines · Antonio Quartulli
Hi,
On 05/06/18 23:54, Selva Nair wrote:
[cut]Quoted 11 lines
Quoted 11 lines
ACK on the feature, but NAK on "we can do this more nicely" reasons :-)
First, I'd leave off the bits about "this can be useful" of the commit message - because that's not the point of this patch, you can *ignore*
the settings already today. Maybe word this"This patch enables the client to run IPv6-only on the tun/tap interface,
but will not make it ignore a pushed IPv4 config. To achieve that, one can use 'pull-filter ignore "ifconfig "' on the client or 'push-filter' on the server".Quoted 7 lines
Quoted 1 line
(if we want to go into this here at all)
I don't think this belongs here and such advice could include other details like what
to do with routes, redirect gateway etc. Better add it to the howto.Agreed to both comments. I'll trim the commit and make it more objective.
Quoted 7 lines
Quoted 5 lines
A more serious thing:
- On windows we require that ifconfig is required with --dev tun. This has to change. Could be tricky as
TAP_WIN_IOCTL_CONFIG_TUNrequires a v4 address.Is 0.0.0.0 a valid address for this ioctl?
I do not know the tapdriver code enough to answer that.. -- will take a look.
Quoted 3 lines
Or does it need to be meaningful?
I think this could be tested by applying only this patch and ignoring the pushed 'ifconfig ' directive (as explained in the commit).
I haven't tested it, but pretty sure that'll just fail with "--dev tun also requires ifconfig" or some such message as can be seen from open_tun() code in tun.c -- it requires did_ifconfig_setup == true which won't get set in init_tun if there are no ifconfig parameters.
How to work around that depends on what the tap driver expects in the v4 address. Ideally, we should patch the driver to work without a V4 address...
Selva
Re: [Openvpn-devel] [PATCH v2 4/5] pool: allow to configure an IPv6-only ifconfig-pool
In reply to Antonio QuartulliHi,
Quoted 6 lines · Antonio Quartulli
Quoted 2 lines
Without having done much review here, just one initial caveat: did you test this with --ifconfig-pool-persist? What happens?
It should just be ignored.
At the moment pool-persist works only for IPv4 and there is no support for IPv6. This has not been changed by this patchset.
Well, it does save the (calculated) v6 address into the save file...
So, what happens if you run a server with --ifconfig-pool-persist and no IPv4? Will it crash, not write anything to the file, write garbage?
Quoted 10 lines
I added a check about it in
ifconfig_pool_read():521 /* IPv6 logic not implemented yet, therefore bail out if no IPv4
pool was
522 * configured
523 */
524 if (pool && !pool->ipv4.enabled)
525 {
526 return;
527 }
We should aim to make this work as well (but it could be patch 6 of the series :-)).
gert
Signature · 6 lines
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany [email protected]...Re: [Openvpn-devel] [PATCH 1/5] tun: ensure interface can be configured with IPv6 only
In reply to Antonio QuartulliHi,
Quoted 10 lines · Antonio Quartulli
Why is it !ipv6 by default in the first place?
I'd rather keep default behaviours as they are now, to avoid messing up the user experience.
However, I also understand that if there is no IPv4 and gateway-redirect is specified, then the user wants a default route for IPv6.
Maybe we should keep the current behaviour as it is (!ipv6 by default) but print a warning when only ifconfig-ipv6 is provided?
I think for compatibility with existing configs, "redirect-gateway" with no extra arguments (or just the old ones, "def1" etc.) should be "ipv4", as it is today.
If there is no IPv4 address configured, redirect-gateway (ipv4) should log a notice ("NOTICE: --redirect-gateway without the 'ipv6' flag will handle IPv4 only. No IPv4 on tunnel, so not redirecting anything" or something like that).
Eventually we might want to change it to do
--redirect-gateway "with no IPv* flags" = IPv4+IPv6 --redirect-gateway ipv4 (def1|local|...) = "only IPv4" --redirect-gateway ipv6 = "only IPv6"
What we have today ("unless there is a !ipv4, it's always ipv4") is historic due to "the ipv6 code was expected to change as little of the existing behaviour as possible". We can be a bit more daring nowadays :)
We might also merge Arne's block-ipv6 patch some day :-) - and add the corresponding block-ipv4 functionality.
Quoted 3 lines
Quoted 3 lines
[ Selva ]
May be there are more such nuances -- this patch will need some thoroug testing before being ready for review.
Yes, definitely. There will be interesting surprises. I'm not sure we can catch everything before review/merging, though... but I'll try my best ;-)
Quoted 9 lines
Quoted 9 lines
Quoted 4 lines
Of course we'll also need to check if typical consumers of the management interface explode if you're not giving an IPv4 address to them...
Selva, Jonathan, how will our GUI and Tunnelblick handle that?
Windows GUI uses configured IPs only for logging and display so I don't think it will complain, let alone explode. If any changes are needed, likely to be minimal. We have to just keep the format of reporting configured IPs unchanged even if some elements may be blank.
When Antonio sends the v2, I'll do a windows build and see what happens.
gert
Signature · 6 lines
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany [email protected]...Re: [Openvpn-devel] [PATCH 1/5] tun: ensure interface can be configured with IPv6 only
In reply to Selva NairHi,
Quoted 3 lines · Selva Nair
How to work around that depends on what the tap driver expects in the v4 address. Ideally, we should patch the driver to work without a V4 address...
Samuli's build/test rig seems to be close to finished, so now is the time to break the tap driver for good ;-)
I'll look into that. Had my fingers in that code quite a lot recently anyway...
gert
Signature · 6 lines
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany [email protected]...[Openvpn-devel] [PATCH applied] Re: pool: restyle ipv4/ipv6 members to improve readability
In reply to Antonio QuartulliWhile not strictly necessary, it makes the code somewhat easier to follow ("this is only about IPv4, which does not interest me right now").
Stared-at-code, and tested (t_client + t_server) :-)
Your patch has been applied to the master branch (with some minor grammar fixes to the commit message).
commit 5d2cd1222e06291021cf5e793f585d5f1485ae9b
Author: Antonio Quartulli Date: Tue Jun 5 17:04:18 2018 +0800
pool: restyle ipv4/ipv6 members to improve readability
Signed-off-by: Antonio Quartulli <[email protected]...>
Acked-by: Gert Doering <[email protected]...>
Message-Id: <[email protected]...>
URL: https://www.mail-archive.com/[email protected]/msg16944.html
Signed-off-by: Gert Doering <[email protected]...>--
kind regards,
Gert Doering
Re: [Openvpn-devel] [PATCH 1/5] tun: ensure interface can be configured with IPv6 only
In reply to Gert DoeringHi,
Quoted 7 lines · Gert Doering
Hi,
Quoted 3 lines · Selva Nair
How to work around that depends on what the tap driver expects in the v4 address. Ideally, we should patch the driver to work without a V4 address...
Quoted 6 lines
Samuli's build/test rig seems to be close to finished, so now is the time to break the tap driver for good ;-)
I'll look into that. Had my fingers in that code quite a lot recently anyway...
Sounds good.
FWIW, I did a quick test --- looking into tap-windows sources it seems the address is used only for ARP so passing some random address to the ioctl looks ok (?).
Tried this by commenting out the check for did_ifconfig_setup on when windows tun mode is in use. In this case the local ip and netmask stays at 0, and gets passed to tap-windows. This allows one to run the exe on Windows (see the diff below to see what I did). Without that it just errors out saying --dev tun requires ifconfig, as expected.
There is a less than ideal log message which could be improved:
"Set TAP-Windows TUN subnet mode network/local/netmask = 0.0.0.0/0.0.0.0/0.0.0.0 [SUCCEEDED]"
However, even with !ipv4, redirect-gateway ipv6 appears to error out -- it fails with
"TEST ROUTES: 0/2 succeeded len=1 ret=0 a=0 u/d=up
Route: Waiting for TUN/TAP interface to come up..."
A couple of other random things I noticed
If a v4 address is not being set:
- some management messages could be bypassed as Gert had guessed -- eg., ASSIGN_IP which includes the v4 and v6 address.
The GUI takes the address from the final CONNECTED,SUCCESS message but other clients may parse this message.
- setting of mtu may get skipped in some systems at least
Here is the diff of what I did for the Windows build run:
src/openvpn/tun.c +0 -0
@@ -5824,9 +5824,9 @@ open_tun(const char *dev, const char *dev_type,
const char *dev_node, struct tun
if (tt->type == DEV_TYPE_TUN)
{
- if (!tt->did_ifconfig_setup)
+ if (!tt->did_ifconfig_setup && !tt->did_ifconfig_ipv6_setup)
{
- msg(M_FATAL, "ERROR: --dev tun also requires --ifconfig");
+ msg(M_WARN|M_INFO, "WARNING: neither ifconfig nor
ifconfig-ipv6 specified");
}
if (tt->topology == TOP_SUBNET)Selva
Re: [Openvpn-devel] [PATCH 1/5] tun: ensure interface can be configured with IPv6 only
Hi,
Quoted 3 lines · Selva Nair
FWIW, I did a quick test --- looking into tap-windows sources it seems the address is used only for ARP so passing some random address to the ioctl looks ok (?).
Not sure about that. For ARP spoofing, it should use the route-gateway address - the "ifconfig" address is likely to end up in the DHCP-server code. Haven't checked yet (busy repairing my own test right which deteriorated a bit...).
[..]
Quoted 4 lines
There is a less than ideal log message which could be improved:
"Set TAP-Windows TUN subnet mode network/local/netmask = 0.0.0.0/0.0.0.0/0.0.0.0 [SUCCEEDED]"
Indeed :-)
Quoted 5 lines
However, even with !ipv4, redirect-gateway ipv6 appears to error out -- it fails with
"TEST ROUTES: 0/2 succeeded len=1 ret=0 a=0 u/d=up
Route: Waiting for TUN/TAP interface to come up..."
Interesting. This is route.c, test_routes(), using test_route_helper() -> test_route(), which basically tries to find the adapter index where a given (route)->gateway is configured on. Since it cannot find anything, it assumes "tun interface is stuck in DHCP" and is unhappy.
This shouldn't actually try to do anything in the first place - it looks at "struct route_list *rl", which should not be populated if we have no v4 address to point the routes to. (Or maybe it should, but only for "non-tun/tap routes").
Quoted 8 lines
A couple of other random things I noticed
If a v4 address is not being set:
- some management messages could be bypassed as Gert had guessed -- eg.,
ASSIGN_IPwhich includes the v4 and v6 address.
The GUI takes the address from the final CONNECTED,SUCCESS message but other clients may parse this message.
What does our GUI display here? "0.0.0.0" or "<blank>"?
Quoted 18 lines
- setting of mtu may get skipped in some systems at least
Here is the diff of what I did for the Windows build run:
src/openvpn/tun.c +0
-0@@ -5824,9 +5824,9 @@ open_tun(const char *dev, const char *dev_type,const char
*dev_node, struct tunif (tt->type == DEV_TYPE_TUN) {src/openvpn/tun.c +2
-2-if (!tt->did_ifconfig_setup) +if (!tt->did_ifconfig_setup && !tt->did_ifconfig_ipv6_setup) { -msg (M_FATAL ,"ERROR: --dev tun also requires --ifconfig" ); + msg(M_WARN|M_INFO, "WARNING: neither ifconfig nor
Quoted 2 lines
ifconfig-ipv6 specified");
}Thanks. This is easy enough to integrate... Antonio, are you listening? ;-)
gert
Signature · 6 lines
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany [email protected]...Re: [Openvpn-devel] [PATCH 1/5] tun: ensure interface can be configured with IPv6 only
Hi,
Quoted 11 lines · Gert Doering
Hi,
Quoted 3 lines · Selva Nair
FWIW, I did a quick test --- looking into tap-windows sources it seems the address is used only for ARP so passing some random address to the ioctl looks ok (?).
Not sure about that. For ARP spoofing, it should use the route-gateway address - the "ifconfig" address is likely to end up in the DHCP-server code. Haven't checked yet (busy repairing my own test right which deteriorated a bit...).
I should have said TAP is given the address/network/netmask combination. In ProcessARP() it checks both the source and destination using those. This is for subnet topology, so it spoofs all addresses in the subnet I suppose.
For DHCP we have another ioctl which sets the dhcp_address (same as the v4 ip), dhcp server address and mask of ~0 but we wont be using it if v4 address is not set. There is also a sanity check on the netmask and network addresses which 0.0.0.0/0.0.0.0 will pass.
That said, I have only got it to connect and ping the server.
Quoted 20 lines
[..]
Quoted 4 lines
There is a less than ideal log message which could be improved:
"Set TAP-Windows TUN subnet mode network/local/netmask = 0.0.0.0/0.0.0.0/0.0.0.0 [SUCCEEDED]"
Indeed :-)
Quoted 5 lines
However, even with !ipv4, redirect-gateway ipv6 appears to error out -- it fails with
"TEST ROUTES: 0/2 succeeded len=1 ret=0 a=0 u/d=up
Route: Waiting for TUN/TAP interface to come up..."Interesting. This is
route.c,test_routes(), usingtest_route_helper()->test_route(), which basically tries to find the adapter index where a given (route)->gateway is configured on. Since it cannot find anything, it assumes "tun interface is stuck in DHCP" and is unhappy.
Quoted 4 lines
This shouldn't actually try to do anything in the first place - it looks at "struct
route_list*rl", which should not be populated if we have no v4 address to point the routes to. (Or maybe it should, but only for "non-tun/tap routes").
Yeah, we cant ignore v4 routes completely. So the logic for checking the tun is ready has to change?
Quoted 4 lines
Quoted 4 lines
A couple of other random things I noticed
Quoted 8 lines
Quoted 6 lines
If a v4 address is not being set:
- some management messages could be bypassed as Gert had guessed -- eg.,
ASSIGN_IPwhich includes the v4 and v6 address.
The GUI takes the address from the final CONNECTED,SUCCESS message but other clients may parse this message.What does our GUI display here? "0.0.0.0" or "<blank>"?
Just a "comma" but no segfaults :) We can fix that.
Selva
Re: [Openvpn-devel] [PATCH 1/5] tun: ensure interface can be configured with IPv6 only
In reply to Gert DoeringHi,
On 06/06/18 03:59, Gert Doering wrote:
[cut]
Quoted 9 lines
Quoted 9 lines
Here is the diff of what I did for the Windows build run:
src/openvpn/tun.c +0
-0@@ -5824,9 +5824,9 @@ open_tun(const char *dev, const char *dev_type,const char
*dev_node, struct tun
Quoted 12 lines
Quoted 9 lines
if (tt->type == DEV_TYPE_TUN) {src/openvpn/tun.c +2
-2-if (!tt->did_ifconfig_setup) +if (!tt->did_ifconfig_setup && !tt->did_ifconfig_ipv6_setup) { -msg (M_FATAL ,"ERROR: --dev tun also requires --ifconfig" ); + msg(M_WARN|M_INFO, "WARNING: neither ifconfig norifconfig-ipv6 specified"); }Thanks. This is easy enough to integrate... Antonio, are you listening? ;-)
Copy that!
I'll add this change in v2.
Cheers,
Signature · 1 line
Antonio Quartulli
Re: [Openvpn-devel] [PATCH v2 4/5] pool: allow to configure an IPv6-only ifconfig-pool
In reply to Gert DoeringHi,
Quoted 6 lines · Gert Doering
Hi,
Quoted 3 lines · Antonio Quartulli
Quoted 2 lines
Without having done much review here, just one initial caveat: did you test this with --ifconfig-pool-persist? What happens?
Quoted 8 lines
Quoted 3 lines
It should just be ignored.
At the moment pool-persist works only for IPv4 and there is no support for IPv6. This has not been changed by this patchset.Well, it does save the (calculated) v6 address into the save file...
So, what happens if you run a server with --ifconfig-pool-persist and no IPv4? Will it crash, not write anything to the file, write garbage?
It won't start. --ifconfig-pool-persist *requires* --ifconfig-pool that is a v4 option and is not set (normally set by --server).
However, even if we were to remove this option check, it should write the proper IPv6 into the file, but would not read them back as per the check below.
Quoted 12 lines
Quoted 11 lines
I added a check about it in
ifconfig_pool_read():521 /* IPv6 logic not implemented yet, therefore bail out if no IPv4
pool was
522 * configured
523 */
524 if (pool && !pool->ipv4.enabled)
525 {
526 return;
527 }
Quoted 3 lines
We should aim to make this work as well (but it could be patch 6 of the series :-)).
Definitely :) I just thought that "it is not there now, so it can't be a regression if we don't have it after this patchset". :)
However, it is definitely something we can add as extra feature at the end of the patchset. I'll see if I can squeeze that into v2.
Thanks for the comments!
Cheers,
Signature · 1 line
Antonio Quartulli
Re: [Openvpn-devel] [PATCH 1/5] tun: ensure interface can be configured with IPv6 only
In reply to Selva NairHi,
Quoted 16 lines · Selva Nair
Here is the diff of what I did for the Windows build run:
src/openvpn/tun.c +0
-0@@ -5824,9 +5824,9 @@ open_tun(const char *dev, const char *dev_type,const char
*dev_node, struct tunif (tt->type == DEV_TYPE_TUN) {src/openvpn/tun.c +2
-2-if (!tt->did_ifconfig_setup) +if (!tt->did_ifconfig_setup && !tt->did_ifconfig_ipv6_setup) { -msg (M_FATAL ,"ERROR: --dev tun also requires --ifconfig" ); + msg(M_WARN|M_INFO, "WARNING: neither ifconfig nor
Quoted 1 line
ifconfig-ipv6 specified");
Why converting this from M_FATAL to M_WARN|M_INFO?
Isn't just better to quit the client if we receive no IPv* settings?
Cheers,
Signature · 1 line
Antonio Quartulli
Re: [Openvpn-devel] [PATCH 1/5] tun: ensure interface can be configured with IPv6 only
Hi
Quoted 12 lines · Antonio Quartulli
Hi,
Quoted 9 lines · Selva Nair
Here is the diff of what I did for the Windows build run:
src/openvpn/tun.c +0
-0@@ -5824,9 +5824,9 @@ open_tun(const char *dev, const char *dev_type,const char
*dev_node, struct tun
Quoted 11 lines
Quoted 8 lines
if (tt->type == DEV_TYPE_TUN) {src/openvpn/tun.c +2
-2-if (!tt->did_ifconfig_setup) +if (!tt->did_ifconfig_setup && !tt->did_ifconfig_ipv6_setup) { -msg (M_FATAL ,"ERROR: --dev tun also requires --ifconfig" ); + msg(M_WARN|M_INFO, "WARNING: neither ifconfig norifconfig-ipv6 specified");
Why converting this FAtTAL to M_WARN|M_INFO?
Isn't just better to quit the client if we receive no IPv* settings?
That was just to show why Windows needs some special handling here, not a patch :)
Well, the reason why this used to be FATAL is because Windows is
special: tun mode requires --ifconfig. Whereas on other platforms its not FATAL to run without any ifconfig: say the user sets a static IP on the tun and somehow gets it to work.
At the same time, v4 address will work only if also present as an ifconfig line (even if a manual method of assigning the IP is in use). So some FATAL check is still required to catch that. But making this combination check FATAL is not the same thing. I'm not entirely sure of the best approach, but, anyway, its your patch :)
Selva
Re: [Openvpn-devel] [PATCH 1/5] tun: ensure interface can be configured with IPv6 only
In reply to Selva NairHi,
Quoted 11 lines · Selva Nair
Quoted 11 lines
Quoted 5 lines
However, even with !ipv4, redirect-gateway ipv6 appears to error out -- it fails with
"TEST ROUTES: 0/2 succeeded len=1 ret=0 a=0 u/d=up
Route: Waiting for TUN/TAP interface to come up..."Interesting. This is
route.c,test_routes(), usingtest_route_helper()->test_route(), which basically tries to find the adapter index where a given (route)->gateway is configured on. Since it cannot find anything, it assumes "tun interface is stuck in DHCP" and is unhappy.
Quoted 8 lines
Quoted 4 lines
This shouldn't actually try to do anything in the first place - it looks at "struct
route_list*rl", which should not be populated if we have no v4 address to point the routes to. (Or maybe it should, but only for "non-tun/tap routes").Yeah, we cant ignore v4 routes completely. So the logic for checking the tun is ready has to change?
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.
On Linux the route_list is empty when there is no v4 and "gateway-redirect !ipv4" is set.
Cheers,
Signature · 1 line
Antonio Quartulli
Re: [Openvpn-devel] [PATCH 1/5] tun: ensure interface can be configured with IPv6 only
Hi,
Quoted 19 lines · Antonio Quartulli
Hi,
Quoted 16 lines · Selva Nair
Quoted 15 lines
Quoted 5 lines
However, even with !ipv4, redirect-gateway ipv6 appears to error out -- it fails with
"TEST ROUTES: 0/2 succeeded len=1 ret=0 a=0 u/d=up
Route: Waiting for TUN/TAP interface to come up..."Interesting. This is
route.c,test_routes(), usingtest_route_helper()->test_route(), which basically tries to find the adapter index where a given (route)->gateway is configured on. Since it cannot find anything, it assumes "tun interface is stuck in DHCP" and is unhappy.This shouldn't actually try to do anything in the first place - it looks at "struct
route_list*rl", which should not be populated if we have no v4 address to point the routes to. (Or maybe it should, but only for "non-tun/tap routes").
Quoted 6 lines
Quoted 3 lines
Yeah, we cant ignore v4 routes completely. So the logic for checking the tun is ready has to change?
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 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
- 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)
- 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
- 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
- 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
- Test block-outside-dns (just to be sure as failure there is FATAL).
Quoted 3 lines
On Linux the
route_listis 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.
Selva
Re: [Openvpn-devel] [PATCH 1/5] tun: ensure interface can be configured with IPv6 only
Hi,
Quoted 22 lines · Selva Nair
Quoted 2 lines
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:
Quoted 3 lines
- 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).
Quoted 4 lines
- 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
Quoted 4 lines
- 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
Quoted 4 lines
- 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
Quoted 5 lines
- 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?
Quoted 5 lines
- 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.
Quoted 2 lines
- Test block-outside-dns (just to be sure as failure there is FATAL).
oh, thanks for this.
Quoted 7 lines
Quoted 3 lines
On Linux the
route_listis 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,
Signature · 1 line
Antonio Quartulli
Re: [Openvpn-devel] [PATCH 1/5] tun: ensure interface can be configured with IPv6 only
Hi,
Quoted 9 lines · Antonio Quartulli
Quoted 4 lines
- 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?
For whatever reason I never understood we support this... so while it doesn't make much sense here, breaking it on purpose doesn't make much sense either.
I'd go with "whatever is less intrusive to implement"
gert
Signature · 6 lines
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany [email protected]...Re: [Openvpn-devel] [PATCH 1/5] tun: ensure interface can be configured with IPv6 only
In reply to Antonio QuartulliHi
Quoted 6 lines · Antonio Quartulli
Hi,
Quoted 3 lines · Selva Nair
Quoted 2 lines
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.
..
Quoted 9 lines
Quoted 4 lines
- 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).
Yes, it boils down to the check I had written about + your suggestion to keep it FATAL, not WARN.
Quoted 1 line
..
Quoted 10 lines
Quoted 6 lines
- 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.
I think such routes should be allowed as there is no reason to fail them. And should work once we learn to skip the "waiting for tun to come up with a v4 ip"
when there are no v4 routes to set on the tun/tap adapter.
Quoted 11 lines
Gert? what do you think?
Quoted 5 lines
- 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.
Yes, this should be dependent on what is being redirected (v4 or v6) and how the server is being reached (by v4 or v6). But to keep the logic simple adding a bypass route when any kind of redirect-gateway is in effect keeps the logic simple. I think that's the current state and I don't see a need to change it.
Selva
Re: [Openvpn-devel] [PATCH 1/5] tun: ensure interface can be configured with IPv6 only
In reply to Selva NairHi
Quoted 6 lines · Selva Nair
Hi,
Quoted 3 lines · Antonio Quartulli
Hi,
On 06/06/18 04:30, Selva Nair wrote:
..
Quoted 5 lines
Quoted 3 lines
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.
The logs are here:
https://gist.github.com/selvanair/fc8c74ce83bfa0c93aca8bec97dd091b
(sanitized). --redirect-gateway !ipv4 is in client config
(not pushed), no other routes in config or PUSH. ifconfig is rejected using pull filter as seen in the logs.
Actually despite the "errors" the connection has succeeded, appearances to the contrary.
It doesn't say anything more than what we already discussed, but may still help.
Selva
Re: [Openvpn-devel] [PATCH 1/5] tun: ensure interface can be configured with IPv6 only
Hi Selva,
I have tried to account most of your comments, but something might still be off. Building openvpn for Windows might need some time here as I don't have the entire environment ready yet.
Would you mind giving my latest branch a try and let me know how it goes with regards to your previous observations?
Find it on gitlab: https://gitlab.com/ordex986/openvpn/tree/ipv6-only
(git: [email protected]...:ordex986/openvpn.git)
Thanks!
Cheers,
Quoted 31 lines · Selva Nair
Hi
Quoted 6 lines · Selva Nair
Hi,
Quoted 3 lines · Antonio Quartulli
Hi,
On 06/06/18 04:30, Selva Nair wrote:
..
Quoted 5 lines
Quoted 3 lines
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.
The logs are here:
https://gist.github.com/selvanair/fc8c74ce83bfa0c93aca8bec97dd091b
(sanitized). --redirect-gateway !ipv4 is in client config
(not pushed), no other routes in config or PUSH. ifconfig is rejected using pull filter as seen in the logs.Actually despite the "errors" the connection has succeeded, appearances to the contrary.
It doesn't say anything more than what we already discussed, but may still help.
Selva
Signature · 1 line
Antonio Quartulli
Re: [Openvpn-devel] [PATCH 1/5] tun: ensure interface can be configured with IPv6 only
Hi,
Quoted 9 lines · Antonio Quartulli
Hi Selva,
I have tried to account most of your comments, but something might still be off. Building openvpn for Windows might need some time here as I don't have the entire environment ready yet.
Would you mind giving my latest branch a try and let me know how it goes with regards to your previous observations?
Did some quick tests and this seems to work quite well (but see the note at the bottom):
- v4 routes via tun just fail with a warning which is good (our route errors not being FATAL pays off here)
- v4 routes via net_gateway just works : no idea why we support this, but good to see this patch doesn't break it
- redirect-gateway causes warnings as v4 routes fail:
If its not too hard could we check !tt->did_ifconfig_setup before
attempting v4 redirect? Saying this because "--redirect-gateway with no options automatically implies ipv4" is just a hangover from the past that we are stuck with. For other routes it may be harder to detect whether its via the tun or not so just letting them error out is fine. And those warnings provide useful feedback to the user.
A minor thing:
- The warning
"WARNING: OpenVPN was configured to add an IPv4 route. However, no IPv4 has been configured for this interface, therefore the route installation may fail or may not work as expected."
is printed without the M_WARN flag --- so syslog won't see it as a warning nor does the GUI. M_INFO|M_WARN will make it print at verb > 0 with the warning tag. If that sounds like a strange combination, invent a warning level like D_GENERIC_WARNING = LOGLEV(1,0,M_WARN). We don't have one.
Note: All that said, I can't seem to connect to the server via ipv6 when there is no v4 address. tracert fails before the first hop. v6 does work when ifconfig is not filtered out.
One difference from my earlier test using your previous version with the minor change to allow tap initialize is that the tap adapter now gets the link-local v4 address (169.254.x.y) as opposed to staying at 0.0.0.0 earlier. But this may be just dependent on the order in which I tried various combinations and may not matter.
So, is the tap-driver mis-behaving when the v4 ip/net/mask is set as 0/0/0 ? Will test this further when I get time later today.
Thanks for working on this,
Selva
Re: [Openvpn-devel] [PATCH 1/5] tun: ensure interface can be configured with IPv6 only
Hi Selva,
thanks for testing this branch again!
See below:
Quoted 18 lines · Selva Nair
Hi,
Quoted 9 lines · Antonio Quartulli
Hi Selva,
I have tried to account most of your comments, but something might still be off. Building openvpn for Windows might need some time here as I don't have the entire environment ready yet.
Would you mind giving my latest branch a try and let me know how it goes with regards to your previous observations?
Did some quick tests and this seems to work quite well (but see the note at the bottom):
Quoted 12 lines
- v4 routes via tun just fail with a warning which is good (our route errors not being FATAL pays off here)
- v4 routes vianet_gatewayjust works : no idea why we support this, but good to see this patch doesn't break it
- redirect-gateway causes warnings as v4 routes fail:
If its not too hard could we check !tt->did_ifconfig_setup before
attempting v4 redirect? Saying this because "--redirect-gateway with no options automatically implies ipv4" is just a hangover from the past that we are stuck with. For other routes it may be harder to detect whether its via the tun or not so just letting them error out is fine. And those warnings provide useful feedback to the user.
Don't you think it's still meaningful to print the warning? somebody is asking for a redirect that does not make sense because there is no v4 configured and the config should be adjusted. No?
Quoted 12 lines
A minor thing:
- The warning
"WARNING: OpenVPN was configured to add an IPv4 route. However, no IPv4 has been configured for this interface, therefore the route installation may fail or may not work as expected."
is printed without theM_WARNflag --- so syslog won't see it as a warning nor does the GUI. M_INFO|M_WARN will make it print at verb > 0 with the warning tag. If that sounds like a strange combination, invent a warning level likeD_GENERIC_WARNING=LOGLEV(1,0,M_WARN). We don't have one.
you are the master of the log levels, therefore I'll just follow your suggestion, unless somebody else objects.
Quoted 10 lines
Note: All that said, I can't seem to connect to the server via ipv6 when there is no v4 address. tracert fails before the first hop. v6 does work when ifconfig is not filtered out.
One difference from my earlier test using your previous version with the minor change to allow tap initialize is that the tap adapter now gets the link-local v4 address (169.254.x.y) as opposed to staying at 0.0.0.0 earlier. But this may be just dependent on the order in which I tried various combinations and may not matter.
This happens because I have factored out the set 0/0/0 in open_tun(). I have added a "if (tt->did_ifconfig_setup)" that prevents the entire setup if no ipv4 is present. I wanted to see if this could make any difference. Should be at tun.c:5721. Feel free to remove that if and see if it makes any difference again.
Quoted 4 lines
So, is the tap-driver mis-behaving when the v4 ip/net/mask is set as 0/0/0 ? Will test this further when I get time later today.
Thanks for working on this,
Thank you! I am still struggling to get my cross builder going, therefore having somebody else doing sane windows tests is a big value for this work.
Cheers,
Signature · 1 line
Antonio Quartulli
Re: [Openvpn-devel] [PATCH 1/5] tun: ensure interface can be configured with IPv6 only
Hi,
Quoted 12 lines
Quoted 11 lines
Note: All that said, I can't seem to connect to the server via ipv6 when there is no v4 address. tracert fails before the first hop. v6 does work when ifconfig is not filtered out.
One difference from my earlier test using your previous version with the minor change to allow tap initialize is that the tap adapter now gets the link-local v4 address (169.254.x.y) as opposed to staying at 0.0.0.0 earlier. But this may be just dependent on the order in which I tried various combinations and may not matter.
Quoted 5 lines
This happens because I have factored out the set 0/0/0 in
open_tun(). I have added a "if (tt->did_ifconfig_setup)" that prevents the entire setup if no ipv4 is present. I wanted to see if this could make any difference. Should be at tun.c:5721. Feel free to remove that if and see if it makes any difference again.
Oh, no, that wont work. Some configuration steps for the tap will not happen in this case -- one of the ioctls (TUN or POINT_TO_POINT) needs to happen.
See the two-line diff I had sent earlier.
So that explains why the tunnel doesn't work when no v4 address is set.
While we do need to do further tests to ensure setting tap for TUN mode using 0/0/0 doesn't break anything, skipping it is not an option.
Selva
Re: [Openvpn-devel] [PATCH 1/5] tun: ensure interface can be configured with IPv6 only
In reply to Selva NairHi,
Quoted 3 lines · Selva Nair
Note: All that said, I can't seem to connect to the server via ipv6 when there is no v4 address. tracert fails before the first hop. v6 does work when ifconfig is not filtered out.
This "should not happen".
v6 should work no matter what we break in v4 land.
But this is windows, and "should work" land...
Thanks for testing & reporting back ;-)
gert
Signature · 6 lines
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany [email protected]...Re: [Openvpn-devel] [PATCH 1/5] tun: ensure interface can be configured with IPv6 only
In reply to Antonio QuartulliHi,
Failed to respond to some other points in the last reply:
Quoted 17 lines
Quoted 4 lines
Did some quick tests and this seems to work quite well (but see the note at the bottom):
Quoted 12 lines
- v4 routes via tun just fail with a warning which is good (our route errors not being FATAL pays off here)
- v4 routes vianet_gatewayjust works : no idea why we support this, but good to see this patch doesn't break it
- redirect-gateway causes warnings as v4 routes fail:
If its not too hard could we check !tt->did_ifconfig_setup before
attempting v4 redirect? Saying this because "--redirect-gateway with no options automatically implies ipv4" is just a hangover from the past that we are stuck with. For other routes it may be harder to detect whether its via the tun or not so just letting them error out is fine. And those warnings provide useful feedback to the user.
Quoted 3 lines
Don't you think it's still meaningful to print the warning? somebody is asking for a redirect that does not make sense because there is no v4 configured and the config should be adjusted. No?
When you put it that way, yes. But interpreting redirect-gateway with no arguments to mean redirect ipv4 is something we have to live with just because of backward compatibility. In that sense its different from an explicit ipv4 route in the config. Being a bit more helpful and interpret it as !ipv4 when no v4 address is present looks like a nice touch? So I would say, a warning saying redirect v4 is skipped is useful but letting those routes error out is not.
But unlike I may sound, I do not have a strong feeling about this -- works either way for me.
Quoted 14 lines
Quoted 13 lines
A minor thing:
- The warning
"WARNING: OpenVPN was configured to add an IPv4 route. However, no IPv4 has been configured for this interface, therefore the route installation may fail or may not work as expected."
is printed without theM_WARNflag --- so syslog won't see it as a warning nor does the GUI. M_INFO|M_WARN will make it print at verb > 0 with the warning tag. If that sounds like a strange combination, invent a warning level likeD_GENERIC_WARNING=LOGLEV(1,0,M_WARN). We don't have one.
Quoted 2 lines
you are the master of the log levels, therefore I'll just follow your suggestion, unless somebody else objects.
Personally I do not like M_WARN|M_INFO but that's the best I can think of to get the warning tag and print only if verb > 0.
Thanks,
Selva
Re: [Openvpn-devel] [PATCH 1/5] tun: ensure interface can be configured with IPv6 only
In reply to Gert DoeringHi,
Quoted 7 lines · Gert Doering
Hi,
Quoted 3 lines · Selva Nair
Note: All that said, I can't seem to connect to the server via ipv6 when there is no v4 address. tracert fails before the first hop. v6 does work when ifconfig is not filtered out.
Quoted 5 lines
This "should not happen".
v6 should work no matter what we break in v4 land.
But this is windows, and "should work" land...
It happens because the patch skips CONFIG_TUN ioctl when v4 address is not set. I think that skips some initialization steps. I had expected the patch to setup the driver using 0/0/0 as the addres/mask/net as we discussed earlier. Fixing that should make the tap driver talk back to us and v6 work.
Selva
Re: [Openvpn-devel] [PATCH 1/5] tun: ensure interface can be configured with IPv6 only
Quoted 14 lines · Selva Nair
Hi,
Quoted 11 lines · Gert Doering
Hi,
Quoted 3 lines · Selva Nair
Note: All that said, I can't seem to connect to the server via ipv6 when there is no v4 address. tracert fails before the first hop. v6 does work when ifconfig is not filtered out.
This "should not happen".
v6 should work no matter what we break in v4 land.
Quoted 7 lines
Quoted 1 line
But this is windows, and "should work" land...
It happens because the patch skips
CONFIG_TUNioctl when v4 address is not set. I think that skips some initialization steps. I had expected the patch to setup the driver using 0/0/0 as the addres/mask/net as we discussed earlier. Fixing that should make the tap driver talk back to us and v6 work.
I have fixed that, but I have not been able to compile/test yet. Feel free to give it a shot.
Cheers,
Quoted 3 lines
Selva
Signature · 1 line
Antonio Quartulli
Re: [Openvpn-devel] [PATCH 1/5] tun: ensure interface can be configured with IPv6 only
In reply to Selva NairHi,
Quoted 5 lines · Selva Nair
It happens because the patch skips
CONFIG_TUNioctl when v4 address is not set. I think that skips some initialization steps. I had expected the patch to setup the driver using 0/0/0 as the addres/mask/net as we discussed earlier. Fixing that should make the tap driver talk back to us and v6 work.
Oh, indeed. That will be needed.
(I "assumed" - which I shouldn't do - that this is already happening)
gert
Signature · 6 lines
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany [email protected]...Re: [Openvpn-devel] [PATCH 1/5] tun: ensure interface can be configured with IPv6 only
In reply to Antonio QuartulliHi,
Quoted 18 lines · Antonio Quartulli
Quoted 3 lines · Selva Nair
Hi,
On Thu, Jun 7, 2018 at 12:57 PM, Gert Doering <[email protected]...>
Quoted 13 lines · wrote:
Quoted 12 lines
Hi,
Quoted 3 lines · Selva Nair
Note: All that said, I can't seem to connect to the server via ipv6 when there is no v4 address. tracert fails before the first hop. v6 does work when ifconfig is not filtered out.
This "should not happen".
v6 should work no matter what we break in v4 land.
But this is windows, and "should work" land...
Quoted 9 lines
Quoted 5 lines
It happens because the patch skips
CONFIG_TUNioctl when v4 address is not set. I think that skips some initialization steps. I had expected the patch to setup the driver using 0/0/0 as the addres/mask/net as we discussed earlier. Fixing that should make the tap driver talk back to us and v6 work.I have fixed that, but I have not been able to compile/test yet. Feel free to give it a shot.
It works now though not thoroghly tested.
I just noticed this change:
src/openvpn/tun.c +0 -0
@@ -5718,7 +5718,10 @@ open_tun(const char *dev, const char *dev_type,
const char *dev_node, struct tun
msg(M_FATAL, "ERROR: --dev tun also requires --ifconfig");
}- if (tt->topology == TOP_SUBNET)
+ /* send 0/0/0 to the TAP driver even if we have no IPv4 configured
to
+ * ensure it is somehow initialized.
+ */
+ if (!tt->did_ifconfig_setup || tt->topology == TOP_SUBNET)
{This should work, but why change the logic? I would leave the conditionals as in the original:
if (tt->topology == TOP_SUBNET) etc..
i.e call the CONFIG_TUN ioctl if topology is subnet else call CONFIG_POINT_TO_POINT (eg., net30) irrsepective of v4 address is available or not. This separate handling of net30 and subnet in the orginal is due to historic reasons[*]. That is already messy and confusing so why add to it with another cryptic condition?
Just saying... feel free to ignore.
Selva
[*] Topology subnet uses ip, nework and netmask, while net30 passes in the second IP of the /30 in network as "netmask". The two ioctls interprets their parameters differently such that in the end only valid ARP packets get a response from the driver !
Re: [Openvpn-devel] [PATCH 1/5] tun: ensure interface can be configured with IPv6 only
Hi,
Quoted 26 lines · Selva Nair
It works now though not thoroghly tested.
I just noticed this change:
src/openvpn/tun.c +0
-0@@ -5718,7 +5718,10 @@ open_tun(const char *dev, const char *dev_type,const char
*dev_node, struct tunmsg(M_FATAL, "ERROR: --dev tun also requires --ifconfig"); }src/openvpn/tun.c +1
-1-if (tt->topology ==TOP_SUBNET ) +/* send 0/0/0 to the TAP driver even if we have no IPv4 configured to
src/openvpn/tun.c +3
-0+* ensure it is somehow initialized. +*/ +if (!tt->did_ifconfig_setup || tt->topology ==TOP_SUBNET ) {This should work, but why change the logic? I would leave the conditionals as in the original:
if (
tt->topology==TOP_SUBNET) etc..
Quoted 7 lines
i.e call the
CONFIG_TUNioctl if topology is subnet else callCONFIG_POINT_TO_POINT(eg., net30) irrsepective of v4 address is available or not. This separate handling of net30 and subnet in the orginal is due to historic reasons[*]. That is already messy and confusing so why add to it with another cryptic condition?Just saying... feel free to ignore.
Well, topology is relevant only for IPv4, therefore when no --ifconfig is passed topology is basically ignored.
For this reason I thought it would make sense to make the codeflow in this function explicit instead of relying of the topology value we actually have. Does it make sense?
Quoted 7 lines
Selva
[*] Topology subnet uses ip, nework and netmask, while net30 passes in the second IP of the /30 in network as "netmask". The two ioctls interprets their parameters differently such that in the end only valid ARP packets get a response from the driver !
Is ARP still to be considered when no IPv4 is configured?
Signature · 1 line
Antonio Quartulli
Re: [Openvpn-devel] [PATCH 1/5] tun: ensure interface can be configured with IPv6 only
Hi,
Quoted 8 lines
Quoted 1 line
[*] Topology subnet uses ip, nework and netmask, while net30 passes in
the
Quoted 3 lines
second IP of the /30 in network as "netmask". The two ioctls interprets their parameters differently such that in the end only valid ARP packets get a response from the driver !
Is ARP still to be considered when no IPv4 is configured?
No, but we only have one ioctl (well two with slightly different syntax) to setup the tap driver which uses the v4 info we pass in for setting up ARP data as well as a few other things. So unless we patch the tap driver we are stuck with some convoluted code. I was only suggesting not to touch it unless we are improving the code.
I'm still hoping that one day we may be able to treat Windows like other platforms. And then did_ifconfig_setup = false would only mean ifconfig is not in the config (or pushed) which is not the same as v4 is disabled.
Anyway, I'll leave it at that.
Selva
Am Dienstag, 5. Juni 2018, 14:05:10 CET schrieb tincanteksup:
Quoted 3 lines
Hi,
I have applied these 5 patches to master...
me too, a little bit late my confirmation:
/usr/local/sbin/openvpn --config server-neu.ovpn
Sat Jan 26 00:05:09 2019 OpenVPN 2.5_git [git:HEAD/a59fd1475089eda4+] armv7l- unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Jan 25 2019
Sat Jan 26 00:05:09 2019 library versions: OpenSSL 1.1.0h-fips 27 Mar 2018, LZO 2.10
Sat Jan 26 00:05:09 2019 Diffie-Hellman initialized with 2048 bit key Sat Jan 26 00:05:09 2019 TUN/TAP device tun0 opened
Sat Jan 26 00:05:09 2019 TUN/TAP TX queue length set to 100
Sat Jan 26 00:05:09 2019 /sbin/ip link set dev tun0 up mtu 1500 Sat Jan 26 00:05:09 2019 /sbin/ip -6 addr add 2001:a61:5e8:5b01::1:2/112 dev tun0
Sat Jan 26 00:05:09 2019 Socket Buffers: R=[163840->163840] S=[163840->163840] Sat Jan 26 00:05:09 2019 setsockopt(IPV6_V6ONLY=0)
Sat Jan 26 00:05:09 2019 UDPv6 link local (bound): [AF_INET6][undef]:1194 Sat Jan 26 00:05:09 2019 UDPv6 link remote: [AF_UNSPEC]
Sat Jan 26 00:05:09 2019 MULTI: multi_init called, r=256 v=256 Sat Jan 26 00:05:09 2019 IFCONFIG POOL IPv6: (IPv4) size=0, size_ipv6=65536, netbits=112, base_ipv6=2001:a61:5e8:5b01::1:1001
Sat Jan 26 00:05:09 2019 Initialization Sequence Completed
Sat Jan 26 00:05:36 2019 2a01:598:89f0:85e7:f19b:58b8:9005:20f7 TLS: Initial packet from [AF_INET6]2a01:598:89f0:85e7:f19b:58b8:9005:20f7:39005, sid=1055982b 433815b8
Sat Jan 26 00:05:36 2019 2a01:598:89f0:85e7:f19b:58b8:9005:20f7 VERIFY OK:
depth=1, C=KG, ST=NA, L=BISHKEK, O=OpenVPN-TEST, [email protected]...
Sat Jan 26 00:05:36 2019 2a01:598:89f0:85e7:f19b:58b8:9005:20f7 VERIFY OK:
depth=0, C=KG, ST=NA, O=OpenVPN-TEST, CN=Test-Client, [email protected]...
Sat Jan 26 00:05:36 2019 2a01:598:89f0:85e7:f19b:58b8:9005:20f7 peer info:
IV_GUI_VER=OC30Android
Sat Jan 26 00:05:36 2019 2a01:598:89f0:85e7:f19b:58b8:9005:20f7 peer info:
IV_VER=3.2
Sat Jan 26 00:05:36 2019 2a01:598:89f0:85e7:f19b:58b8:9005:20f7 peer info:
IV_PLAT=android
Sat Jan 26 00:05:36 2019 2a01:598:89f0:85e7:f19b:58b8:9005:20f7 peer info:
IV_NCP=2
Sat Jan 26 00:05:36 2019 2a01:598:89f0:85e7:f19b:58b8:9005:20f7 peer info:
IV_TCPNL=1
Sat Jan 26 00:05:36 2019 2a01:598:89f0:85e7:f19b:58b8:9005:20f7 peer info:
IV_PROTO=2
Sat Jan 26 00:05:36 2019 2a01:598:89f0:85e7:f19b:58b8:9005:20f7 peer info:
IV_AUTO_SESS=1
Sat Jan 26 00:05:36 2019 2a01:598:89f0:85e7:f19b:58b8:9005:20f7 peer info:
IV_BS64DL=1
Sat Jan 26 00:05:36 2019 2a01:598:89f0:85e7:f19b:58b8:9005:20f7 Control
Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA Sat Jan 26 00:05:36 2019 2a01:598:89f0:85e7:f19b:58b8:9005:20f7 [Test-Client] Peer Connection Initiated with [AF_INET6]2a01:598:89f0:85e7:f19b:
58b8:9005:20f7:39005
Sat Jan 26 00:05:36 2019 Test-Client/2a01:598:89f0:85e7:f19b:58b8:9005:20f7MULTI_sva: pool returned IPv4=(Not enabled), IPv6=2001:a61:5e8:5b01::1:1001 Sat Jan 26 00:05:36 2019 Test-Client/2a01:598:89f0:85e7:f19b:58b8:9005:20f7
MULTI: no --ifconfig-pool netmask parameter is available to push to Test- Client/2a01:598:89f0:85e7:f19b:58b8:9005:20f7
Sat Jan 26 00:05:36 2019 Test-Client/2a01:598:89f0:85e7:f19b:58b8:9005:20f7
MULTI: no dynamic or static remote --ifconfig address is available for Test- Client/2a01:598:89f0:85e7:f19b:58b8:9005:20f7
Sat Jan 26 00:05:36 2019 Test-Client/2a01:598:89f0:85e7:f19b:58b8:9005:20f7
MULTI: Learn: 2001:a61:5e8:5b01::1:1001 -> Test-Client/ 2a01:598:89f0:85e7:f19b:58b8:9005:20f7
Sat Jan 26 00:05:36 2019 Test-Client/2a01:598:89f0:85e7:f19b:58b8:9005:20f7
MULTI: primary virtual IPv6 for Test-Client/2a01:598:89f0:85e7:f19b:
58b8:9005:20f7: 2001:a61:5e8:5b01::1:1001
Sat Jan 26 00:05:36 2019 Test-Client/2a01:598:89f0:85e7:f19b:58b8:9005:20f7
PUSH: Received control message: 'PUSH_REQUEST'
Sat Jan 26 00:05:36 2019 Test-Client/2a01:598:89f0:85e7:f19b:58b8:9005:20f7 SENT CONTROL [Test-Client]: 'PUSH_REPLY,route-ipv6 fd00::/64,route-ipv6 2001:a61:5e8:5b01:0:0:0:0/64,dhcp-option DNS fd00::464e:6dff:fe72:8a08,tun- ipv6,ping 10,ping-restart 120,ifconfig-ipv6 2001:a61:5e8:5b01::1:1001/112 2001:a61:5e8:5b01::1:2,peer-id 0,cipher AES-256-GCM' (status=1) Sat Jan 26 00:05:36 2019 Test-Client/2a01:598:89f0:85e7:f19b:58b8:9005:20f7 Data Channel: using negotiated cipher 'AES-256-GCM'
Sat Jan 26 00:05:36 2019 Test-Client/2a01:598:89f0:85e7:f19b:58b8:9005:20f7 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key Sat Jan 26 00:05:36 2019 Test-Client/2a01:598:89f0:85e7:f19b:58b8:9005:20f7 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key Sat Jan 26 00:07:58 2019 Test-Client/2a01:598:89f0:85e7:f19b:58b8:9005:20f7 SIGTERM[soft,remote-exit] received, client-instance exiting
config at raspberry pi
proto udp6
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
server-ipv6 2001:a61:5e8:5b01:0:0:1:1/112
push "route-ipv6 fd00::/64"
push "route-ipv6 2001:a61:5e8:5b01:0:0:0:0/64"
push "dhcp-option DNS fd00::464e:6dff:fe72:8a08"
keepalive 10 120
verb 3
Client was Openvpn connect 3.05 for android.
Thomas
Hi,
Quoted 7 lines · Thomas Schäfer
Am Dienstag, 5. Juni 2018, 14:05:10 CET schrieb tincanteksup:
Quoted 3 lines
Hi,
I have applied these 5 patches to master...
me too, a little bit late my confirmation:
Thanks for testing the patches! We still need to setup some more automated testing for the server side to make sure we don't introduce regressions and similar...hopefully we'll put this together soon :-)
Cheers,
Signature · 1 line
Antonio Quartulli