I have rebuilt the router and this appears to be working as expected now. Marking as resolved.

PR 138

I've tested it and can't reproduce. There are a few issues in the debian files and autoreconf, but other than that everything seems to work just fine.

There is no such thing like separate identities. You can either decrypt a package or you can't, that's about it. You basically have to hand out more public keys, you have to maintain more keys. As I mentioned before I only see currently disadvantages so far. However the user can chose what way to go and multiple options are always good. If it helps you, well that's nice to hear.

In T1572#42883, @hagbard wrote:

It's not so much the implementation as I wrote before, it just doesn't seem beneficial. It gets implemented anyway, but I try to understand why a user would like to use that. The private key is by the way no identity and also won't interfere with multiple VPN peers if you are using only one pk. On IP:12345 arrives an encrypted packet, it is simply decrypted using your pk. If it works it's given to your kernel netlink interface as far as I recall and routed there, so no verification of the private key anywhere. If it can't be decrypted, it's discarded. If you have multiple wg interfaces, your 'crypto routing' either allows the traffic to the peer or discards it if it doesn't fit, the private key has nothing to do with that, since the public key of your peer is used to encrypt it. Summary, I still cna't see any benefit having that, which doesn't mean that I won't implement it.

This feature is currently in the 1.2 rolling release.

It would be awsome if the feature could also be made available in the next VyOS 1.2.x version.
Because it likely takes a lot more time until version 1.3 gets released.

https://github.com/vyos/vyos-1x/commit/c6e9285262ddd762aac96ad3fa30d63cdeb2c6f2

PR https://github.com/vyos/vyos-1x/pull/137, using vyos-hostsd-client instead of typical adding record to /etc/hosts

Can confirm. All my routing tables now have 0.0.0.0/0, no matter what the device is. This is just in 1.2.3.

Seems that it s merged an in 1.2.3 it looks in the moment good for me:

reproduced on 1.2-rolling-201909100338

Unfortunately we have multiple commands like this.

Exist interesting moment when LLDPD communicate with cisco ios, after 1 min 55 second LLDPD in VyOS forget cisco device, but cisco device send LLDP (with ethertype encapsulated in vlan 1 0x8100). However LLDPD in VyOS remember mikrotik and other VyOS router, which directly connected, and which also transmit LLDP. I was try using and new version LLDPD which build for myself, but same result.
After adding vlan 1 on directly connected interface with cisco device LLDPD in VyOS, R1 don't forget it.

That's fixed the problem we had, but we've encountered some other strangeness.

Bump

At this point I've moved all my ASAs to VyOS, and all my tunnels to Wireguard. Unfortunately I cannot test this setup anymore.

Do you still have that problem?
Did you see EwaldvanGeffen's message?
Do you have any comment on it?

Thank you, @c-po, I'll go deploy it now, then! :-)

https://downloads.vyos.io/rolling/current/amd64/vyos-1.2-rolling-201909231545-amd64.iso

ISO rebuild triggered

It's in 1.2 rolling too, but the iso has to rebuild. You can alternatively download and manually install http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyos-1x/vyos-1x_1.3.0-16_all.deb.

Has this been merged into 1.2, or just 1.3? Because all of the 1.2-rolling images currently available from downloads.vyos.io right now have this bug in them :-(

MikroTik RouterOS supports something like this:

Why does this BGP neighbor need to be configred in the VyOS CLI? Wouldn't it be added automatically as a side-effect of wanting netflow data to have ASNs? Maybe add a flag to netflow, for those of us who are carrying full tables.

https://github.com/vyos/vyos-1x/commit/eed2ba5379067ba3ef3a7b9eef72b8252958e766