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.

Thanks for your response, did you test a newer image already? There was a lot of work done meanwhile.

tried with the first version 1.2, problem was still present. After that, decided to get us a physical router/fw because ipsec would stopped without any obvious reason.
It was a long time ago, almost year and a half...

@mario Did you manage to upgrade to 1.2 and if so, do you still have that issue?

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

I think encapsulate the udp based traffic into tcp is more than counter productive and makes it an easy DoS target.

Actually somebody made a nifty websocket tunnel named wstunnel (similar to stunnel conceptually, but websockets is more natural for tunneling generic binary protocols thanks to webRTC...) that seems to work alright for Wireguard.

I was thinking some more along the lines of stunnel and wrapping wireguard that way but it would require additional packaging and integration on the vyos side. Luckily whatever outbound filtering is in place for this specific implementation seems to be relatively basic and limited to port blocking/whitelisting.

As long as the local nginx is not listening on the external interface on udp/443, functionally there should be no limitation to running wireguard on 443 there. A convoluted script to check that the current config has no existing 443 mapping is one solution, but that seems a bit fragile, and wouldn't really tell you where in the config the blocking 443 instance is.

Why not using ports higher 1024? Port 80 and 443 are so called privileged ports, not sure if that is really required. Port udp/80, udp/443 for instance may interfere in the future with QUIC.

Yes, I understand that. The primary request is to be able to set a listen port lower than 1024 without having to create a destination NAT rule to get the same result.

That is listen port. endpoints are peer specific, if you have multiple peers on the same interface, each one has of course it's own endpoint if you want to initiate the connections. Otherwise, once the other peer connected to your gateway (assuming the handshake was successful), this information is taken from the header.

@trystan Listen or endpoint? The listen port had been limited to avoid issues with IANA assigned ports.
udp/80 or udp/443 might not m=be the best option anyway.

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

Thanks for that, What I am suspecting is once the maximum value is reached the router is starting to drop packets, rather clearing the stale connections.

Hello @Daya , you can set custom kernel params for nf_conntrack

set system sysctl custom net.netfilter.nf_conntrack_max value 786432
set system sysctl custom net.nf_conntrack_max value 786432

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.

It should have been fixed by https://github.com/vyos/vyos-1x/commit/ff05e2a90edf8af5d7b8ad5c69cae2dd40af2c8d It works for me in post-Sep 01 images and I don't see the error in the latest one, but I'm not sure why it would appear in the Sep 01 image if the commit is from Aug 30.

@nirmal The full fix is a bit more complicated. There are two cases: when it's called from conf mode at commit time, it needs to use the value from the proposed config (that's returnValue). However, in op mode, it also re-generates the config, so your fix would make the send dhcp6.client-id option disappear from the config when a user runs renew dhcpv6 interface .... A full fix needs to handle both cases and use returnEffectiveValue in op mode.

It was indeed a bug, caused by the same issue as all other subtasks of T1598: lack of proper synchronization.
If it re-appears, please reopen of course.

Disappearing entries should no longer be a problem, but if it re-appears due to a missing case, please reopen.