- User Since
- Aug 3 2017, 1:55 PM (107 w, 1 d)
Unfortunately I can not reproduce this issue
This can be solved using multiple ways:
- add option to the interfaces-bridge.py script to recreate the bridge when triggered externally
- advantage: the conde is already there
- disadvantage: the script can easily grow to a wastebin of code executed from 100 places
- add a dedicated bridge-group-sync.py script which synchronizes the bridge groups and interfaces, called whenever a interface is added to the system (e.g OpenVPN vtun or ethernet vif)
- advantage: code is contained in a dedicated scirpt
- disadvantage: more and more scripts might evolve
- Write a vyos-interfaced which acts as message receiver and will handle tasks as adding/removing IP addresses, adding/removing bridge and bond members
- advantage: most generic and single source
- disadvantage: most complex
If the bridge priority is higher then the ethernet vif this should work out of the box
Wed, Aug 21
Tue, Aug 20
Mon, Aug 19
Backported to crux
Sat, Aug 17
Also the subtask T1524 should be part of this migration script as if the new allow-from node does not exist it should be populated by the current hard-coded addresses of 0.0.0.0/0 and ::/0
Using 1.2-rolling-201908171107 I configured:
set service dns forwarding domain example.com server '172.16.10.1' set service dns forwarding listen-address '172.18.201.10' set service dns forwarding name-server '22.214.171.124'
- OpenVPN site-to-site
This error won't be fixed as the new Python/XML implementation of OpenVPN has been merged into current and will appear in the next rolling release.
Fri, Aug 16
Thu, Aug 15
This is actually invalid. There is no way with the current CLI design to specify the local address node with an optional subnet-mask leaf node.
Wed, Aug 14
Tue, Aug 13
Why not use curl which is inside the image?
Okay. Please test with latest rolling so we can possibly backport this to crux
I have no experience with Q-in-Q but does it even make sense to apply a firewall to the outer side of a Q-in-Q link?