Pull request created: https://github.com/vyos/vyos-1x/pull/133

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

Please share a pre and post-commit config block for me for testing.

The loading error is caused by bridging a l2tpv3 interface, didn't see the cause at first because of the other errors. Since the bridge is now created at priority 470, and l2tpv3 is 800, when before an interface would be added to the bridge as it is created.

Pull request added: https://github.com/vyos/vyos-1x/pull/131

After adding the vif to bridge member interfaces, I get a config load error on boot. Running config, load, commit, works. Something to do with the order the configs get applied?

Just noticed bridge has a member interface parameter now. The vif bridge-group config was not migrated.

Thanks for testing.

@hagbard
In VyOS 1.2-rolling-201909190545 all work. Fixed. Thank's.

@sever I see that the new package hasn't been autobuild in our CI, I see to get that fixed. If you are in urgent need of the change, please build and install vyos-1x manually.

In release VyOS 1.2-rolling-201909180118 I dont see this command

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.

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

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?

In T1660#43438, @c-po wrote:

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

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

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

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.

The documentation is also correct. Please not that there are two git branches for the documentation, current and equuleus. You send me the VyOS 1.2.2 crux link. I gave you the upcoming VyOS 1.2 equuleus link.

Thanks! Should update the documentation @ https://vyos.readthedocs.io/en/latest/interfaces/bridging.html

The bahavior has changed, see https://vyos.readthedocs.io/en/equuleus/interfaces/bridging.html and T1556

When the site looses connection and thus a SIGUSR21 is sent to OpenVPN to restart internally the priviledges have dropped and yes, /sbin/ip can't be called again.

This is "as intended" b/c ping is an op-mode command.

backported to crux

Pull request for fixing this problem: https://github.com/vyos/vyatta-netflow/pull/4

Resolved with rewrite of op-mode scripts in Python.

We have change vyos configuration.
Now, our vyos still have 1 interface but haven't two ip adresses.
It have only one private IP.
VPN coming from wan connecte to it by public IP manage by compgany firewall and VPN coming from Local network connect to it by private ip adresses.