- User Since
- Jun 16 2016, 3:15 PM (148 w, 4 d)
Mar 14 2019
is this change only VyOS local interface with dhcp address? Not related to T440 (FQDN peer)?
Jan 24 2019
are you sure, or could it be related to conntrack helper topic in T1141?
Jan 22 2019
look at T1181
Jan 17 2019
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.
Jan 9 2019
Jan 6 2019
I just updated to VyOS-1.2.0-rolling+201901061111 and it seems to be fixed. I only see one tunnel now:
Jan 5 2019
Jan 3 2019
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.
Jan 2 2019
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
The keyboard bug is still there in VyOS-1.2.0-epa2! No keyboard possible in hyper-v virtual machine connection (console)
Dec 21 2018
.184.108.40.206.220.127.116.11.1.2 is IF-MIB::ifDescr
Dec 19 2018
I saw that in earlier versions too, but not in 1.2.0-RC11. Can you please retest on RC11?
Dec 17 2018
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:
Dec 14 2018
tcpdump is available in VyOS for long time.
Dec 6 2018
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
Dec 5 2018
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)
Nov 29 2018
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):
Nov 26 2018
I know. Please don't contact him by phone :-)
maybe contact @c-po for kernel 4.19.4
Nov 25 2018
Nov 24 2018
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.
Nov 7 2018
Ok I see, RC6 is now on kernel 4.19. Very nice!
Nov 6 2018
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)
Oct 31 2018
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 (.18.104.22.168.22.214.171.124.1.1)
Oct 30 2018
Sorry for the mixup of the kernel version numbers in my original post. I corrected it. But good you can reproduce the issue.
Oct 29 2018
tested again on VyOS 1.2.0-rc5 (kernel 4.14.75), same packetloss.
Oct 26 2018
Would 'set service broadcast-relay' be a possibility for that?
Oct 25 2018
just retested with VyOS1.2.0-rc4, same drops.
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:
Oct 24 2018
Jul 1 2018
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!
Jun 28 2018
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:
OID .126.96.36.199.188.8.131.52.1.2 is interface description, here we see content like 'eth0', 'eth1'.
For interface alias it's OID .184.108.40.206.220.127.116.11.1.1.18 from SNMP table ifXTable, this one is empty in VyOS 1.2.0-rolling+201806251824.
Jun 22 2018
I just tested on VyOS 1.2.0-rolling+201806220337 and 'show version' works here. Can you maybe update?
Jun 7 2018
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.
Jun 6 2018
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:
### Autogenerated by snmp.py ###
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?
Jun 5 2018
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):
May 22 2018
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.
May 21 2018
May 20 2018
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?
Apr 20 2018
I have updated to V1.2.0-rolling+201804200337. After that the configuration node 'service dns forwarding' has disappeared from the config tree.
I reconfigured this and the 'listen on'-part is ok now. Thanks for fixing this one Christian.
Apr 19 2018
I just tried. The config tree looks like before:
Apr 3 2018
This Tasks seems to be resolved since kernel 4.14, as the xen netfront bug in kernel is fixed in this version (https://patchwork.kernel.org/patch/9338979/).
I tested with latest nightly on AWS. No packetloss anymore with AES!
Feb 8 2018
I also tried without edit mode like this with same result:
I just tested on VyOS 999.201802080337 with same result:
Nov 27 2017
vyos@vyos-test# ls -al /run total 56 drwxr-xr-x 25 root root 900 Nov 27 21:29 . drwxr-xr-x 1 root root 4096 Nov 24 20:22 .. drwxr-xr-x 2 root root 40 Nov 24 20:23 agentx -rw-r--r-- 1 root root 5 Nov 24 20:22 atd.pid drwxr-xr-x 2 root root 80 Nov 24 20:22 blkid srwxrwx--- 1 root root 0 Nov 27 21:29 charon.ctl -rw-r--r-- 1 root root 6 Nov 27 21:29 charon.pid srwxrwx--- 1 root root 0 Nov 27 21:29 charon.vici -rw-r--r-- 1 root root 5 Nov 24 20:22 crond.pid
that's exactly how i tested before. All other vpn config was done before and is running fine (commit and saved). As soon as i change (set or delete) something at 'vpn ipsec logging log-level' oder vpn ipsec logging log-modes' I get this message:
yes that's the version I tested on
I don't know what other information could be relevant. It's an instance on AWS. Nothing special before. The log-modes are set after the error messages. I can say that. Look at this here:
Nov 26 2017
Nov 19 2017
Thanks Brandon for your findings. IPSec with dynamic peer is no problem in VyOS. We use some of that with x.509 auth. Only VTI with dynamic peer is not allowed by VyOS. Do you know more about VTI and dynamic peer with strongswan on other linux installations (not VyOS)? Is it possible there?
Oct 30 2017
VyOS doesn't allow this configuration variant. You get an appropriate message if you try. In EdgeOS it's the same. I don't know if it's possible in Strongswan V5.3.5.
Sep 4 2017
Jul 28 2017
is your fix already in 'vyos-999.201707272138-amd64.iso'? I get in this version:
Jul 27 2017
I can support this idea. It's quite usual on other routers or firewalls to have global objects, you define once and use it in firewall, nat, policy routing...