| Age | Commit message (Collapse) | Author |
|---|
|
- allow configuring IPv6 server addresses and push options
- add IPv6 server client IP pool
- add IPv6 push dhcp-option DNS6
- allow configuring IPv6 server client addresses
- allow configuring IPv6 site-to-site addresses
- validate all IPv6 options and addresses
- use protos that explicitely open an IPv6 listening socket
(tcp6-server, tcp6-client, udp6) as the default on Linux listens on
IPv4 only (https://community.openvpn.net/openvpn/ticket/360)
- add validator for any IPv6 address, host or network (used by pool)
|
|
|
|
openvpn: T2235: add custom server pool handling
|
|
- add config options and logic for server client-ip-pool
- add function for determining default IPs for the server in different
configurations
- verify for pool IPs and maximum subnet prefix length
- move remote netmask logic for client ifconfig-push to use new function
- add topology 'net30' , set it as default (as it already was)
- replace generic ip_* with IPv4* where necessary
- print warning to console when server client IP is in server pool
- fix server subnet help field
|
|
|
|
Combining multiple options into a single CLI node is considered bad practice.
IPv6 prefixes consited of the prefix itself and a mask send to the client in
one node only.
The following CLI parts have been migrated from
client-ipv6-pool {
delegate-prefix fc00:0:1::/48,64
prefix 2001:db8::/64,64
}
to
client-ipv6-pool {
delegate fc00:0:1::/48 {
delegation-prefix 48
}
prefix 2001:db8::/48 {
mask 64
}
}
Thus regular validation steps from the VyOS CLI can be used when a prefix is
configured.
|
|
|
|
It makes less sense for the user to specify this behavior.
|
|
There is no reason to distinguish between WINS servers in terms of priority.
This is solely a task which can be done in the underlaying Python scripts.
|
|
There is no reason to distinguish between an IPv4 and IPv6 name-server node
on the CLI - this can be done in the underlaying Python scripts.
|
|
|
|
|
|
|
|
This reverts commit 2d33cf656f5856fb06e8390fc2250bb99ea0206b.
|
|
This is a base requirement for l2vpn evpn. When source-address is configured,
the option "local <source-addr> nolearning" is appended when creating the
interface as mentioned here: https://vincent.bernat.ch/en/blog/2017-vxlan-bgp-evpn
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Restriction of api proxy should be owned by https.py, not http-api.py.
|
|
|
|
VHT flags deal with many variables which depend on antenna count and
supported features. BF-ANTENNA-(2|3|4) and SOUNDING-DIMENSION-(2|3|4)
were not dealt with correctly.
IEEE 802.11ac (VHT) supports at least 1 antenna and up to 8 antennas
at most. The hsotapd VHT flags may support as many but most do not.
Therefore, we need to be picky here...
|
|
|
|
|
|
WireGuard has been the only subsystem combining a remote ip address and a
remote port number into a single node. This is bad as there is no possiblity
for the XML based input validation for IP address and port numbers.
That's the reason the peer endpoint node goets migrated into a peer address
and a peer port node utilizing the embedded syntax node checking for IP
addresses and port ranges.
|
|
|
|
pim: T1729: Add dr-priority and IGMP join support
|
|
|
|
Commits to
"interfaces wireless wlanX capabilities vht link-adaptation (unsolicited|both)"
always failed.
|
|
|
|
VRRP: T1820: Added transition-script support for sync-groups
|
|
|
|
Every VRF that's created is not allowed to be named like any interface that
can be active on the system. This includes eth, lan, br, dum, lo ....
In theoriy this would work but as soon as such a regular interface is created
things will go sideways rather quick thus we limit the namespace which can
be used to create a VRF.
Appending an interface name is still possible like coolvrf-eth0.
|
|
|
|
Every interface on the system can be a member of a bridge - thus the bridge
interface must be the one interface which has the highest priority
compared to all other interfaces - incl. l2tpv3.
With this change the system boots up fine with also l2tpv3 interfaces
participating as bridge members. This change was needed as a l2tpv3 interface
requires proper configured routing oin the system, else adding the
interface will fail miserably:
FileNotFoundError: [Errno 2] ip l2tp add tunnel tunnel_id 200
peer_tunnel_id 100 udp_sport 4000 udp_dport 3000 encap udp
local 172.18.201.10 remote 172.18.203.10
returned: RTNETLINK answers: Network is unreachable
|
|
As L2TPv3 interfaces can be member interface of a bridge device it must be
configured prior to the bridge - else the system will boot with an error as
member adding fails.
|
|
Note: if transition-scripts configured for both vrrp instance and sync group, which are it a member of, both scripts will be executed.
|
|
By default, the HTTP API will be proxied by any nginx virtual server.
Allow specifying a subset of servers to act as proxy.
|
|
... to not cause any issues with buildin tables or PBR. PBR uses table 1 - 200
so there is a small overlap (by intention)
|
|
|
|
|
|
|
|
|
|
Autoconfigure addresses using Prefix Information in Router Advertisements.
|
|
... to new XML and Python based frontend/backend.
|
|
|
|
|
