I tested https://phabricator.vyos.net/T1787 for @c-po with the following results. He asked me to write down this here in the parent task.

600MB

that's really strange. As I can reproduce the problem on both intances in 100% of the cases. But not the same config and not the same inital VyOS version.
Can I do some troubleshooting steps for you?
I can also give you the vhd, but on a private channel if possible (is it possible on slack?)

1vCPU, 512MB RAM

with vyos-1.2-rolling-201908270337-amd64.iso also fixed for me. Thanks

I just tested again.
Running on rolling VyOS-1.2-201908130337, same config as before, recursor.conf is ok.
Updated VyOS to rolling VyOS-1.2-201908190337, reboot, check recursor.conf. The domain forwarding is missing.
Reboot again, it's back in the recursor.conf.

@c-po
I have some new findings. When I upgrade to a new rolling release (tested with the one from 11.08.2019 and 12.08.2019), I do 'add system image ...', then reboot, then the forwarders are missing in recursor.conf:

"cheat link here"
I tested and it works for me as expected. I also have a test record on the internal DNS server not in name space '.intern', so I checked everything not '.intern' goes to the DNS server 1.1.1.1. It seems the more specific wins.

strange, I just have to reboot again with same software version and now it looks good!!

I tested again with vyos-1.2.0-rolling+201907141109 but in recursor.conf the domain forwarding is missing (VyOS config is the same as in tests before):

test config looks like this:

It worked as it looked like this:

recursor.conf looks like this:

The problem is back in 1.2.0-rolling+201907110337 :-(
The line with the forwarders in recursor.conf is missing again.
@c-po
How can I reopen this task here?

I just tested with a split dns config (so I can exlude the internal DNS server has resolved the external domain name I used for the test). It works again!

I supposed something like that :-) I will test and report

in vyos-1.2.0-rolling+201907031336 now the dns forwarding domain entries are completely missing in recursor.conf:

in vyos-1.2.0-rolling+201906250337 dns forwarding domain doesn't work. Only the nameserver from 'name-server' are used.
In /etc/powerdns/recursor.conf it lokks like this now:

I can't see 'unknown command' lines in log anymore, on VyOS 1.2.0-rolling"201905180337.

@c-po thanks for that. I changed my configs from postconfig script to new config syntax

thanks Kim

@UnicronNL Yes, exactly that is what is discussed in T440.

is this change only VyOS local interface with dhcp address? Not related to T440 (FQDN peer)?

are you sure, or could it be related to conntrack helper topic in T1141?

look at T1181

I just tested with 1.2.0-EPA3 and it works! So the fix is included. Thanks c-po

I just tested this on 1.2.0-EPA3 and it works here. Please re-test with EPA3.

Maybe the same as in T1119. T1119 is fixed in my tests since VyOS-1.2.0-rolling+201901061111. Can you test again with latest rolling?

I just updated to VyOS-1.2.0-rolling+201901061111 and it seems to be fixed. I only see one tunnel now:

I tested on VyOS-1.2.0-rolling+201901030337 and the keyboard works in console on Win2012R2. As it already worked in older rolling releases I really hope it goes in EPA3.

I will test tomorrow on a Win2012R2 host

I can confirm, it works in VyOS-1.2.0-EPA2

I can confirm, it's fixed in VyOS-1.2.0-EPA2

@dmbaturin :
The keyboard bug is still there in VyOS-1.2.0-epa2! No keyboard possible in hyper-v virtual machine connection (console)

.1.3.6.1.2.1.2.2.1.2 is IF-MIB::ifDescr

I saw that in earlier versions too, but not in 1.2.0-RC11. Can you please retest on RC11?

I see maybe the same on VyOS 1.2.0-rolling+201812162050 with MMS clamping on a GRE interface.

in VyOS 1.2.0-rolling+201812162050 the bug is still existing, but I will test in next RC here.

On which version of VyOS you are? In older versions the syntax was different:

tcpdump is available in VyOS for long time.

:-)

all these commands show the same output:
show vpn ipsec sa
show vpn ipsec sa verbose
show vpn debug
sudo ipsec statusall

@syncer is it really finished for you? The bug is still there in my tests

I just tested "show vpn ipsec sa" on latest rolling (vyos-1.2.0-rolling+201812050337) and get exactly the output of "sudo ipsec statusall"

In 1.2.0-rc10 the keyboard bug is still there as in RC9. No keyboard in hyper-v virtual machine connection. Latest rolling is ok (vyos-1.2.0-rolling+201812050337)

I just made a few first tests with VyOS 1.2.0-rolling+201811281529 and VyOS 1.2.0-RC9 (downloaded now) on Hyper-V 2012R2 (Generation 2 VM, SecureBoot off):

I know. Please don't contact him by phone :-)

maybe contact @c-po for kernel 4.19.4

IPsec config:

I would remove the user engineid. I can't see any useful benefit.

in VyOS 1.2.0-rolling+201811240337 I get no proposals and no traffic in 'show vpn ipsec sa':

I just retested on VyOS 1.2.0-rolling+201811240337. Problem is gone.

also tried the same on VyOS 1.2.0-rolling+201811240337, it's ok.

Ok I see, RC6 is now on kernel 4.19. Very nice!

I saw the change to kernel 4.19.0 (LTS) in VyOS-1.2.0-rolling+201811061700. Just updated to this version and tested again. The packetloss is gone again in this version (same as with kernel 4.18.x)! Tested with mtr and PING (small packets).

any new findings in this case? I also searched on the internet with no solution yet (beside kernel version 4.18.x)

I made a few further tests. These errors occure in log every 5min. That's the routing-table refresh intervall of the network monitoring system. I deactivated encryption of snmp and captured the traffic in these moments. Now I can reproduce this by a snmpwalk to OID .iso.org.dod.internet.mgmt.mib-2.ip.ipRouteTable.ipRouteEntry.ipRouteDest (.1.3.6.1.2.1.4.21.1.1)

Sorry for the mixup of the kernel version numbers in my original post. I corrected it. But good you can reproduce the issue.

tested again on VyOS 1.2.0-rc5 (kernel 4.14.75), same packetloss.

Would 'set service broadcast-relay' be a possibility for that?

just retested with VyOS1.2.0-rc4, same drops.

VyoS:
t2.nano (only little network traffic in this VPC and no such problems with 4.18 kernel versions)

I also made 2 tcpdumps, one on eth0 (pulic interface) and on on eth1 (private interface) with VyOS 1.2.0-rc3 (kernel 4.14.65).

I retested on 1.2.0-rolling-201810240337, the same log:

I just tested with VyOS-1.2.0-rolling+201807010337. I deleted my SNMPv3 config completely and set it again.

@c-po . I just tested on VyOS-1.2.0-rolling+201807010337. And it's fixed! My network monitoring can read the ifalias over SNMP. Thanks for fixing!

@hagbard :
Sorry for the misunderstanding. I checked on an old openSUSE box. but after that the SNMP OID was still empty.
On latest VyOS rolling release I get with 'cat /sys/class/net/eth0/ifalias' the description from 'set interfaces ethernet eth0 description TEST'.
I also saw on EdgeOS (Ubiquiti) the OID is working, I get the interface descriptions. Maybe that helps.

I just set alias on another linux system 'ip link set dev eth0 alias TEST', now I can see the alias with 'ip link show eth0', but nothing in the SNMP OID. Here an old discussion in net-snmp project:
https://sourceforge.net/p/net-snmp/feature-requests/185/

OID .1.3.6.1.2.1.2.2.1.2 is interface description, here we see content like 'eth0', 'eth1'.
For interface alias it's OID .1.3.6.1.2.1.31.1.1.1.18 from SNMP table ifXTable, this one is empty in VyOS 1.2.0-rolling+201806251824.

I just tested on VyOS 1.2.0-rolling+201806220337 and 'show version' works here. Can you maybe update?

ok thanks for your work and explanations

I tested update from vyos-1.2.0-rolling+201806060337 to vyos-1.2.0-rolling+201806070337, went fine.
Then I tested update from vyos-1.2.0-rolling+201806040337 to vyos-1.2.0-rolling+201806070337, went fine too , even without 'listen-address'.
Looks good. Only the truncated encrypted-key in privacy is still there.

ok if you need tests or info, please ask

then I deleted the encrypted-keys, set plaintext keys, commit, show config shows encrypted-keys (the privacy key again truncated), and snmpwalk works now. So it is a migration problem if someone just updates his router to rolling version from today.

i set this, got the following messages:

Yes is running:

I have updated from VyOS-1.2.0-rolling+201806040337 to VyOS-1.2.0-rolling+201806060337 with the same config (the one I sent you before). But now I cannot get SNMP info from this VyOS installation anymore (timeout).
What can I test next?

I think I set it in an older VyOS version by "set service snmp v3 user nms auth plaintext-key blabla" and VyOS encrypted the key.
I changed now to plaintext-key as in your config in newest build with the same negative result.

I just tested vyos-1.2.0-rolling+201806050337 with this config (same as in the past worked):

I see the same messages in EdgeOS 1.10.3 if that helps

in VyOS-1.2.0-rolling+201805220337 with latest strongsSwan only one deprecated keyword is remaining:

I see the same lines still in log on VyOS-1.2.0-rolling+201805220337 as @c-po .
In filesystem there is no directory '/etc/lldpd.conf' but there is a '/etc/lldpd.d' and a file '/etc/init.d/lldpd.conf'

I just tested this one again in VyOS-1.2.0-rolling+201805220337. Setting IPSec log-modes works! commit without errors. Maybe fixed by update to latest strongSwan version.

I have running VyOS-1.2.0-rolling+201805210337 with working SNMPv3.

are there any new possibilities with the new kernel 4.14 and strongswan 5.6.2 in V1.2.0-rolling for this case here?