Page MenuHomeVyOS Platform

OpenVPN site-to-site creates wrong peer address
Closed, ResolvedPublicBUG

Description

Site to site OpenVPN creates a wrong peer address (it used netmask instead of peer ip address)

set interfaces openvpn vtun30365 local-address 10.10.36.18 subnet-mask '255.255.255.252'
set interfaces openvpn vtun30365 local-host '100.64.0.2'
set interfaces openvpn vtun30365 local-port '30365'
set interfaces openvpn vtun30365 mode 'site-to-site'
set interfaces openvpn vtun30365 remote-address '10.10.36.17'
set interfaces openvpn vtun30365 remote-host '100.64.0.1'
set interfaces openvpn vtun30365 remote-port '30365'
set interfaces openvpn vtun30365 shared-secret-key-file '/config/auth/foo.key'

Commit

vyos@r4-roll# commit
[ interfaces openvpn vtun30365 ]
{'auth_user_pass_file': '/run/openvpn/vtun30365.pw',
 'daemon_group': 'openvpn',
 'daemon_user': 'openvpn',
 'device_type': 'tun',
 'ifname': 'vtun30365',
 'ip': {'ospf': {'dead_interval': '40',
                 'hello_interval': '10',
                 'priority': '1',
                 'retransmit_interval': '5',
                 'transmit_delay': '1'}},
 'keep_alive': {'failure_count': '60', 'interval': '10'},
 'local_address': {'10.10.36.18': {'subnet_mask': '255.255.255.252'}},
 'local_host': '100.64.0.2',
 'local_port': '30365',
 'mode': 'site-to-site',
 'protocol': 'udp',
 'remote_address': ['10.10.36.17'],
 'remote_host': ['100.64.0.1'],
 'remote_port': '30365',
 'server': {'topology': 'net30'},
 'shared_secret_key_file': '/config/auth/foo.key'}

Additional logs.

Nov 16 18:36:22 r4-roll sudo[29040]:     root : TTY=unknown ; PWD=/run/openvpn ; USER=root ; COMMAND=/sbin/ip link set dev vtun30365 up mtu 1500
Nov 16 18:36:22 r4-roll sudo[29040]: pam_unix(sudo:session): session opened for user root by (uid=0)
Nov 16 18:36:22 r4-roll netplugd[733]: vtun30365: ignoring event
Nov 16 18:36:22 r4-roll charon[10052]: 12[KNL] interface vtun30365 activated
Nov 16 18:36:22 r4-roll sudo[29040]: pam_unix(sudo:session): session closed for user root
Nov 16 18:36:22 r4-roll openvpn-vtun30365[29034]: /usr/libexec/vyos/system/unpriv-ip addr add dev vtun30365 local 10.10.36.18 peer 255.255.255.252
Nov 16 18:36:22 r4-roll sudo[29046]:     root : TTY=unknown ; PWD=/run/openvpn ; USER=root ; COMMAND=/sbin/ip addr add dev vtun30365 local 10.10.36.18 peer 255.255.255.252

Nov 16 18:36:32 r4-roll openvpn-vtun30365[29034]: WARNING: 'ifconfig' is used inconsistently, local='ifconfig 10.10.36.18 255.255.255.252', remote='ifconfig 10.10.36.18 10.10.36.17'
[edit]

What there wrong

/sbin/ip addr add dev vtun30365 local 10.10.36.18 peer 255.255.255.252
instead of 10.10.36.17

It seems "netmask" should be used only when we use "device-type tap" and in the proper place.

What I expect

vtun30365: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 10.10.36.18  netmask 255.255.255.255  destination 10.10.36.17

What I get

vtun30365: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 10.10.36.18  netmask 255.255.255.255  destination 255.255.255.252

vyos@r4-roll# sudo ip route get 255.255.255.252
255.255.255.252 dev vtun30365 src 10.10.36.18 uid 0 
    cache 
[edit]
vyos@r4-roll#

Details

Difficulty level
Normal (likely a few hours)
Version
VyOS 1.3-rolling-202011150217
Why the issue appeared?
Implementation mistake
Is it a breaking change?
Stricter validation
Issue type
Bug (incorrect behavior)

Event Timeline

vyos@r4-roll# sudo cat /run/openvpn/vtun30365.conf 
### Autogenerated by interfaces-openvpn.py ###
#
# See https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage
# for individual keyword definition
#
# 
#

verb 3
user openvpn
group openvpn
dev-type tun
dev vtun30365
persist-key
iproute /usr/libexec/vyos/system/unpriv-ip
proto udp
local 100.64.0.2
lport 30365
rport 30365
remote 100.64.0.1
secret /config/auth/foo.key

#
# OpenVPN site-2-site mode
#
ping 10
ping-restart 60

ifconfig 10.10.36.18 255.255.255.252


# Encryption options



# DEPRECATED This option will be removed in OpenVPN 2.5
# Until OpenVPN v2.3 the format of the X.509 Subject fields was formatted like this:
# /C=US/L=Somewhere/CN=John Doe/[email protected] In addition the old
# behaviour was to remap any character other than alphanumeric, underscore ('_'),
# dash ('-'), dot ('.'), and slash ('/') to underscore ('_'). The X.509 Subject
# string as returned by the tls_id environmental variable, could additionally
# contain colon (':') or equal ('='). When using the --compat-names option, this
# old formatting and remapping will be re-enabled again. This is purely implemented
# for compatibility reasons when using older plug-ins or scripts which does not
# handle the new formatting or UTF-8 characters.
#
# See https://phabricator.vyos.net/T1512
compat-names

[edit]
vyos@r4-roll#

Device-type tap option works incorrectly

set interfaces openvpn vtun20 device-type 'tap'
set interfaces openvpn vtun20 local-address 10.0.0.0
set interfaces openvpn vtun20 local-host '100.64.0.1'
set interfaces openvpn vtun20 local-port '22222'
set interfaces openvpn vtun20 mode 'site-to-site'
set interfaces openvpn vtun20 remote-address '10.0.0.1'
set interfaces openvpn vtun20 remote-host '100.64.0.2'
set interfaces openvpn vtun20 remote-port '22222'
set interfaces openvpn vtun20 shared-secret-key-file '/config/auth/foo.key'

log

Nov 22 15:49:39 r5 openvpn-vtun20[9753]: /usr/libexec/vyos/system/unpriv-ip addr add dev vtun20 10.0.0.0/-1 broadcast 255.255.255.254
Nov 22 15:49:39 r5 netplugd[816]: eth1.50: can't get flags: No such device
Nov 22 15:49:39 r5 vyos-configd[579]: Sending response 1
Nov 22 15:49:39 r5 sudo[9743]: pam_unix(sudo:session): session closed for user root
Nov 22 15:49:39 r5 sudo[9769]:     root : TTY=unknown ; PWD=/run/openvpn ; USER=root ; COMMAND=/sbin/ip addr add dev vtun20 10.0.0.0/-1 broadcast 255.255.255.254
Nov 22 15:49:39 r5 sudo[9769]: pam_unix(sudo:session): session opened for user root by (uid=0)
Nov 22 15:49:39 r5 openvpn[9753]: Error: any valid prefix is expected rather than "10.0.0.0/-1".

It looks like this issue is already present in 1.3-rolling-202010270217, before the OpenVPN rewrite to get_config_dict():

set interfaces openvpn vtun20 local-address 10.0.0.1
set interfaces openvpn vtun20 local-host '172.18.254.202'
set interfaces openvpn vtun20 local-port '22222'
set interfaces openvpn vtun20 mode 'site-to-site'
set interfaces openvpn vtun20 remote-address '10.0.0.0'
set interfaces openvpn vtun20 remote-host '172.18.254.201'
set interfaces openvpn vtun20 remote-port '22222'
set interfaces openvpn vtun20 shared-secret-key-file '/config/auth/ovpn_test_site2site.key'
[email protected]# cat /run/openvpn/vtun20.conf
### Autogenerated by interfaces-openvpn.py ###
#
# See https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage
# for individual keyword definition

verb 3

user openvpn
group openvpn

dev-type tap
dev vtun20
persist-key
iproute /usr/libexec/vyos/system/unpriv-ip

proto udp
local 172.18.254.202
lport 22222

rport 22222
remote 172.18.254.201

secret /config/auth/ovpn_test_site2site.key

#
# OpenVPN site-2-site mode
#
ping 10
ping-restart 60

ifconfig 10.0.0.1 10.0.0.0





# Encryption options



# DEPRECATED This option will be removed in OpenVPN 2.5
# Until OpenVPN v2.3 the format of the X.509 Subject fields was formatted like this:
# /C=US/L=Somewhere/CN=John Doe/[email protected] In addition the old
# behaviour was to remap any character other than alphanumeric, underscore ('_'),
# dash ('-'), dot ('.'), and slash ('/') to underscore ('_'). The X.509 Subject
# string as returned by the tls_id environmental variable, could additionally
# contain colon (':') or equal ('='). When using the --compat-names option, this
# old formatting and remapping will be re-enabled again. This is purely implemented
# for compatibility reasons when using older plug-ins or scripts which does not
# handle the new formatting or UTF-8 characters.
#
# See https://phabricator.vyos.net/T1512
compat-names
Nov 23 10:29:18 LR2 systemd[1]: [email protected]: Service RestartSec=5s expired, scheduling restart.
Nov 23 10:29:18 LR2 systemd[1]: [email protected]: Scheduled restart job, restart counter is at 20.
Nov 23 10:29:18 LR2 openvpn-vtun20[18343]: DEPRECATED OPTION: --compat-names, please update your configuration. This will be removed in OpenVPN 2.5.
Nov 23 10:29:18 LR2 openvpn-vtun20[18343]: disabling NCP mode (--ncp-disable) because not in P2MP client or server mode
Nov 23 10:29:18 LR2 openvpn-vtun20[18343]: OpenVPN 2.4.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Feb 20 2019
Nov 23 10:29:18 LR2 openvpn-vtun20[18343]: library versions: OpenSSL 1.1.1d  10 Sep 2019, LZO 2.10
Nov 23 10:29:18 LR2 openvpn-vtun20[18343]: WARNING: you are using user/group/chroot/setcon without persist-tun -- this may cause restarts to fail
Nov 23 10:29:18 LR2 openvpn-vtun20[18343]: Outgoing Static Key Encryption: Cipher 'BF-CBC' initialized with 128 bit key
Nov 23 10:29:18 LR2 openvpn-vtun20[18343]: WARNING: INSECURE cipher with block size less than 128 bit (64 bit).  This allows attacks like SWEET32.  Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
Nov 23 10:29:18 LR2 openvpn-vtun20[18343]: Outgoing Static Key Encryption: Using 160 bit message hash 'SHA1' for HMAC authentication
Nov 23 10:29:18 LR2 openvpn-vtun20[18343]: Incoming Static Key Encryption: Cipher 'BF-CBC' initialized with 128 bit key
Nov 23 10:29:18 LR2 openvpn-vtun20[18343]: WARNING: INSECURE cipher with block size less than 128 bit (64 bit).  This allows attacks like SWEET32.  Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
Nov 23 10:29:18 LR2 openvpn-vtun20[18343]: Incoming Static Key Encryption: Using 160 bit message hash 'SHA1' for HMAC authentication
Nov 23 10:29:18 LR2 openvpn-vtun20[18343]: WARNING: Since you are using --dev tap, the second argument to --ifconfig must be a netmask, for example something like 255.255.255.0. (silence this warning with --ifconfig-nowarn)
Nov 23 10:29:18 LR2 openvpn-vtun20[18343]: WARNING: --local address [202.254.18.172] conflicts with --ifconfig subnet [10.0.0.1, 10.0.0.0] -- local and remote addresses cannot be inside of the --ifconfig subnet. (silence this warning with --ifconfig-nowarn)
Nov 23 10:29:18 LR2 openvpn-vtun20[18343]: TUN/TAP device vtun20 opened
Nov 23 10:29:18 LR2 openvpn-vtun20[18343]: TUN/TAP TX queue length set to 100
Nov 23 10:29:18 LR2 openvpn-vtun20[18343]: /usr/libexec/vyos/system/unpriv-ip link set dev vtun20 up mtu 1500
Nov 23 10:29:18 LR2 openvpn-vtun20[18343]: /usr/libexec/vyos/system/unpriv-ip addr add dev vtun20 10.0.0.1/-1 broadcast 255.255.255.255
Nov 23 10:29:18 LR2 openvpn[18343]: Error: any valid prefix is expected rather than "10.0.0.1/-1".
Nov 23 10:29:18 LR2 openvpn-vtun20[18343]: Linux ip addr add failed: external program exited with error status: 1
Nov 23 10:29:18 LR2 openvpn-vtun20[18343]: Exiting due to fatal error
Nov 23 10:29:18 LR2 systemd[1]: [email protected]: Main process exited, code=exited, status=1/FAILURE
Nov 23 10:29:18 LR2 systemd[1]: [email protected]: Failed with result 'exit-code'.
c-po changed the task status from Open to Needs testing.Nov 23 2020, 10:44 AM
c-po claimed this task.
c-po triaged this task as High priority.
c-po changed Difficulty level from Unknown (require assessment) to Normal (likely a few hours).
c-po changed Why the issue appeared? from Will be filled on close to Implementation mistake.
c-po changed Is it a breaking change? from Unspecified (possibly destroys the router) to Stricter validation.
erkin renamed this task from openvpn site-to-site dosn't work to OpenVPN site-to-site creates wrong peer address.Aug 29 2021, 12:15 PM
erkin set Issue type to Bug (incorrect behavior).
erkin removed a subscriber: Active contributors.