In T1226#32102, @hagbard wrote:

@Maltahl Let me know if you still need help, please. I put the task meanwhile on-hold.

@Maltahl Let me know if you still need help, please. I put the task meanwhile on-hold.

Configured protocols does not match Proposed protocols. Try without pfs configuration on the VyOS side.

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.

http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyos-1x/vyos-1x_1.2.0-12_all.deb next rolling release has it.

Change your OSPF network type to broadcast. I had the exact same issue with a Cisco 877 Client with a VYOS hub.

So this problem still exists but I have no clue where to add it in our source @dmbaturin @UnicronNL

Ah, there was a similar issue with dhcp last couple of weeks where quotes broke the config (T1129). Can you try using &nbsp instead of your whitespace?

if we use a more simply string without blank as e.g.

skip "yourIP"

all seems OK. So I think there is some problem in parsing a whole quoted string.

just what I've post
dynamic {

interface eth1 {
    service dyndns {
        host-name xxxxx.mine.nu
        host-name yyyyy.dnsalias.com
        login someuser
        password somepsw
    }
    use-web {
        skip "this is your IP"
        url http://www.web.net/GetRemoteIP.asp
    }
}

}

In T1226#32033, @hagbard wrote:

@Maltahl Did you try the same with the rolling release? I don't see any issue with your config in particular, did you check that the wg traffic is actually getting to your router02?

Hmm, I have 7.1-dev-1~debian8+1 on a rolling and 3 blackhole routes and no issues at all.

@Maltahl Did you try the same with the rolling release? I don't see any issue with your config in particular, did you check that the wg traffic is actually getting to your router02?

Con you provide a configuration to reproduce the issue?

server OK but now we get ERROR:
Feb 2 16:51:21 VyosCP ddclient[5968]: FAILED: updating is: notfqdn: A Fully-Qualified Domain Name was not provided
Feb 2 16:56:21 VyosCP ddclient[5968]: WARNING: file /var/cache/ddclient/ddclient.cache, line 5: Invalid Value for keyword 'ip' = ''
Feb 2 16:56:22 VyosCP ddclient[5968]: FAILED: updating is: notfqdn: A Fully-Qualified Domain Name was not provided
Feb 2 17:05:28 VyosCP ddclient[4710]: WARNING: file /var/cache/ddclient/ddclient.cache, line 5: Invalid Value for keyword 'ip' = ''
Feb 2 17:05:36 VyosCP ddclient[4710]: FAILED: updating is: notfqdn: A Fully-Qualified Domain Name was not provided

That is not how wireguard works ? that is how ipsec and openvpn works.

This is how ipv4 works :) and have nothing to do with wireguard, ipsec etc. Actually the config you have applied eill in some situations work, but that relies on the handling of the packets inside the kernel and is not following the tcp/ip principles... If you take a look on the quick start guide on the wireguard webpage you se it there aswell... https://www.wireguard.com/quickstart/.

In T1226#32008, @runar wrote:

Hi! I see that your tunnels does not resides inside the same subnet, one devise is '10.0.90.1/24' and the other one '10.0.100.1/24'.. please move one of then to ip .2 in the subnet belonging to the other router.

After some more playing with it ... it solves the problem reproducibly to have staticd=yes included and NOT have the null route anywhere.

It solved it for me yesterday. After some more playing today this now seems to be a frr bug.

@primoz Adding staticd to the daemons config fixes the issue reproducibly on affected systems, even after reboot?

I have done a bit more work on this problem and, correct me if I'm wrong, I no longer think it is driver related.

I can confirm this. 1.2.0-EPA3 does not have thisbissue but 1.2.0 has it.

Hi! I see that your tunnels does not resides inside the same subnet, one devise is '10.0.90.1/24' and the other one '10.0.100.1/24'.. please move one of then to ip .2 in the subnet belonging to the other router.

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)?

Forgot to add version for both routers, sorry.

There might actually be a bit of a deeper problem here, somewhat conditional on some static interface routing. On an broken system, it does say something about staticd starting

Wierd, i cannot reproduce this on LTS 1.2.0 on both baremetal and virtual instances.

to /etc/frr/daemons (+ restarting frr) seems to fix this.

@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

Package needs to be build from source. There are already some packages which we build that way like libyang or librtr so not a big deal.

Change was reverted because "libcidr-dev is not available until Debian Buster thus the container can't be built"

And more info:

I tracked down what is causing this.

http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyos-1x/vyos-1x_1.2.0-11_all.deb or next rolling release will have the fix.

Fix: https://github.com/vyos/vyos-1x/commit/2f70340179a64d5936c32cc3c0d6d7f6f04054d0 applied, pkg build currently running.

Too add, routes are present in FRR

Bug confirmed.

I can't replicate it, but I'm using also the rolling release.
Can you please provide the output of:

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