In T2664#126031, @Viacheslav wrote:

As we have the 1.3 LTS release (where it is fixed) I propose to close it.
It is a big change for 1.2 that we should avoid.

As we have the 1.3 LTS release (where it is fixed) I propose to close it.
It is a big change for 1.2 that we should avoid.

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

I downloaded

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

Output plugins that we use in 1.4

"github.com/influxdata/telegraf/plugins/outputs/azure_data_explorer"
"github.com/influxdata/telegraf/plugins/outputs/influxdb_v2"
"github.com/influxdata/telegraf/plugins/outputs/prometheus_client"
"github.com/influxdata/telegraf/plugins/outputs/http"

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

@c-po I opened https://github.com/vyos/vyos-documentation/pull/805

Feature backport: https://github.com/vyos/vyos-1x/pull/1400

@dsummers I strongly believe we should not publish bleeding edge HEAD revisions and stick bleeding edge releases only.

After doing some research, it appears this is a known bug in PowerDNS Recursor 4.7 (amazing to me).

This feature would be very helpfull for hairpin nat as we can see from the mentions.
Might also be helpfull for ipv6 as well.
I am aware its a different product but edgeos from ubiquiti does something like this (looks to be a managed address group that populates dynamically) for nat and fw:

Confirmed working on "current" branch.

Is anyone else seeing this same problem? It is keeping me from being able to use VyOS in an IPv6-only environment.

OK, I just noticed the merge to "current" branch.

I'd be glad to help test it, but I checked the repos and didn't see where it got merged in?

I think there's still a problem possible with /var/log/messages handling:

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

I re-created a new VM and it is Not reproducing
I closed it

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

Interface virtio

vyos@r1# run show interfaces ethernet eth1 physical 
Settings for eth1:
        Supported ports: [ ]
        Supported link modes:   Not reported
        Supported pause frame use: No
        Supports auto-negotiation: No
        Supported FEC modes: Not reported
        Advertised link modes:  Not reported
        Advertised pause frame use: No
        Advertised auto-negotiation: No
        Advertised FEC modes: Not reported
        Speed: Unknown!
        Duplex: Unknown! (255)
        Port: Other
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: off
        Link detected: yes
Ring parameters for eth1:
Pre-set maximums:
RX:             256
RX Mini:        0
RX Jumbo:       0
TX:             256
Current hardware settings:
RX:             256
RX Mini:        0
RX Jumbo:       0
TX:             256

Confirmed issue, seems to be a problem in rsyslog/logrotate. Possibly related to T4250

In T3933#124952, @sandwichdoge wrote:

@Viacheslav I tested your fix in my environment. The inbound filtering worked as expected after the fix. However it did not work correctly for the case we where we want both inbound and outbound firewalls on a single vrf member interface (or any case that has more than 2 directions on the same interface).

table ip filter {
	chain VYOS_FW_LOCAL {
		type filter hook input priority filter; policy accept;
		oifname "ONE" counter packets 63 bytes 6024 jump NAME_FOO # <<< Problem here, oifname should be eth0, not vrf name
		iifname "ONE" counter packets 63 bytes 6024 jump NAME_FOO
		jump VYOS_POST_FW
	}
...
	chain NAME_FOO {
		ip saddr 8.8.8.8 counter packets 79 bytes 6636 drop comment "FOO-10"
		counter packets 3 bytes 984 return comment "FOO default-action accept"
	}
}

@a.apostoliuk Could you create PR for 1.3?

Pull request for VyOS 1.4

I see that the pull request was accepted. I just tested it with the latest rolling and it seems to work as expected.
Thanks a lot!

Confirmed that issue is resolved.

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

PR for 1.3 https://github.com/vyos/vyos-1x/pull/1392

PR for 1.3 https://github.com/vyos/vyos-1x/pull/1392

Closed
https://github.com/vyos/vyos-1x/pull/1384