WIP: https://github.com/vyos/vyos-1x/pull/325
We won't do strict exclusion of client IPs from the server pool, but just print a warning if they overlap. This way old configs won't require migration and will still work, and new configurations will be able to manually set a smaller pool.
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
Feed All Stories
All Stories
All Stories
Apr 10 2020
Apr 10 2020
jjakob changed the status of T2235: OpenVPN server client IP doesn't reserve that IP in the pool from Open to In progress.
GitHub <noreply@github.com> committed rVYOSONEX2c8c3117093b: Merge pull request #324 from DmitriyEshenko/fix-res-ra (authored by c-po).
Unknown Object (User) added a comment to T2262: Broken reset commands for pptp and l2tp.
GitHub <noreply@github.com> committed rVYOSONEX881a9b679316: Merge pull request #323 from jjakob/openvpn-verify-bridge-fix (authored by c-po).
jjakob changed the status of T2266: openvpn bridged client-server doesn't work (validation error) from Open to In progress.
https://github.com/vyos/vyos-1x/pull/323
Bridged mode still doesn't work until T2064 is fixed, but at least the validation should be fixed.
GitHub <noreply@github.com> committed rVYOSONEX5ecfd5c973a5: Merge pull request #230 from DaniilHarun/upstream (authored by hagbard-01 <39653662+hagbard-01@users.noreply.github.com>).
jjakob triaged T2266: openvpn bridged client-server doesn't work (validation error) as Normal priority.
c-po committed rVYOSONEX7156762ed3b0: op-mode: raid: T689: Typo in description (authored by Viacheslav Hletenko <v.gletenko@vyos.io>).
It's best if we just use packages targeted for buster, not another debian release. I suggest you create PRs for all pathches needed (in addition to the one you already submitted) in Debian's PTS for buster's conntrack-tools, and then ask them to make a new release with those patches included.
The new conntract package depend in newer libnetfilter. but you dont need to rebuild the package, just download the debs.
Unknown Object (User) created T2263: Reset feature for SSTP sessions.
Unknown Object (User) changed the status of T2262: Broken reset commands for pptp and l2tp from Open to In progress.
Unknown Object (User) claimed T2262: Broken reset commands for pptp and l2tp.
Unknown Object (User) updated the task description for T2262: Broken reset commands for pptp and l2tp.
Unknown Object (User) created T2262: Broken reset commands for pptp and l2tp.
c-po placed T1875: Add the ability to use network address as BGP neighbor (bgp listen range) up for grabs.
c-po closed T1629: IP addresses configured on vif-s interfaces are not added to the system as Resolved.
c-po added a comment to T1629: IP addresses configured on vif-s interfaces are not added to the system.
15: eth1.100@eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state LOWERLAYERDOWN group default qlen 1000
link/ether 00:0d:b9:53:07:ed brd ff:ff:ff:ff:ff:ff
inet 192.168.1.1/24 scope global eth1.100
valid_lft forever preferred_lft foreverc-po updated the task description for T2110: RADIUS: supply include file for radius config to have a uniform CLI.
on-demand dialing and VRFs are now mutually exlcusive. As VRF is a new feature of 1.3 this won't break existing 1.2 LTS devices.
c-po changed Is it a breaking change? from behavior to compatible on T2248: PPPoE Broken in Latest 1.3 Rolling (1.3-rolling-202004070629).
GitHub <noreply@github.com> committed rVYOSONEXcbfc9156b371: Merge pull request #321 from jjakob/openvpn-ccd-fix (authored by c-po).
dmbaturin renamed T1821: "authentication mode radius" has no effect for PPPoE server from VyOS - pppoe-server to "authentication mode radius" has no effect for PPPoE server.
c-po added a reverting change for rVYOSONEX2d33cf656f58: vif-s: T2240: add VRF support: rVYOSONEX0eeea79bf084: Revert "vif-s: T2240: add VRF support".
Moved to vif-c
c-po renamed T2240: Support for bind vif-c interfaces into VRFs from Support for bind vif-s interfaces into VRFs to Support for bind vif-c interfaces into VRFs.
Apr 9 2020
Apr 9 2020
syncer changed the status of T2237: l2tp, pptp, pppoe wrong chap-secrets file from Unknown Status to Resolved.
just that the interface can be added to the VRF
GitHub <noreply@github.com> committed rVYOSONEXc0574ed7334c: op-mode: raid: T689: Typo in description (authored by Viacheslav Hletenko <v.gletenko@vyos.io>).
c-po closed T2172: Enable conf VXLAN without remote address, a subtask of T1315: Allow BGP to use address-family l2vpn evpn, as Resolved.
What you mean by "bindable"?
It would appear this commit is the source of the problem - client-config-dir was removed but I don't see anywhere it's re-added.
c-po renamed T2260: vxlan, pseudo-ethernet: convert link nodes to source-interface from Convert link nodes to source-interface to vxlan, pseudo-ethernet: convert link nodes to source-interface.
Thank you @c-po - I can confirm removal of connect-on-demand fixes the problem.
I was under the, obviously mistaken, impression that I needed that command for PPPoE to self-establish on reboot. But I obviously don't as I've just rebooted with the latest 1.3-rolling-202004090909 and it's connected straight away and is working.
c-po changed the status of T2260: vxlan, pseudo-ethernet: convert link nodes to source-interface from Open to In progress.
GitHub <noreply@github.com> committed rVYOSONEX9875a21bdb26: util: T2226: os.system was wrongly converted to run (authored by thomas-mangin).
GitHub <noreply@github.com> committed rVYOSONEXc8a86d3ccee6: Merge pull request #319 from thomas-mangin/T2205 (authored by c-po).
Vrfs are for now not supported in dynamic routing protocols, only static routing is for now possible. Se also comment in T2257
For now only static routing supports vrf, bgp, ospf and rip does not support vrf for time beeing. Support for this is being workes on, but its quite a large rewrite required to add support for this in bgp.
Thanks for the responsiveness to this request!
would it be possible to make both vif-s and vif-c interfaces bindable? or should I make a new feature request?
It let you know ufo could not be changed, but your interface will work :-)
Yes, it is as you have as file in /tmp/vyos.interface.debug' which turns on this debugging :-)
the Problem comes with the connect-on-demand option. As the default route setup was changed some days ago by me to support PPPoE for VRFs this introduced a regression (T2219).