Opened 4 years ago

Closed 3 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 4 years ago by Steffan Karger

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.

comment:2 Changed 3 years ago by Steffan Karger

Resolution: fixed
Status: newclosed

This has been tackled by commit ec4dff3bbdcc9fedf7844701dc5aa2679d503667.

Note: See TracTickets for help on using tickets.