Since 1.3 is EOL now, I'm marking this wontfix. Feel free to reopen if it turns out to be reproducible in later, still-supported versions.

The 1.3.x is mostly EOL.
We are not expecting any fixes here. Check config/firewall/so on
Consider updating to a more recent 1.4.x version.

Is it reproducible in 1.4 or later? 1.3 will EOL very soon, so if it's unique to 1.3, we may mark this wontfix.

In T6996#211364, @Viacheslav wrote:

The 1.3.x is deprecated; I'm not expecting any fixes here.

The 1.3.x is deprecated; I'm not expecting any fixes here.

Ref earlier task T5188

I've checked on 1.4.0 and BGP session is stable

I'm not sure if you've fully read what I've explained, but this is a regular GRE (IPv4 over IPv6) Tunnel configured in VYOS and in the Huawei Routers. The communication doesn't works in this specific case. If we do VYOS to VYOS then everything is alright. But VYOS to Huawei is not working at all.

please , read the guidelines on this post . it doesn't see a bug if not a support task:

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

It is not a bug with the VyOS itself.
You don't need to create the task on Phabricator
Feel free to create a PR without the task https://github.com/vyos/vyos-documentation/tree/equuleus

Personally I dont think its a good idea to be able to use VyOS as a jumphost towards victims of scanning.

ok, i'll change a port list and nmap scenario

I'm not sure that a list of ports will be helpful in this way.
From time to time, we need to scan specific ports.
What about

force scan-port-host <x.x.x.x> proto <tcp|udp> port '8080-8081,9200'
force port--discovery-host <x.x.x.x> proto <tcp|udp> port '8080'
force port-scan host <x.x.x.x> proto <tcp|udp> port '8080'

And use native nmap binaries (as python3 nmap module is not installed by default)
Also, it has XML format if you want a custom table:

sudo nmap -oX - 127.0.0.1

@sever what do you think about it?

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

In T6108#179246, @Viacheslav wrote:

There is no 1.3.7 version ;)

There is no 1.3.7 version ;)

The issue persists in 1.3.4 too from what I have tested.

1.3.3 and rolling from 2020?

I can reproduce this on VyOS 1.4.0-rc3. It also appears that IPv6 addresses are only garbled on subinterfaces.

PR for 1.4 https://github.com/vyos/vyos-1x/pull/2810

PR for 1.5 https://github.com/vyos/vyos-1x/pull/2809

Sorry maybe I’m not understanding you. The address you’ve highlighted isn’t valid in any case (it only has 6 segments). At the very best it should look like 2602:fcad:2:fffe:5054:ff:XXXX:XXXX (with eight segments). 2602:fcad:2:fffe::/64 is a valid prefix on our network, but there would need to be another 4 segments at the end for SLAAC assigned addresses (which is how that particular address is being assigned). I’d need to look deeper into what the correct address should be, which is why we provided the iperf3 example given the shorter / defined host addresses (with the hope that someone else smarter than me might see the pattern of how the addresses are being mangled). Thanks.

Yes but "2602:fcad:2:fffe:5054:ff" is a valid host in your case?

Hmm, I also just realized the SRC_PORT and DST_PORT are 0 in both the IPv4 and IPv6 flows (also seen in the first example).

No -- I don't believe that's a valid IPv6 address. We just ran some iperf3 tests between two servers on our network 2602:fcad:1::12 <-> 2602:fcad:1:ffff::ffff. Here's what showed up in nfdump (our Netflow collector). I'm not seeing an obvious pattern on how the addresses are being mangled.

You mean that for SRC_IP you expect it to be "2602:fcad:2:fffe:5054:ff" and not "14d:63f:2602:fcad:2:fffe:5054:ff" ?

PR for 1.5: https://github.com/vyos/vyos-build/pull/469

KeyboardInterrupt is caught with an appropriate error message now.