Maintainance release
Details
Sep 12 2019
No, we don't use vyos in production any more, so I can't tell.
Sep 11 2019
Thanks for your response, did you test a newer image already? There was a lot of work done meanwhile.
tried with the first version 1.2, problem was still present. After that, decided to get us a physical router/fw because ipsec would stopped without any obvious reason.
It was a long time ago, almost year and a half...
Sep 10 2019
@mario Did you manage to upgrade to 1.2 and if so, do you still have that issue?
May 25 2019
Seem like this issue still in vyos 1.2. Would please check it and fix it ?
Jan 12 2019
Jan 10 2019
Nov 1 2018
Unfortunately, we not provide any support or bug fixes for 1.1.x series
I will suggest trying 1.2 instead
Oct 19 2018
Hi,
we returned ike-lifetime to AWS specs. Logs above are when we tshoot it.
Oct 17 2018
@mario is your ike-lifetime correct? That looks really short for an aws tunnel.
Otherwise yeah, I'd try with 1.2.
@mario we not going to fix this in 1.1.x
It will be required to retest with 1.2 same config
Don't know, but we are still experiencing this in 1.1.8. The only solution is to restart IPSEC service. The logs are as above.
Oct 15 2018
Oct 13 2018
Can this be reproduced in 1.2?
Oct 3 2018
Aug 29 2018
I am interesting to install and test image in Alibaba cloud.
Aug 15 2018
Jul 18 2018
Jul 17 2018
Jun 23 2018
Jun 22 2018
We are runing VyOS 1.1.8 with AWS tunnels based on AWS provided config.
It's running for months !
Jun 21 2018
Fix applied to current and helium branch (if there will be a 1.1.9 release)
cpo@LR1# set system flow-accounting netflow source-ip 192.168.253.13 [edit] cpo@LR1# show system flow-accounting +netflow { + source-ip 192.168.253.13 +}
This problem exists at least with VyOS 1.2.0-rolling+201806040337 as I've stumbled accross this one, too.
Thanks for reporting @begetan !
@c-po want to look in relevant scripts, I think he is correct and that ipv6 validation likely present in 1.2 too
@dmbaturin see yourself too.
May 27 2018
May 24 2018
May 12 2018
The patch only resolves the issue when an explicit dh-group is defined. The 'pfs enable' option, using ike-group's dh-group still exhibits the issue.
May 4 2018
Which release will include this fix. We are running into the same issue on release 1.1.8.
Mar 7 2018
It was likely the first scenario that I mentioned where there was traffic already established before the NAT rule was created. Also note that a reset conntrack is essentially a flush of the conntrack table and can be disruptive for established connections. Alternatively you could have cleared conntrack entries for the specific host address only as a more safe way of doing it in the future.