@hensur You haven't dealt with this for a long time
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
All Stories
Aug 4 2022
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)