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.

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

pushed to current too and rebuilt kernel in CI successfully.

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

@runar
I just cross compiled it successfully. CI uses a sed right now to correct it, all paths are now generic.
What I currently can't do is actually testing the binaries on a real device, I would appreciate it if you can do that.

This is a support request,
please use forum.vyos.io for such request

@drac , before implementation cli command for restarting l2tp I need explanation how to reproduce issue when daemon is died. Can you detailed explain this?

Implementation advanced ppp-options

vyos@vyos# set vpn l2tp remote-access ppp-options 
Possible completions:
   lcp-echo-failure
                Maximum number of Echo-Requests may be sent without valid reply
   lcp-echo-interval
                LCP echo-requests/sec

https://github.com/vyos/vyos-1x/pull/127

@drac, thank you for info.
reset commands migrated to vyos-1x, PR bellow
https://github.com/vyos/vyatta-ravpn/pull/13
https://github.com/vyos/vyos-1x/pull/126

I'm thinking about trying to run either tayga or jool as a docker container inside of VyOS. Has anyone tried something like this? If I wrote a guide on how to do this I wonder if it would be an OK temporary solution until it's integrated into VyOS.

Ok, closing as wontfix

No, we don't use vyos in production any more, so I can't tell.

We have openned a ticket on VyOS support, and they have find the solution.
We had to add this configuration :

@rcit Is that still a relevant issue?

nothing added we would need.

I have been trying this new feature out.

1. I had configured an MTU value and I had some sessions connected, I realised I had set it incorrect so I modified it to the correct value. On commit I received an error (sorry I don't have it at present) but to the extent that accel-pppd was not running on localhost:2004.

I had to reboot the router to get it working again.