@Scoopta Can you share commands on how to reproduce it?
It will be easier for developers to reproduce this bug.

In my test configuration all works fine.

set interfaces bridge br0 address '10.0.0.1/30'
set interfaces bridge br0 member interface vtun0
set interfaces openvpn vtun0 device-type 'tap'
set interfaces openvpn vtun0 encryption cipher 'aes128'
set interfaces openvpn vtun0 mode 'server'
set interfaces openvpn vtun0 server subnet '192.168.1.0/24'
set interfaces openvpn vtun0 tls ca-cert-file '/config/auth/openvpn/ca.crt'
set interfaces openvpn vtun0 tls cert-file '/config/auth/openvpn/central.crt'
set interfaces openvpn vtun0 tls dh-file '/config/auth/openvpn/dh.pem'
set interfaces openvpn vtun0 tls key-file '/config/auth/openvpn/central.key'

Bridge

[email protected]:~$ sudo brctl show
bridge name	bridge id		STP enabled	interfaces
br0		8000.923f3607f0dc	no		vtun0

My config which breaks

set interfaces openvpn vtun2 device-type tap
set interfaces openvpn vtun2 mode site-to-site 
set interfaces openvpn vtun2 persistent-tunnel
set interfaces openvpn vtun2 shared-secret-key-file /config/auth/ovpn.key
set interfaces bridge br3 member interface vtun2

In T3686#98142, @Scoopta wrote:

My config which breaks

set interfaces openvpn vtun2 device-type tap
set interfaces openvpn vtun2 mode site-to-site

Did this work in work in 1.2 or any other version?

I'm not sure, I haven't tried it. Thing is if I add

set interfaces openvpn vtun2 local-address fe80::1

it no longer breaks. For now I'm setting local-address and then adding it to a bridge which while pointless works as a workaround. If it is an issue with site-to-site it specifically has to do with not having local-address set while attempting to bridge. The reason I want to use site-to-site is so I can use static keys as I only have 2 hosts on the tunnel anyway. If needed I can test on v1.2 or v1.4. v1.3 is my first VyOS deployment but I'm in an IPv6 only environment running IS-IS across VPN tunnels and vxlans which is a rather unconventional configuration so I've broken VyOS quite a lot with this setup.

To reproduce in 1.4

set interfaces bridge br3 member interface vtun2
set interfaces openvpn vtun2 device-type 'tap'
set interfaces openvpn vtun2 mode 'site-to-site'
set interfaces openvpn vtun2 persistent-tunnel
set interfaces openvpn vtun2 shared-secret-key 'foo'
set pki openvpn shared-secret foo key '190696ff2244ca9ce8d5bef8718c58881fe8df8e3519c8bf6ede49108c97a5d9456db648d8c5ca953bb19d21978527a742497426313e614640d037ffffa4980be315e193727ebfb28f3725b779e2d3309ad6f8c939363f7fc14a0080c81e3faf4b053661c81c3003ddabeb87ac8611b81718956b7325f03978c74f502b39965f0d788b21b4370f6a625e3098f8d71ff3e653f50c54b424c511cba78871b38337237830a34266aa9558cd69c68ded89f7f0a82f94b5b87200c7ea05edb14a806e9e4998b00dc2895d976c0e506a6a06056745bca6ce1d2a5c95a51a1460e3080c7743eecbcee9d2c4f89d9e1b59f44484e43591f43bf713255b5de13ae8500620'
set pki openvpn shared-secret foo version '1'

Commit:

Traceback (most recent call last):
  File "/usr/libexec/vyos/conf_mode/interfaces-openvpn.py", line 663, in <module>
    verify(c)
  File "/usr/libexec/vyos/conf_mode/interfaces-openvpn.py", line 228, in verify
    if len([addr for addr in openvpn['local_address'] if is_ipv4(addr)]) > 1:
KeyError: 'local_address'

@Scoopta I can't get your configuration, how does should work without the declaration source or remote address?
There is a template that generates OpenVPN site-to-site configuration https://github.com/vyos/vyos-1x/blob/9910020ae6ef37964c97bb28b6b1d84f8227650b/data/templates/openvpn/server.conf.tmpl#L143-L147

Or could you send an example of the required working OpenVPN config? That would be easiest and great.

For example such configuration:

set interfaces bridge br3 member interface vtun2
set interfaces openvpn vtun2 device-type 'tap'
set interfaces openvpn vtun2 mode 'site-to-site'
set interfaces openvpn vtun2 persistent-tunnel
set interfaces openvpn vtun2 shared-secret-key 'foo'

Will generate:

verb 3
dev-type tap
dev vtun2
persist-key
proto udp
secret /run/openvpn/vtun2_shared.key
persist-tun

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

Is it what do you expect?

PR https://github.com/vyos/vyos-1x/pull/1214

@Scoopta Can you check your configuration with the next rolling release?

I think I'm experiencing this same issue. I just tried upgrading a VPN server running 1.3-rolling-202001260217 to 1.3.0 LTS. As this is a production server (albeit a secondary/backup server) I've reverted to the old version of VyOS, and it looks like a fix is already on its way, so I just wanted to add my info to the ticket.

My config has a number of openvpn tun devices (with local-address set) and openvpn tap devices (with no local-address set). After upgrade, all the tap devices were missing from the config. I tried adding one of them back with the exact same config that worked on 1.3-rolling-202001260217, but got the same error as in the original post.

This is the tap config I tried with (with public IP address removed):

openvpn vtun24025 {
    description "Hydra-BHM-4025 data tunnel"
    device-type tap
    encryption {
        cipher aes256
    }
    hash sha256
    local-host [removed]
    local-port 24025
    mode site-to-site
    persistent-tunnel
    shared-secret-key-file /config/auth/Hydra-BHM-4025.key
}

(the interface is also added to a bridge in the config)

I can't get your configuration, how does should work without the declaration source or remote address?

What do you mean? Only one side of the tunnel needs a remote address, the other side can behave like a server and doesn't need any address configuration

Or could you send an example of the required working OpenVPN config? That would be easiest and great.

I sent my config earlier, but these are the commands used to generate the config I'd like to use, I just add a local-address as a workaround

set interfaces openvpn vtun2 device-type tap
set interfaces openvpn vtun2 mode site-to-site 
set interfaces openvpn vtun2 persistent-tunnel
set interfaces openvpn vtun2 shared-secret-key-file /config/auth/ovpn.key
set interfaces bridge br3 member interface vtun2

Can you check your configuration with the next rolling release?

Will do when I have some time to deploy an update to my routers.

I can confirm that the latest 202202140317 build fixes this issue, thanks.

PR for 1.3 https://github.com/vyos/vyos-1x/pull/1221

Is this fixed in the released 1.3.1? It looks like it was merged into equuleus, but I don't see it in the 1.3.1 changelog at https://blog.vyos.io/vyos-1.3.1-release.

If not, is there a timeline for including it in a 1.3.x LTS release? Right now this is preventing us from upgrading some of our routers.

Hi @freelancer . PR mentioned by @Viacheslav was merged on February 17, so fix should be included in 1.3.1

Thank you. I can confirm it works as expected in 1.3.1-S1.