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.

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.

OpenVPN now runs as user openvpn with the above helper script. Please also test this new implementation, it will be in the rolling ISO which is building right now.

Persistent tunnel is a configuration option set interfaces openvpn vtun10 persistent-tunnel