No, we don't use vyos in production any more, so I can't tell.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Sep 12 2019
We have openned a ticket on VyOS support, and they have find the solution.
We had to add this configuration :
Sep 11 2019
@rcit Is that still a relevant issue?
nothing added we would need.
I have been trying this new feature out.
- 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.
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...
Sep 10 2019
@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/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.
Sep 9 2019
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.
set interfaces wireguard wg1 port 443
@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.
Sep 8 2019
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
Sep 7 2019
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.
Sep 6 2019
Confirmed, same issue in 1.2.2
Works in the latest image for me.