IPv4 ttl matching is missing too.
could this be copied to IPv4?
it's exactly same except the iptables module name called ttl

Sorry I can't replicate your issue, tested it with VyOS 1.2.0-rolling+201903110337.

I've finally managed to test this (apologies, we've had a super busy couple of months) and don't appear to be able to connect to the VPN anymore :(

I'm a little confused about the status of this task.

Tested it myself and can't find any issues.

Need to reopen this task.
Version: 1.2.0-LTS.
Running configuration:

vyos@test-01# show 
 interfaces {
     ethernet eth0 {
         address 192.168.55.18/30
         duplex auto
         hw-id 08:00:27:95:bb:f6
         smp-affinity auto
         speed auto
     }
     ethernet eth1 {
         address 192.168.56.3/24
         duplex auto
         hw-id 08:00:27:8e:d6:fb
         smp-affinity auto
         speed auto
     }
     ethernet eth2 {
         duplex auto
         hw-id 08:00:27:8c:27:04
         smp-affinity auto
         speed auto
     }
     loopback lo {
     }
 }
 service {
     ssh {
     }
 }
 system {
     config-management {
         commit-revisions 100
     }
     console {
         device ttyS0 {
             speed 9600
         }
     }
     host-name test-01
     login {
         user vyos {
             authentication {
                 encrypted-password $6$7X4XbQJ2xVMZ8$NmISPmyC1f88cIfcKig01pkjePNTVeeWwULrHgich6wB0A1TH/b31Jywpsde8Mv4/B8Qa5CxFM.rlXmfOQT0Z0
                 plaintext-password ""
             }
             level admin
         }
     }
     name-server 1.1.1.1
     ntp {
         server 0.pool.ntp.org {
         }
         server 1.pool.ntp.org {
         }
         server 2.pool.ntp.org {
         }
     }
     syslog {
         global {
             facility all {
                 level info
             }
             facility protocols {
                 level debug
             }
         }
     }
     time-zone UTC
 }

@thinkl33t Please test the latest rolling which has openvpn2.4 installed.

Just to add extra info to this ticket, I had a openvpn-option that i wanted to add but it contained a single quote. I was not able to do this (in version 1.8.x this worked).

I was not able to test sooner. But i confirmed it works properly with rolling release vyos-1.2.0-rolling+201902060337-amd64.

Handled in/with T484, hopefully

@thinkl33t Can you please test?

My fault for not having the time to test this as one of the users who has a need for RFC compliant VRRP. The use of + for interface matching is less than ideal but if we do so we should take care to recommend that use of 802.1Q VLAN sub-interfaces not make use of the parent (untagged) interface else traffic matching will not be obvious.

Does this mean it can now listen on "outer" transport IPv6 addresses now that it is using 2.4.0 (even if it is just a special "option" and not yet in the VyOS CLI)?

@jmlccdmd Ok, I'll re-test with in/out then.

@thinkl33t Would you mind testing your use case with https://downloads.vyos.io/rolling/current/amd64/vyos-1.2.0-rolling%2B201901312041-amd64.iso or later? This iso is using the bpo package of openvpn (2.4.0).

@thinkl33t http://dev.packages.vyos.net/repositories/current/vyos/pool/main/o/openvpn/openvpn_2.4.0-6+deb9u1~bpo8+1_amd64.deb

@c-po imported and test against latest rolling, I couldn't find any issue with 2.4.

@c-po it only affects clients which enforce tls 1.0 or 1.1, at least what I have tested. The perl code needs quite some rework, so I think I split the task into getting a newer release of openvpn into the build. Newer versions have tls 1.0 and 1.1 disabled per default from what I have read, so I think it might be more a changelog announcement that with the new version only tls 1.2 is automatically supported and you have the option to enable weak ciphers via opt .... or so. I'm not too sure yet, I think I have to wait a little on the response once the newer version is in rolling and the feedback I receive.

I confirm that in yesterday's rolling image, the problem is corrected.

I reopen this bug.

Sounds more reasonable (enable than disable). Will this affect backwards compatibility or will there be a migrator?

In T1051#27092, @c-po wrote:

set interfaces openvpn vtun0 disable-weak-tls-ciphers

On my systems, the problem persist with today's rolling release.

Unfortunately I still see the problem when the blackhole routes are set with a distance of 240 and the 0.0.0.0 route is distance 1.

@syncer Currently we ship in the iso openvpn from main, we could use it from bpo which would be 2.4 (2.6 is the latest), or we replace it with a self-compiled 2.6, or do you just want cpo's solution implemented?

@hagbard can you please bump version of openvpn

Since this is a trivial cosmetic issue, we are about to freeze 1.2.0, and the installer is due for a rework in 1.3.0, I'm going to ignore this for now.

I'm not sure. Only hypothesis...

are you sure, or could it be related to conntrack helper topic in T1141?

Also happens when you put in invalid BGP config that doesn't get caught by the validation. It then thinks its applied successfully, saves it as the boot config, then BGP is broken upon next boot up.

No issue known but it eases reproducibility

Thank you for this very quick response.
I will be out for the night after this message.

@alexandrestein can you share your complete dns forwarding config node please?

This feature is great but it looks buggy to me.

OK. So, for now, anyone can use workarounds provided in T1011 or here. And wait for permanent fix in further builds.