No, we don't use vyos in production any more, so I can't tell.

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...

@mario Did you manage to upgrade to 1.2 and if so, do you still have that issue?

Seem like this issue still in vyos 1.2. Would please check it and fix it ?

Unfortunately, we not provide any support or bug fixes for 1.1.x series
I will suggest trying 1.2 instead

Hi,
we returned ike-lifetime to AWS specs. Logs above are when we tshoot it.

@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.

Can this be reproduced in 1.2?

I am interesting to install and test image in Alibaba cloud.

We are runing VyOS 1.1.8 with AWS tunnels based on AWS provided config.
It's running for months !

Fix applied to current and helium branch (if there will be a 1.1.9 release)

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.

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.

Which release will include this fix. We are running into the same issue on release 1.1.8.

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.

Thank you for your attention, cause it's router in production at night executed

reset conntrack

I don't know what it was but now all works fine, sorry for the trouble.

I have verified that this is working on 1.1.8 so there might be a configuration or operation issue that is making you see this behavior (I actually have this working in production at scale using over 14,500 rules across 28 chains).

You are right, installing a fresh copy of VyOS 1.1.7 only has:

root@vyos:~# ls -al /usr/lib/openvpn
total 23
drwxr-xr-x  2 root root    70 Feb 17  2016 .
drwxr-xr-x 55 root root  9548 Feb 17  2016 ..
-rw-r--r--  1 root root 11520 Mar  9  2015 openvpn-auth-pam.so
-rw-r--r--  1 root root 10792 Mar  9  2015 openvpn-down-root.so

it´s normally shipped as separate package? (that ldap plugin)

I think that this is a bug that has been resolved in newer versions, but can not confirm.

I will suggest perform testing on 1.2 since we not going to patch 1.1.x line anymore

Hi xrpixer,

So just to be clear,

I finally got to test my final script, and it worked perfectly.

Nice!

@mickvav What's the status of 1.2.0-x? is there a build node\vm\container I can experiment building nDPI support?

I reproduce the same problem on VyOS 1.1.8 on different region - N.Verginia.

After a lot of reinstallation and terminaton we broke Amazon VPS, so I did full test.

@begetan Does creating it with one interface first work for you?
Also, I still need the show version output from the running instance (complete with S/N and UUID) to see if it's the same issue or a different one.

I've did a lot of attempts, and removed old stuff. Anyway I can reproduce it one more time with the same result.
I am configuring 2 interfaces for the virtual router. May be it can be a problem?

@begetan It is the same build that the marketplace team at AWS distributes to all regions. I've just made an instance in Frankfurt and it worked for me.

I face this issue on the new VyOS 1.1.8 AMI in the Frakfurt region. It is working in Seoul region.

Gentlemen, you've forgot to add this fix to the changelog.

@EwaldvanGeffen can you check on that?

This fix didn't seem to make it into 1.1.8 - was it supposed to?

@dmbaturin I tested the new image. I can confirm that the problem is solved.

will state - "fix testing required" work for us?

@S3m1r6 Could you test this image? http://dev.packages.vyos.net/iso/testing/vyos-1.1.8-rc2-amd64.iso I tested loading a config similar to yours (with ingress/egress QoS values added to make sure they get processed) and it works for me.

Not resolved yet. ;)