PR: https://github.com/vyos/vyatta-cfg-qos/pull/12

Adding priority >=615 should fix it

vyos@r11-roll# sudo cat /opt/vyatta/share/vyatta-cfg/templates/interfaces/ethernet/node.tag/vif/node.tag/redirect/node.def
type: txt
priority: 615
help: Incoming packet redirection destination
allowed: /opt/vyatta/sbin/vyatta-interfaces.pl --show=input

Explanation on how to reproduce this error:

• On fresh install on 1.2.8 (more parameter may be needed to be able to upgrade router):

set interfaces input ifb042
set interfaces ethernet eth0 vif 42 address 203.0.113.47/32
set interfaces ethernet eth0 vif 42 redirect 'ifb042'

Then add and install 1.3.0 vyos image, and reboot.

VyOS 1.4

set interfaces input ifb042
set interfaces ethernet eth0 vif 42 address 203.0.113.47/32
set interfaces ethernet eth0 vif 42 redirect 'ifb042'

Same problem when downgrading from 1.3.0 to 1.2.8

Can confirm the problem.
Also, when bootting on 1.3.0 version, and trying to load pre-migration config file, it's also not possible.
Removing "redirect" entry from pre-migration file, configurations loads correctly.
Once configuration was loaded, "redirect" command con be inserted once again in cli, and it is accepted.

1. Negated ports: erros while writing command.

For example:

Submitted this PR: https://github.com/vyos/vyos-1x/pull/1232

+1

+1

It is used in keepalived Template

PR :https://github.com/vyos/vyos-1x/pull/1228

Dhcp template https://github.com/vyos/vyos-1x/blob/9e626ce7bad2bd846826822a3622fedf2d937e09/data/templates/dhcp-server/dhcpd.conf.tmpl#L45-L47

Install official pkg solve the issue

wget http://ftp.de.debian.org/debian/pool/main/o/ocserv/ocserv_0.12.2-3_amd64.deb
dpkg -i *.deb
`

Can be related
Found out some strange things, client address was banned:

ocserv[2072]: main: added 1 points (total 1) for IP '192.168.122.1' to ban list

I don't see any issues with LTS 1.3.0

Duplicate T1292 was assigned to 1.4 version, and I close it because it was solved.
This bug remains open for 1.3 Equuleus

Solved. New commands:

Task for kea T3316

@sever https://kea.readthedocs.io/en/kea-2.0.1/arm/dhcp4-srv.html#using-a-specific-relay-agent-for-a-subnet

@Viacheslav As I said: every rolling version of VyOS 1.3 branch starting from mid-January. I built ISO several times during this month. Last one I tried today (built today). All of them behave like this in my two different routers. Last time ocserv worked was middle of December build.

Which version?

PR https://github.com/vyos/vyos-1x/pull/1218

Issue not resolved, re-open

Ip address for openvpn is not yet assigned as a priority for OpenVPN less than for HA

460 interfaces/openvpn
800 high-availability

Anf we have checks if address assigned:

set interfaces ethernet eth0 address '10.1.12.1/24'
set high-availability vrrp group FOO interface 'eth0'
set high-availability vrrp group FOO no-preempt
set high-availability vrrp group FOO priority '150'
set high-availability vrrp group FOO rfc3768-compatibility
set high-availability vrrp group FOO virtual-address '203.0.113.1/24'
set high-availability vrrp group FOO vrid '10'

VyOS 1.4-rolling-202201041316 - works well.

@aohanian I got it, thanks, so it doesn't delete the previous route in one commit
it can be archived with 2 commits

configure
delete protocols static route 1.1.1.1/32 dhcp-interface eth4
commit
set protocols static route 1.1.1.1/32 dhcp-interface eth5
commit

The problem in 1.3.0 is that if you delete the next-hop and then use a different next-hop, both next-hops are in the routing table. The next-hop that you deleted is still there:

I think there is a bit of confusion here. nowadays 1.4 it's works as you mention , but 1.3 doesn't remove static (so we can see both static in the RIB) . however, In my personal opinion , it should show both static in our cli (same also on FRR) , because it's possible that you may need a different prefix ,it'll be installed with a different next-hop .

@fernando What do you want to see it that case?
In the our CLI DHCP-route can be as a single value now:

set protocols static route 192.0.2.192/32 dhcp-interface 'eth0'
set protocols static route 192.0.2.192/32 dhcp-interface 'eth2'

I.e. the first route will be replaced with the second route in CLI.
So if I understand correctly you expect that this route will be also replaced an in the FRR?

@jestabro you are right. Adding no_tag_node_value_mangle=True will fix this issue.
https://github.com/vyos/vyos-1x/blob/ec13cac66ba612ecc36053158c7517c8fe993547/src/system/keepalived-fifo.py#L73-L74

self.vrrp_config_dict = conf.get_config_dict(base,
                                     key_mangling=('-', '_'), get_first_key=True,
                                     no_tag_node_value_mangle=True)

Found the problem here - I used a different and simpler version of the configuration above and *show openvpn server* returns an output when a client is connected.

https://github.com/vyos/vyos-1x/pull/1205

I've used for these tests (VyOS 1.4-rolling-202202010836)
The same situation in general when you want to use "!".
Bad exampels.

set nat source rule 10 destination port !1-5
set nat source rule 10 destination port !22
set nat source rule 10 destination port !http
set nat source rule 10 destination port telnet,!http,!123,1001-1005
set nat source rule 10 destination port telnet,http,!123,1001-1005

I have found the following links:

Seems like this is already handled in T4101

Is there any Linux implementation?

I don't know what I'm building. How can I be sure I'm actually building 1.3.0 rather than 1.4? I ask because when I boot off the build I compiled I get the following message at the start of the boot process. Is it 1.3.0 or sagitta (1.4)?

I've checked the same scenario on the cisco router.

Failover is handled by my firewall which is upstream of VyOS which I am using more as a router than anything. The commit you listed I believe is actually the fix for T4206, not for this, but I can certainly try that to see if I'm up and running and to see if the issue I'm reporting here is resolved, since I have only tried this setup in 1.3.0 RC6. I'm not sure why you'd think I'd need " failover with custom hook-scripts" for this issue. All I'm trying to do is have a PBR for traffic with the destination IP of local VyOS interfaces to use the main table rather than the vrf table. I also have an issue where if I ping the IP on the FIOS WAN interface from upstream, the reply traffic from the VyOS is sent downstream to the FiOS gateway, so this fails. However, the VyOS isn't doing that for the WOW! WAN interface, and I get the replies as expected. So it seems there are strange things happening. Either things not being cleaned up and/or not being set up right.

@adestis https://github.com/vyos/vyatta-config-mgmt/tree/equuleus

I could commit a merge request but I have not figured out in which repo the file is located.

@Viacheslav steps to reproduce:

I'm not completely sure that behavior in 1.4 is the correct one.
If I add these two routes:

vyos@vyos# set protocols static route 8.8.8.8/32 dhcp-interface eth0
vyos@vyos# set protocols static route 8.8.8.8/32 dhcp-interface eth1

I would expect to see both in main routing table, as it is in 1.3 version. I would expect that latest command doesn't overwrite previous command, as user may want/need redundancy for that particular route.
So I think that adding routes to main routing table and not overwriting previous entry is the correct behavior.
IMO in 1.3:

• Second route is added and not overwriten in main routing table -- OK
• But in vyos cli, second route overwrites the first one, when both routes should remain present in config --- Not OK

It's good to know that it works as expected on 1.4-rolling. Is it possible to get a fix for 1.3?

We didn't receive the customer's request.
The timers work without problems.
I'll open a design request to see the range 1-99.

I have emulated the same scenario in to vyos VyOS 1.4-rolling-202201041316
And it works well.
{

vyos@vyos:~$ show dhcp client leases
interface  : eth0
ip address : 172.168.32.146     [Active]
subnet mask: 255.255.255.0
domain name: localdomain        [overridden by domain-name set using CLI]
router     : 172.168.32.2
name server: 172.168.32.2
dhcp server: 172.168.32.254
lease time : 1800
last update: Fri Jan 28 01:09:31 UTC 2022
expiry     : Fri Jan 28 01:39:30 UTC 2022
reason     : RENEW

This issue is due to negated source/destination port not being handled properly in code, not validation.

Is it the same task T4138 ?

Try to dump traffic from the required interface