PR https://github.com/vyos/vyos-1x/pull/1445
vyos@r14:~$ show nat destination rules
Rule Source Destination Proto In-Int Translation
------ --------- ------------- ------- -------- -------------
100 0.0.0.0/0 0.0.0.0/0 TCP eth0 192.0.2.40
sport any dport 3389 port 80
380 0.0.0.0/0 203.0.113.5 TCP any 192.0.2.5
sport any dport 443 port 8443
vyos@r14:~$Working as expected in VyOS 1.3.1-S1
Change DUID to IAID_DUAID was in T1470
Not sure which format we should to use
It's applied but masked by another part, looking into it. A brief workaround is to just change the description on br0 and commit - then the bridge vlan is re-created.
@c-po Bug exists after reboot (tested in 1.4)
@Viacheslav can you save your config and reboot?
We have ssmtp, I think we can use it for notifications
There is an example of configuration
Need to test it and come up with a CLI
I don't know if should it be a part of set service event-handler xxx or some new CLI service like set service monitoring notification mail xxx
+1
OpenConfig should be used as a basic YANG model.
If something is missing, add proprietary ones
https://www.openconfig.net/
If "notice" in CLI and documentation is enough, the task can be closed.
Moving in from forwardto prerouting doesn't seem to be a good idea. Filtering in prerouting will also filter local traffic.
Also, as remarked in previous entry, I would try to avoid using marks in mangle, since it may lead to mayor problems/incompatibilities when PBR also present in configuration.
PR https://github.com/vyos/vyos-1x/pull/1443
vyos@r14:~$ show vrf foo
Name State MAC address Flags Interfaces
------ ------- ----------------- ------------------------ ------------
foo up aa:de:40:58:2e:dd noarp,master,up,lower_up eth1.2
vyos@r14:~$
vyos@r14:~$
vyos@r14:~$
vyos@r14:~$ /usr/libexec/vyos/op_mode/vrf.py show --name bar --raw
[
{
"ifname": "bar",
"operstate": "UP",
"address": "ce:c1:4f:e8:dc:9a",
"flags": [
"NOARP",
"MASTER",
"UP",
"LOWER_UP"
]
}
]
vyos@r14:~$PR https://github.com/vyos/vyos-1x/pull/1442
>>> from vyos.util import rc_cmd
>>>
>>> rc_cmd('uname')
(0, 'Linux')
>>>
>>> rc_cmd('ip link show dev fake')
(1, 'Device "fake" does not exist.')
>>>Ex2
>>> rc, command = rc_cmd('ip link show dev eth999')
>>>
>>>
>>> print(rc)
1
>>> print(command)
Device "eth999" does not exist.
>>>True, marking packets can help. I would only be very careful because we use marks a lot for PBR, LB, etc. Not sure if they can conflict with each other. Also, the performance is the question - better to check how marking each packet on an interface affects it.
The reason I set an MTU is because I get the following error when unset:
WARNING: RFC7348 recommends VXLAN tunnels preserve a 1500 byte MTU
VyOS 1.3-stable-202207280515 is not affected and works as expected
vyos@r14:~$ show vpn ipsec sa Connection State Uptime Bytes In/Out Packets In/Out Remote address Remote ID Proposal ------------------------- ------- -------- -------------- ---------------- ---------------- ----------- -------------- peer-192.0.2.2-tunnel-0 up 9s 0B/0B 0/0 192.0.2.2 N/A AES_GCM_16_256 peer-2001:db8::2-tunnel-0 up 9s 0B/0B 0/0 2001:db8::2 N/A AES_GCM_16_256 vyos@r14:~$
SAs
vyos@r14:~$ sudo swanctl -l
peer-2001:db8::2-tunnel-0: #4, ESTABLISHED, IKEv2, bae267e189f183be_i 008bf75c872ced6a_r*
local '2001:db8::1' @ 2001:db8::1[500]
remote '2001:db8::2' @ 2001:db8::2[500]
AES_GCM_16-256/PRF_HMAC_SHA2_256/MODP_2048
established 25s ago, rekeying in 85328s
peer-2001:db8::2-tunnel-0: #3, reqid 1, INSTALLED, TUNNEL, ESP:AES_GCM_16-256
installed 25s ago, rekeying in 28178s, expires in 28775s
in c762627a, 0 bytes, 0 packets
out c2278f63, 0 bytes, 0 packets
local 2001:db8:1111::/64
remote 2001:db8:2222::/64
peer-192.0.2.2-tunnel-0: #3, ESTABLISHED, IKEv2, c923210fb14e11d5_i 2450ab183218d566_r*
local '192.0.2.1' @ 192.0.2.1[500]
remote '192.0.2.2' @ 192.0.2.2[500]
AES_GCM_16-256/PRF_HMAC_SHA2_256/MODP_2048
established 25s ago, rekeying in 85526s
peer-192.0.2.2-tunnel-0: #4, reqid 2, INSTALLED, TUNNEL, ESP:AES_GCM_16-256
installed 25s ago, rekeying in 27722s, expires in 28775s
in c1892b7b, 0 bytes, 0 packets
out c8fbbb2f, 0 bytes, 0 packets
local 100.64.0.0/24
remote 100.64.55.0/24
vyos@r14:~$I have it working between VyOS 1.4-rolling-202207280217 (kernel 5.10.133) and VyOS 1.3-stable-202207280515 (kernel 5.4.205)
Will it work if you replace this https://github.com/vyos/vyos-1x/blob/4168e03721b2a9595de4090fddf1280d39ccce4c/python/vyos/ifconfig/interface.py#L1378-L1379
sudo nano -c +1385 /usr/lib/python3/dist-packages/vyos/ifconfig/interface.py
with:
PR https://github.com/vyos/vyos-1x/pull/1441
vyos@r14:~$ show nat source statistics Rule Packets Bytes Interface ------ --------- ------- ----------- 10 5 380 eth0 20 0 0 any 30 0 0 any 40 0 0 eth0 40 0 0 eth0 vyos@r14:~$
I have no proof now of any obvious negative issues. Moreover, in my personal opinion - if some protocol or interface type requires a default MTU that is not assigned to it by the kernel, this is the problem that should be solved by configuration script for that particular interface.
Is there any chance to fix that ?
The latest version of the demo can be found here:
Tested locally and receive sflow with agent IP of the configured ip/interface/vrf.
Will it affect also tunnels/openvpn/wireguard/vxlan etc?
If you get rid of the default MTU values you get more pain.
I can reproduce it:
Here is my WG config:
set interfaces wireguard wg2 address 'REDACTED_IPV6/64' set interfaces wireguard wg2 peer mypeer address 'REDACTED_IPV4' set interfaces wireguard wg2 peer mypeer allowed-ips '::/0' set interfaces wireguard wg2 peer mypeer persistent-keepalive '60' set interfaces wireguard wg2 peer mypeer port '51820' set interfaces wireguard wg2 peer mypeer public-key 'REDACTED' set interfaces wireguard wg2 private-key 'REDACTED' set interfaces wireguard wg2 vrf 'test'