PR checks if openconnect port is listened by another service https://github.com/vyos/vyos-1x/pull/1460
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Aug 5 2022
It is already present in 1.4
vyos@r14:~$ show conf com | match bgp set protocols bgp listen limit '1000' set protocols bgp listen range 192.0.2.0/24 peer-group 'FOO' set protocols bgp local-as '65001' set protocols bgp peer-group FOO remote-as '65001'
It appeared after this commit
It doesn't like this check https://github.com/vyos/vyos-1x/blob/2a10ffa4b5074be27458159fa94d6227d0e5c7f7/src/op_mode/openconnect-control.py#L63-L65
Check root user https://github.com/vyos/vyos-1x/blob/2a10ffa4b5074be27458159fa94d6227d0e5c7f7/python/vyos/util.py#L625-L626
Aug 4 2022
Would it be an option to instead just add new listen-interface and upstream-interface statements, same as for dhcp-relay6? Then keep interface completely unchanged to avoid breaking weird usages, but add some deprecation notice to the CLI.
Currently thinking on how to implement this.
One option could be:
@hensur You haven't dealt with this for a long time
PR https://github.com/vyos/vyos-1x/pull/1458
Formatted output
vyos@r14:~$ show vpn ipsec sa Connection State Uptime Bytes In/Out Packets In/Out Remote address Remote ID Proposal ------------------------- ------- -------- -------------- ---------------- ---------------- ----------- --------------------------------------- peer_2001-db8--2_tunnel_0 up 9m15s 0B/0B 0/0 2001:db8::2 2001:db8::2 AES_CBC_256/HMAC_SHA2_256_128/MODP_2048 peer_2001-db8--2_tunnel_0 up 24m9s 0B/0B 0/0 2001:db8::2 2001:db8::2 AES_CBC_256/HMAC_SHA2_256_128/MODP_2048 vyos@r14:~$
From the strongswan 5.9.6 changelog:
Actively initiating duplicate CHILD_SAs within the same IKE_SA is now largely prevented. This can happen if trap policies are installed and an IKE_SA with its CHILD_SAs is reestablished (e.g. with break-before-make reauthentication or dpd_action=restart). This does not prevent duplicates if they are initiated by the two peers concurrently.
Aug 3 2022
also it would be good if WLB function will control main routing table, that would help to avoid a lot of confusion with protocols static configuration& WLB function. Current documentation does not telling anything about how exactly protocols static 0.0.0.0/0 route must be set with WLB.
From what I had tested:
1)WLB creates additional routing tables and setting PBR rules
2)without protocols static route 0.0.0.0 with next-hops to every wlb GW local vyos traffic would not work(as would not work traffic to vyos)
It sounds like people prefer jool, and in my personal opinion, if there is a package that is still active up to now, like jool, then jool is probably better. But whatever it is, it's foreign to me
PR https://github.com/vyos/vyos-1x/pull/1457
set nat66 destination rule 10 destination address '2001:db8:1111::/64' set nat66 destination rule 10 inbound-interface 'eth1' set nat66 destination rule 10 source address '!2001:db8::6/127' set nat66 destination rule 10 translation address '2001:db8::444' set nat66 source rule 10 destination prefix '2001:db8::2/128' set nat66 source rule 10 outbound-interface 'eth1' set nat66 source rule 10 source prefix '2001:db8:1111::/64' set nat66 source rule 10 translation address 'masquerade' set nat66 source rule 20 destination prefix '!2001:db8::6/127' set nat66 source rule 20 outbound-interface 'eth1' set nat66 source rule 20 source prefix '2001:db8:1111::/64' set nat66 source rule 20 translation address 'masquerade'
Also I had tried to assign IP addresses directly to wan interfaces to test if it's somehow related to usage of vrrp combined with WLB- it does not work.
Aug 2 2022
PR https://github.com/vyos/vyos-1x/pull/1456
vyos@r14:~$ /usr/libexec/vyos/op_mode/container.py restart --name alp01 Container name "alp01" restarted! vyos@r14:~$ vyos@r14:~$ /usr/libexec/vyos/op_mode/container.py restart --name alp02 Error: no container with name or ID alp02 found: no such container vyos@r14:~$
Hi friends, I'm experiencing what appears to be the same bug. In my case, it's on a redirect on a vif subinterface on a bonding interface. So perhaps bug is not so much about PPPoE interfaces, so much as any interfaces that don't exist before the commit is done.
PR https://github.com/vyos/vyos-1x/pull/1455
curl -k --raw 'https://localhost/graphql' \ -H 'Content-Type: application/json' \ -d '{"query":" {\n ShowVrf (data: {key: \"foo\"}) {\n success\n errors\n data {\n result\n }\n}\n}\n"}'
Getting data:
{"data":{"ShowVrf":{"success":true,"errors":null,"data":{"result":[{"ifname":"foo","operstate":"UP","address":"26:f6:35:05:7e:0a","flags":["NOARP","MASTER","UP","LOWER_UP"]}]}}}}
Works as expected in a recent rolling (e.g. 1.4-rolling-202208021045)
Aug 1 2022
The root issue is wpa_supplicant shipped in Debian does not contain commit https://w1.fi/cgit/hostap/commit/?id=46c635910a724ed14ee9ace549fed9790ed5980b which adds a new configuration file option named:
PR for 1.3 https://github.com/vyos/vyos-1x/pull/1453
@ajgnet If you have a way to limit the dynamic prefix to a known prefix, then using 1:1 NAT66 prefix translation should work (only the host segment is dynamic)
@c-po You haven't replied for a long time, please let me know if you have any other questions
To solve the issue with MTU over DHCP we can use some new options like mtu for example:
set interfaces ethernet eth0 dhcp-options mtu
If vrf not configured:
vyos@r14:~$ /usr/libexec/vyos/op_mode/vrf.py show Traceback (most recent call last): File "/usr/libexec/vyos/op_mode/vrf.py", line 89, in <module> res = vyos.opmode.run(sys.modules[__name__]) File "/usr/lib/python3/dist-packages/vyos/opmode.py", line 118, in run res = func(**args) File "/usr/libexec/vyos/op_mode/vrf.py", line 84, in show return _get_formatted_output(vrf_data) File "/usr/libexec/vyos/op_mode/vrf.py", line 68, in _get_formatted_output state = vrf.get('operstate').lower() AttributeError: 'NoneType' object has no attribute 'lower' vyos@r14:~$