Age | Commit message (Collapse) | Author |
|
T2044: RPKI doesn't boot properly
|
|
|
|
|
|
|
|
In CLI we can choose authentication logic:
- `mandatory` - if TACACS+ answered with `REJECT`, authentication must be
stopped and access denied immediately.
- `optional` (default) - if TACACS+ answers with `REJECT`, authentication
continues using the next module.
In `mandatory` mode authentication will be stopped only if TACACS+ clearly
answered that access should be denied (no user in TACACS+ database, wrong
password, etc.). If TACACS+ is not available or other errors happen, it will be
skipped and authentication will continue with the next module, like in
`optional` mode.
|
|
T671: do not preserve old tech-support report implementation
|
|
In CLI we can choose authentication logic:
- `mandatory` - if RADIUS answered with `Access-Reject`, authentication must
be stopped and access denied immediately.
- `optional` (default) - if RADIUS answers with `Access-Reject`,
authentication continues using the next module.
In `mandatory` mode authentication will be stopped only if RADIUS clearly
answered that access should be denied (no user in RADIUS database, wrong
password, etc.). If RADIUS is not available or other errors happen, it will be
skipped and authentication will continue with the next module, like in
`optional` mode.
|
|
|
|
T5576: Add BGP remove-private-as all option
|
|
op-mode: T5581: add "show ip nht" command (IPv4 nexthop tracking table)
|
|
vyos@vyos:~$ show ip nht
172.18.254.202
resolved via ospf
via 172.18.201.254, eth0.201 (vrf default), weight 1
Client list: bgp(fd 28)
|
|
|
|
frr: T5239: fix process startup order
|
|
while configuring dNAT|sNAT rule
|
|
Add the ability to use the option all for remove-private-as.
Remove private ASNs in outbound updates.
all - Apply to all AS numbers
set protocols bgp neighbor <tag> address-family ipv4-unicast remove-private-as all
|
|
We need separated groups for RADIUS and TACACS+ system users because they need
to be used in PAM rules independently.
|
|
Now that the caching fixes are in place, we can update the config to
remove legacy treatment of ipv4 related properties.
|
|
T4309: Conntrack ignore fix to handle interface any
|
|
Interface 'any' not expected in nft rules, it means that option
iifname shouldn't exist at all
set system conntrack ignore ipv4 rule 10 inbound-interface 'any'
table ip raw {
chain VYOS_CT_IGNORE {
iifname "any" counter packets 0 bytes 0 notrack comment "ignore-10"
return
}
}
Fix it
|
|
|
|
- Reuse existing utility functions to check if a boot is ongoing
(boot_configuration_complete())
- Run system_frr.py script to configure FRR daemon before initial launch
- Add safety net to always have FRR running on the system
This does yet not solve the error in T5239 but it's a small step towards
the solution.
|
|
|
|
|
|
|
|
|
|
|
|
vxlan: T3700: Revert change to `vyos.utils.process.cmd`
|
|
|
|
T3655: Fix NAT problem with VRF
|
|
Linux netfilter patch https://patchwork.ozlabs.org/project/netfilter-devel/patch/d0f84a97f9c86bec4d537536a26d0150873e640d.1439559328.git.daniel@iogearbox.net/
adds direction support for conntrack zones, which makes it possible to
do NAT with conflicting IP address/port tuples from multiple, isolated tenants on a host.
According to the description of the kernel patch:
> ... overlapping tuples can be made unique with the zone identifier in
original direction, where the NAT engine will then allocate a unique
tuple in the commonly shared default zone for the reply direction.
I did some basic tests in my lab and it worked fine to forward packets
from eth0 to pppoe0.
- eth0 192.168.1.1/24 in VRF red
- pppoe0 dynamic public IP from ISP VRF default
- set vrf name red protocols static route 0.0.0.0/0 interface pppoe0 vrf 'default'
- set protocols static route 192.168.1.0/24 interface eth0 vrf 'red'
`conntrack -L` shows something like:
```
tcp 6 113 ESTABLISHED src=192.168.1.2 dst=1.1.1.1 sport=58946 dport=80 zone-orig=250 packets=6 bytes=391 src=1.1.1.1 dst=<my-public-ip> sport=80 dport=58946 packets=4 bytes=602 [ASSURED] mark=0 helper=tns use=1
```
It would be much appreciated if someone could test this with more
complex VRF setup.
|
|
|
|
T5567: Increase allowed range for maximum-object-size to 1GB for webproxy
|
|
T5564: Fix show firewall group and show firewall summary
|
|
The `rule` key could be not exists in the entry of the dictionary
for examppe `{'default_action': 'drop'}`
Fix it
|
|
T4309: Fix conntrack teamplate group
|
|
|
|
T5518: pim6: Fix smoketests
|
|
|
|
webproxy service
|
|
T5518: Add basic MLD support
|
|
T5562: Cleanup netns for smoketest load-balancing wan
|
|
Cleanup nets for the smoketest load-balancing
Remove deleting container interfaces from default netns as those
interfaces leave inly in netns.
|
|
|
|
The following commands will enable nftables flowtable offload on interfaces eth0 eth1:
```
set firewall global-options flow-offload software interface <name>
set firewall global-options flow-offload hardware interface <name>
```
Generated nftables rules:
```
table inet vyos_offload {
flowtable VYOS_FLOWTABLE_software {
hook ingress priority filter - 1; devices = { eth0, eth1, eth2, eth3 };
counter
}
chain VYOS_OFFLOAD_software {
type filter hook forward priority filter - 1; policy accept;
ct state { established, related } meta l4proto { tcp, udp } flow add @VYOS_FLOWTABLE_software
}
}
```
Use this option to count packets and bytes for each offloaded flow:
```
set system conntrack flow-accounting
```
To verify a connection is offloaded, run
```
cat /proc/net/nf_conntrack|grep OFFLOAD
```
This PR follows firewalld's implementation: https://github.com/firewalld/firewalld/blob/e748b97787d685d0ca93f58e8d4292e87d3f0da6/src/firewall/core/nftables.py#L590
A good introduction to nftables flowtable: https://thermalcircle.de/doku.php?id=blog:linux:flowtables_1_a_netfilter_nftables_fastpath
|
|
container: T5563 Fix environment replaced by label
|
|
FRR supports a new way of configuring VLAN-to-VNI mappings for EVPN-VXLAN, when
working with the Linux kernel. In this new way, the mapping of a VLAN to a VNI
is configured against a container VXLAN interface which is referred to as a
'Single VXLAN device (SVD)'.
Multiple VLAN to VNI mappings can be configured against the same SVD. This
allows for a significant scaling of the number of VNIs since a separate VXLAN
interface is no longer required for each VNI.
Sample configuration of SVD with VLAN to VNI mappings is shown below.
set interfaces bridge br0 member interface vxlan0
set interfaces vxlan vxlan0 external
set interfaces vxlan vxlan0 source-interface 'dum0'
set interfaces vxlan vxlan0 vlan-to-vni 10 vni '10010'
set interfaces vxlan vxlan0 vlan-to-vni 11 vni '10011'
set interfaces vxlan vxlan0 vlan-to-vni 30 vni '10030'
set interfaces vxlan vxlan0 vlan-to-vni 31 vni '10031'
|
|
|
|
T4072: add firewall bridge filtering.
|
|
T5554: Disable sudo for PAM RADIUS
|
|
Revert Sonar "Create build.yml"
|