The loading error is caused by bridging a l2tpv3 interface, didn't see the cause at first because of the other errors. Since the bridge is now created at priority 470, and l2tpv3 is 800, when before an interface would be added to the bridge as it is created.

Pull request added: https://github.com/vyos/vyos-1x/pull/131

After adding the vif to bridge member interfaces, I get a config load error on boot. Running config, load, commit, works. Something to do with the order the configs get applied?

Just noticed bridge has a member interface parameter now. The vif bridge-group config was not migrated.

https://phabricator.vyos.net/T1499

@thinkl33t you can run your own DNS server with dynamic update functionality, vyos's dhcp server will write the hostnames to it. Doing that is outside the scope of vyos though, and you'd have to think of security, e.g. can a rogue dhcp client DNS spoof your hostnames to do a MITM attack. Systems that do do dyn-dns updates, for example FreeIPA, usually use some sort of pre-shared keys/certificates on the clients (for authentication) and limit the scope to IP updates on preexisting hostnames only, they don't allow adding arbitrary hostnames. At least I'd limit the scope to add all dynamic dns updates to a single zone predefined expressly for that purpose, and not use that zone for any security-critical applications, like logging in to services or doing unauthenticated connections, where a MITM may scrape your sensitive data. I'd only do dyn-dns hostnames from dhcp on a DHCP network where I'm absolutely sure no rogue client could gain access to it, via the network or physically, and that is almost never useful.

Thanks for testing.

In T1416#40429, @zsdc wrote:

@thinkl33t, recommended way is using dynamic-dns-update, all other ways are not recommended to use at this moment.

@hagbard
In VyOS 1.2-rolling-201909190545 all work. Fixed. Thank's.

Seems that upstream did not backport the fixes to the stable version's. So it is only included in frr 7.2.
I asked them for backport.

@sever I see that the new package hasn't been autobuild in our CI, I see to get that fixed. If you are in urgent need of the change, please build and install vyos-1x manually.

In release VyOS 1.2-rolling-201909180118 I dont see this command

Okay, the old vyatta-bonding.pl executed the following code when a bond member has been removed:

PR merged.

This issue don't reproduces at 1.2.2 and 1.2.3-epa1. As for rolling release after T1548, seems all correct and works.

set interfaces openvpn vtun0 server push-route '100.64.0.0/24'
set interfaces openvpn vtun0 server push-route '172.16.41.0/24'
set interfaces openvpn vtun0 server push-route '172.16.42.0/24'

vyos@vyos# sudo cat /opt/vyatta/etc/openvpn/openvpn-vtun0.conf | grep push
push "route 100.64.0.0 255.255.255.0"
push "route 172.16.41.0 255.255.255.0"
push "route 172.16.42.0 255.255.255.0"

on client

vyos@vyos-rtr01# run show ip route | grep vtun0
S>* 10.23.0.0/16 [1/0] is directly connected, vtun0, 00:03:25
C>* 10.23.1.1/32 is directly connected, vtun0, 00:03:25
K>* 100.64.0.0/24 [0/0] via 10.23.1.1, vtun0, 00:03:25
K>* 172.16.41.0/24 [0/0] via 10.23.1.1, vtun0, 00:03:25
K>* 172.16.42.0/24 [0/0] via 10.23.1.1, vtun0, 00:03:25

@kronenpj can you try last rolling release for confirm this?

I have just sent a Pull Request to clarify on the manual how tricky openvpn-option --reneg-sec can be.

Tomorrows rolling ISO will have the patch applied.
Please test and let me know how it goes.

@sever Issue found and working on a patch.

ifname  | called-sid |    calling-sid    |     ip      | ip6 | ip6-dp | rate-limit | state  |  uptime  |        sid       
----------+------------+-------------------+-------------+-----+--------+------------+--------+----------+------------------
 bond0.51 | bond0.51   | 08:00:27:82:43:ae | 192.168.0.2 |     |        |            | active | 00:01:03 | d060220ce77252a9

Auto creation of vlans failed.

@rcit Lot's of development underway and since I wasn't able to reproduce it anymoe, I thought I ask, Feel free to reopen if the issue re-occurs.

You are absolutely right. Was a stressful morning sorting this out, thanks for the response.

@LBegnaud if I read the source correct the command set vpn ipsec options disable-route-autoinstall is what you are looking for, it was implemented in T71.

Yes definitely just ran into this myself. I think i had the opposite problem of OP. I have only ipsec VTI on the router, but whenever a reset vpn ipsec-peer command was run, the peer IP was being added as default route for table 220. Furthermore, this was being respected as the default route for the system (I'm not sure how route priority works with tables, but i'm guessing table 220 has preference over table main?)

@hagbard in first my message actual config for bond1 with client-subnet 10.3.0.0/23 and authentication mode "local".
I plan to use several vlan's for several services.
You use it without vlans.

everything works without issue as far a I see.

@sever Yeah, sorry about the typo. You need to define an IP pool and an authentication method if you are not using a RADIUS server for that.
(I have bond0 in my lab so you need to change that to bond1 if you copy).

@hagbard bond0 - is WAN interface without vlans/tags. For DHCP listening I use bond1 interface, not PPP.
A try man https://vyos.readthedocs.io/en/latest/services/ipoe-server.html

@sever Can you please try: set service pppoe-server interface bond0 vlan-id 55. And have a look into /var/log/messages what accel is reporting there once the dhcp reply arrives. I'm going to lab up your config and test as well.
Also you need to define an IP pool a client can get an IP address from.
https://vyos.readthedocs.io/en/latest/services/ipoe-server.html
(btw: show config comands gives you a nicer config overview)

@hagbard I don't know if this is somehow relevant regarding VyOS 1.3, but i have tested it with VyOS 1.2.3-epa1 just today and it works perfectly.

In T1664#43564, @hagbard wrote:

@sever Can you please also share your pppoe-server config?

@sever Can you please also share your pppoe-server config?

Thank you Taras. Pull request sent.
https://github.com/vyos/vyos-documentation/pull/103

@s.lorente, could you please add details about this option to the https://github.com/vyos/vyos-documentation?

In T1660#43438, @c-po wrote:

Please test again with the rolling release from 2019-09-14. Thanks for reporting the issue.

According to my findings, firewall all-pingaffects only to LOCAL. It does not affect to IN or OUT.

There are a number of strange things going on here, and I suspect there are multiple bugs:

[ protocols bgp 132394 ]
%BGP: No IPv4 Unicast peer configured
%BGP: No IPv6 Unicast peer configured
% Unknown command: bgp scan-time 5
Error configuring routing subsystem. See log for more detailed information

We did an update from 1.2.1-S2 to 1.2.3-epa1.

the error in the test-log is just the errorcode, but the real error message is a memory allocation error:

vyos_bld@dd27213bf7b5:/vyos/ipaddrcheck/src$ ./ipaddrcheck
Error: could not allocate memory!

This could be used as base for testing:

No feedback received, considering this as resolved. please reopen if issue reappears.

The same build procedure is tested fine on x86_64 and armhf without this issue

PR https://github.com/vyos/vyos-1x/pull/129 commit 02195d0

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

I'm very interested in this as well. Especially when you do lots of filtering based on ipsets that contain adresses from multiple zones, inclusion can save you a lot of redundancy.