| Age | Commit message (Collapse) | Author |
|---|
|
|
|
The code path to handle the ca certificate used for the frontend service
is removed, as there is no way on the XLI to define the CA certificate used
for the frontend service.
|
|
|
|
This fixes (for and ACME generated certificate)
vyos@vyos:~$ show pki certificate vyos fingerprint sha512
Traceback (most recent call last):
File "/usr/libexec/vyos/op_mode/pki.py", line 1081, in <module>
show_certificate_fingerprint(args.certificate, args.fingerprint)
File "/usr/libexec/vyos/op_mode/pki.py", line 934, in show_certificate_fingerprint
print(get_certificate_fingerprint(cert, hash))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/vyos/pki.py", line 76, in get_certificate_fingerprint
fp = cert.fingerprint(hash_algorithm)
^^^^^^^^^^^^^^^^
AttributeError: 'bool' object has no attribute 'fingerprint'
After the fix:
vyos@vyos# run show pki certificate vyos fingerprint sha256
10:2C:EF:2C:DA:7A:EE:C6:D7:8E:53:12:F0:F5:DE:B9:E9:D0:6C:B4:49:1C:8B:70:2B:D9:AF:FC:9B:75:A3:D2
|
|
suricata: T751: Initial support for suricata
|
|
|
|
|
|
|
|
reverse-proxy: T6370: Set custom HTTP headers in reverse-proxy responses
|
|
nat: T6345: source NAT port mapping "fully-random" is superfluous in Kernel >=5.0
|
|
nat66: T6365: remove warnings for negated interface selections by name
|
|
current (#3508)
|
|
>=5.0
random - In kernel 5.0 and newer this is the same as fully-random. In earlier
kernels the port mapping will be randomized using a seeded MD5 hash mix using
source and destination address and destination port.
https://git.netfilter.org/nftables/commit/?id=fbe27464dee4588d906492749251454
|
|
|
|
nat: T6365: remove warnings for negated interface selections by name
|
|
|
|
|
|
|
|
|
|
Add the ability to show port allocation per external or internal address
With huge entries, it is necessary to filter it by specific
external/internal IP address
|
|
T6364: CGNAT drop hard limit that allows only one translation rule
|
|
|
|
Allow to set multiple CGNAT internal pools
```
set nat cgnat pool internal int-01 range '100.64.0.0/28'
set nat cgnat pool internal int-01 range '100.64.222.11-100.64.222.14'
```
|
|
As PoC for CGNAT had a hard limit of using only one translation
rule for one internal pool.
Drop this limit and extend the usage number of the rules.
```
set nat cgnat rule 100 source pool 'int-01'
set nat cgnat rule 100 translation pool 'ext-01'
set nat cgnat rule 120 source pool 'vyos-int-02'
set nat cgnat rule 120 translation pool 'vyos-ext-02'
```
|
|
op mode: T6348: SNAT op-mode fails with flowtable offload entries
|
|
T6358: Container config option to enable host pid
|
|
|
|
|
|
T6350: CGNAT add op-mode to show allocation
|
|
T6351: CGNAT add verification if the pool exists
|
|
|
|
T6347: CGNAT fix error if pool contain dashes in the name
|
|
Add op-mode command `show nat cgnat allocation` to get CGNAT
allocations (internal address, external address, port-range)
|
|
T6335: Add/Update EVPN op commands
|
|
Add verification if the external/internal pools are exists before we
can use them in the source and translation rules
|
|
|
|
Converted completion helpers from python to bash for performance
Previous commit:
Added the following commands:
show evpn
show evpn es
show evpn es <es-id>
show evpn es detail
show evpn es-evi
show evpn es-evi detail
show evpn es-evi vni <num>
show evpn vni
show evpn vni detail
show evpn vni <num>
Updated the following commands:
show evpn access-vlan
show evpn arp-cache
show evpn mac
show evpn next-hops
show evpn rmac
|
|
Added the following commands:
show evpn
show evpn es
show evpn es <es-id>
show evpn es detail
show evpn es-evi
show evpn es-evi detail
show evpn es-evi vni <num>
show evpn vni
show evpn vni detail
show evpn vni <num>
Updated the following commands:
show evpn access-vlan
show evpn arp-cache
show evpn mac
show evpn next-hops
show evpn rmac
|
|
|
|
Remove `service upnp` as it never worked as expected, nft rules do
not integrated and custom patches do not seem like a suitable
solution for now.
Security:
UPnP has been historically associated with security risks due to its automatic
and potentially unauthenticated nature.
UPnP devices might be vulnerable to unauthorized access or exploitation.
|
|
ethernet: T6306: add support for EVPN MH uplink/core tracking
|
|
|
|
T6329: firewall: add a patch for op-mode command <show firewall group>
|
|
|
|
When all the underlay links go down the PE no longer has access to the VxLAN
+overlay.
To prevent blackholing of traffic the server/ES links are protodowned on the PE.
A link can be setup for uplink tracking via the following configuration:
set interfaces ethernet eth0 evpn uplink
|
|
|
|
|
|
|
|
|
|
|
