Opened 7 years ago
Closed 7 years ago
#761 closed Bug / Defect (fixed)
cipher change should not lead to tun/tap reopen
| Reported by: | Gert Döring | Owned by: | Steffan Karger |
|---|---|---|---|
| Priority: | major | Milestone: | release 2.4 |
| Component: | Generic / unclassified | Version: | OpenVPN git master branch (Community Ed) |
| Severity: | Not set (select this one, unless your'e a OpenVPN developer) | Keywords: | |
| Cc: |
Description
mattock upgraded the community server from 2.3 to 2.4, leading to changes in PUSH_REPLY (cipher, peer-id)
OpenVPN 2.4_alpha2 [git:master/51d4d1543a64158c+] x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [IPv6] built on Nov 1 2016 ... Mon Nov 7 11:23:59 2016 PUSH: Received control message: 'PUSH_REPLY,route 10.177.36.0 255.255.255.0,topology net30,ping 10,ping-restart 120,ifconfig 10.177.36.10 10.177.36.9,peer-id 3,cipher AES-256-GCM' Mon Nov 7 11:23:59 2016 OPTIONS IMPORT: timers and/or timeouts modified Mon Nov 7 11:23:59 2016 OPTIONS IMPORT: --ifconfig/up options modified Mon Nov 7 11:23:59 2016 OPTIONS IMPORT: route options modified Mon Nov 7 11:23:59 2016 OPTIONS IMPORT: peer-id set Mon Nov 7 11:23:59 2016 OPTIONS IMPORT: adjusting link_mtu to 1625 Mon Nov 7 11:23:59 2016 OPTIONS IMPORT: data channel crypto options modified Mon Nov 7 11:23:59 2016 Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key Mon Nov 7 11:23:59 2016 Data Channel Decrypt: Cipher 'AES-256-GCM' initialized with 256 bit key Mon Nov 7 11:23:59 2016 Preserving previous TUN/TAP instance: tun0 Mon Nov 7 11:23:59 2016 NOTE: Pulled options changed on restart, will need to close and reopen TUN/TAP device.
I'm not 100% sure that it was caused by the --cipher change, it might have given me a new IP address in ifconfig, so this is more a reminder "we need to check this"
Change History (2)
comment:1 Changed 7 years ago by
comment:2 Changed 7 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
This has been tackled by commit ec4dff3bbdcc9fedf7844701dc5aa2679d503667.
Note: See
TracTickets for help on using
tickets.
There are more subtleties to think about wrt NCP + reopening tun.
For example: a different cipher might cause a different tun-mtu if link-mtu is set in the config (because different cipher overhead). Such a setup would 'need' a per-client tun-mtu, which I'm not sure we want, or would be possible to achieve at all...
So, it might not make sense to support ncp + link-mtu at all.
I see this ticket as the chance to think about which combinations we should allow and which not.