It should have been fixed by https://github.com/vyos/vyos-1x/commit/ff05e2a90edf8af5d7b8ad5c69cae2dd40af2c8d It works for me in post-Sep 01 images and I don't see the error in the latest one, but I'm not sure why it would appear in the Sep 01 image if the commit is from Aug 30.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Sep 6 2019
@nirmal The full fix is a bit more complicated. There are two cases: when it's called from conf mode at commit time, it needs to use the value from the proposed config (that's returnValue). However, in op mode, it also re-generates the config, so your fix would make the send dhcp6.client-id option disappear from the config when a user runs renew dhcpv6 interface .... A full fix needs to handle both cases and use returnEffectiveValue in op mode.
>>> s=""" ... foo { ... bar { ... baz quux foo ... } ... } ... """ >>> import vyos.configtree >>> c = vyos.configtree.ConfigTree(s) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib/python3/dist-packages/vyos/configtree.py", line 167, in __init__ raise ValueError("Failed to parse config: {0}".format(msg)) ValueError: Failed to parse config: Syntax error on line 4, character 14: Invalid syntax.
It was indeed a bug, caused by the same issue as all other subtasks of T1598: lack of proper synchronization.
If it re-appears, please reopen of course.
Disappearing entries should no longer be a problem, but if it re-appears due to a missing case, please reopen.
It's not so much the implementation as I wrote before, it just doesn't seem beneficial. It gets implemented anyway, but I try to understand why a user would like to use that. The private key is by the way no identity and also won't interfere with multiple VPN peers if you are using only one pk. On IP:12345 arrives an encrypted packet, it is simply decrypted using your pk. If it works it's given to your kernel netlink interface as far as I recall and routed there, so no verification of the private key anywhere. If it can't be decrypted, it's discarded. If you have multiple wg interfaces, your 'crypto routing' either allows the traffic to the peer or discards it if it doesn't fit, the private key has nothing to do with that, since the public key of your peer is used to encrypt it. Summary, I still cna't see any benefit having that, which doesn't mean that I won't implement it.
OpenVPN now runs as user openvpn with the above helper script. Please also test this new implementation, it will be in the rolling ISO which is building right now.
Persistent tunnel is a configuration option set interfaces openvpn vtun10 persistent-tunnel
i agree with allowing this.
@hagbard the private key should stay where its generated. But thats not the point. The point @zx2c4 and I are making, is each interface represent a diffrent Identity. There are only some special cases where you would need the same private key on two interface. Useally you would just add all peers that connect with the same publickey to the same interface. You only need a second interface if there is a second identity you want to assume. For example wg01 might be used to connect to your workplace and wg02 to a vpn service. In that case you would want peers in wg01 and wg02 to know you under different identities.
I can confirm this is still a problem in current rolling versions.
Hello @kruisdraad . I trying to reproduce this issue, but without success. Tunnel works.
set interfaces l2tpv3 l2tpeth1010 address '192.168.37.2/27' set interfaces l2tpv3 l2tpeth1010 encapsulation 'ip' set interfaces l2tpv3 l2tpeth1010 local-ip '2001:db8::2' set interfaces l2tpv3 l2tpeth1010 peer-session-id '100' set interfaces l2tpv3 l2tpeth1010 peer-tunnel-id '200' set interfaces l2tpv3 l2tpeth1010 remote-ip '2001:db8::1' set interfaces l2tpv3 l2tpeth1010 session-id '100' set interfaces l2tpv3 l2tpeth1010 tunnel-id '200'
Can you provide show log tail 100 after creating l2tpv3?
Sep 5 2019
I'm able to reproduce this bug.
The same, but on current (jessie):
The above 2 files can be diffed to see where the bug is triggered.
The _filedir function from /usr/share/bash-completion/bash_completion was changed, the offending part is:
reset=$(shopt -po noglob); set -o noglob toks=( $( compgen -d -- "$cur" ) ) eval $reset
when eval is called, it expands to eval 'set -o noglob' which triggers _vyatta_op_run set -o noglob, which chokes on the input.
_vyatta_op_run was set up as alias for "set" in https://github.com/vyos/vyatta-op/blob/66753705b86a3d104dfe127d4dd2b904a54ab404/functions/interpreter/vyatta-op-run#L38
eval alias ${cmd:0:$pos}=\'_vyatta_op_run ${cmd:0:$pos}\'
due to "set" being part of the templates.
So there are 2 issues as I found out, I fixed one so far. `/opt/vyatta/sbin/vyatta-interfaces.pl``` has been fixed, if it's called with a bonding interface it doesn't care about hw-id as long as it's a bond member, otherwise the legacy code just continues as before.
That helps with config changes and a cold boot, reboot however brings in another issue. Before the system goes down it compares mac addresses and sorts them. bond is still active and 2 eth interface have the same mac which confuses `/lib/udev/vyatta_net_name```
/opt/vyatta/sbin/vyatta-interfaces.pl
Has nothing to do with your rewrite, it is the legacy code which sets up the ethernet interfaces. Bond runs first, after that comes ethernet and changes the mac address of the bond member interface and that's the issue.
Huh? Which perl script?
To reproduce:
@c-po vyos config does touch it via a perl script. I have a patch ready today for it.
As the bonding interface has been completely rewritten this should not be an issue as I do not touch underlaying interface MAC addresses
No worries, I checked it out, the issue still persists but is not easily fixable.
Well, it's not so much the technical implementation via cli. The private key gets exposed on the computer you generate it, then you transfer it to the vyos box, now you have a duplicate if the origin is not removed. It creates multiple points where you can get the private key. If you have that key and the connection is not secured via pre-shared key, you can decrypt the traffic easily. Or do i See that completely wrong?
Why not specify the keys or the key file location via CLI like other VPN implementations do it?
Here's the output of set -x redirected to a file when doing "ls <TAB>" as root.
At first glance it seems like a call to "set -o tag" from within a script is interpreted as an argument to the template "set" node somewhere, which causes it to break.
If anyone wants to dig in to vyatta-op, this is a starting point.
@hagbard I no longer have the hardware the issue was found on, or anything else with identical interfaces to bond at the moment.
Sep 4 2019
@zsdc Can you please provide a relevant config snippet? I won't have a system with 400 interfaces, but I try to measure the difference with 4 to see if it exponentially increases the boot time.
@mb300sd can you please test with the latest rolling image and see if the issue still exists?
@zx2c4 The private key stays on the system it is generated in a directory only accessible by the user who created it. Now when you create an interface let's say wg01 with 20 peers set up, you hand out 20 time the same public key and to decrypt the incoming traffic you use the single private key. Now, let's say you create an interface wg02, also with 20 peers. Why would it be better to generate a new key pair for wg02 on the same system and use a new private key just for that interface?
@yun can you check this issue on last rolling release, I think it fixed.
That is great to hear, i will schedule upgrade of our infra soon and add some tunnels on GRE6. Ill report back when i have info
Hello, @kruisdraad!
IP6GRE tunnels are supported in 1.2-rolling-201909041703. You are welcome to test.
You could use quoting like mentioned in T1129.
Rewrite was tested using:
So in conf file should be enabled by default:
iproute /usr/local/sbin/unpriv-ip
persist-tun
As i understand this script only generate conf file, but we need to change init script, add wrapper script and grant sudo access to the openvpn user to exec this wrapper script...
I like the openvpn:openvpn ownership idea