I'm also hitting this issue in 1.4-rolling-202109160217
This task has been kicking around for a while now. What needs to be done to get the code from @ruliane or @elbandi into the rolling build?
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Sep 18 2021
Enabling debugging gives me:
Are there updates on this issue?
Related/Duplicate issue of T3680
It's worth adding the no-default-route to the dhcp-options and adding a line like
Sep 17 2021
Thank you for testing!
Something about commands is meddling with strip-private. I'm looking into it.
Now this is quite strange....
$ echo '2001:1578:2fe:fffd::/64' | strip-private xxxx:xxxx:2fe:fffd::/64
Tested on latest build VyOS 1.4-rolling-202109160217 and confirmed it is adding the remote id attribute by default as expected. Connections establish without issue.
Sep 16 2021
Curl checks come back with:
root@vyos:/tmp# curl 169.254.169.254/latest/meta-data ami-id ami-launch-index ami-manifest-path block-device-mapping/ hostname instance-action instance-id instance-type local-hostname local-ipv4 placement/ public-hostname public-ipv4 public-keys/ reservation-id security-groups
xfrm if_id should not be 0
Sep 15 2021
From https://wiki.strongswan.org/projects/strongswan/wiki/ConnSection (1.3 behavior)
Sep 14 2021
Good shout, fixed in following PR: https://github.com/vyos/vyos-1x/pull/1005
This line doesn't match ipv6 addresses https://github.com/vyos/vyos-1x/blob/f86b7314d025fd0cf11c2d91638ed3cc7c4fa507/src/helpers/strip-private.py#L66
Booted my host with 1.4-rolling-202109140217 and confirmed pfs enabled is now generating the expected swanctl.conf file to match the old behavior. If I don't report back in exactly an hour from now that my tunnels died, we can assume the fix works.
Sep 13 2021
To start the proposed CLI:
Needs to be discussed.
1.3-beta-202109120646 doesn't have any commits from T3821:
Migration scripts are meant for adjusting old configs for a new configuration syntax version. I feel that using that mechanism for fresh installs is wrong and we should move that logic to a different place, ideally to the script that inserts MAC addresses in the config—I forgot which script it is.
Ot feels thos change broke more then it fixed. Can we revert it?
This is because of T3821
Sep 12 2021
Note the version string should be different in 1.3:
Sep 11 2021
Backport to 1.3 is complete. See T3821 for further discussion.
FYI, if your OpenVPN config relies on cert files or anything you uploaded into the config directory, you may need to change the owner to the openvpn user or widen file permissions. Oddly this only seems to affect equuleus, not sagitta (OpenVPN seems fine reading files owned by "root" out of "/config/auth").
Sep 10 2021
Okay, trying to reproduce this. In the meantime, can you please check the behavior with vtysh as restarting bgpd is actually a bad idea.
My gut tells me this might be an FRR issue.
Yes, sure. Here the whole configure (subnets, ips and asns replaced with xxx):
Can you please share your entire config and what to type to reproduce it? Happy to have a look later on.
Tried with latest version, issue still exist. I have that issue since July, some update broke export roue-maps. I have that error message "The route-map 'xxx' does not exist." since then.
Can you please retrst with the latest 1.4? the was a bug related to route-maps in bgpd
Not reproducible in 1.2.8
Change works as expected for me. Thank you!
Setting this to resolved as implementation is almost complete. Please file individual tasks for bugs so we can properly track them in the 1.3 release cycle.
Sep 9 2021
Will be fixed in tomorrows rolling - thanks for reporting this.