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

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

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.

pushed to current too and rebuilt kernel in CI successfully.

@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.

@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.

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.

Helo, @MarcSim. I want reproduce your issue in lab, can you provide your ipsec configuration from Central VyOS and one of site

show configuration commands | match ipsec | strip-private

@alkersan I think you need to create the link via Makefile in vyos-1x. At least I don't know of any possibility doing that within the xml.

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

https://downloads.vyos.io/rolling/current/amd64/vyos-1.2-rolling-201909102147-amd64.iso or later

https://vyos.readthedocs.io/en/latest/vpn/wireguard.html

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

https://github.com/vyos/vyos-1x/commit/1017c8103f12ebd6db4f250d8a154571fff32db1
Will be available in tomorrows rolling release for testing. Documentation is underway.

Why can I not delete the default key? If I wan‘t to drop WireGuard on a device I also wan’t to remove that key.

The default keys can only be overwritten, named-keys can be removed.

Just adding a suggestion since cloudflared (argo tunnel) is open source : https://github.com/cloudflare/cloudflared

This behavior not only for ipv6 and appears after task T484

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

It still fails in config mode:

vyos@vyos# ls <TAB>
  Configuration path [-o] is not valid
  Set failed

This PR fixes it for me: https://github.com/vyos/vyatta-op/pull/29

As a workaround could this be added as the first lines of the bash script?
This will check the primary group the script executes via and respawn as the vyattacfg group if it's something else before continuing.

if [ $(id -gn) != vyattacfg ]; then
    exec sg vyattacfg "$0 $*"
fi

NB! the if is necessary because the script should not execute the exec when you respawn as correct group.
You will end in a exec loop if its not there .. :)
i've not tested this on vyos, but have helped me on other systems

Using 1.2.3-eap1 frr version 7.2-dev-10290718, there is still a problem that the default route disappears between 30 minutes and 40 minutes.

https://github.com/vyos/vyos-1x/commit/189ae4f7096abf7ca7100a4a31e038ce9e3e19c2

Confirmed, same issue in 1.2.2

Works in the latest image for me.