I create PR to add this new feature with the syntax to vyos-cli and frr commnads ,
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
Feed All Stories
All Stories
All Stories
Jun 8 2021
Jun 8 2021
c-po added projects to T3605: Allow to set prefer-global for ipv6-next-hop: VyOS 1.3 Equuleus, VyOS 1.4 Sagitta.
c-po moved T3607: [route-map] set ipv6 next-hop prefer-global from Open to Finished on the VyOS 1.4 Sagitta board.
c-po moved T3607: [route-map] set ipv6 next-hop prefer-global from Need Triage to Finished on the VyOS 1.3 Equuleus board.
c-po changed the status of T3289: No description for node "service" conf-mode from Confirmed to In progress.
Jun 7 2021
Jun 7 2021
fernando renamed T3607: [route-map] set ipv6 next-hop prefer-global from [route-mapset ipv6 next-hop prefer-global to [route-map] set ipv6 next-hop prefer-global.
Viacheslav moved T3289: No description for node "service" conf-mode from Open to Finished on the VyOS 1.4 Sagitta board.
Viacheslav changed the status of T3461: OpenConnect Server redundancy check from Unknown Status to Resolved.
Viacheslav added a comment to T2620: Add ipsec peer-name to log to simplifies grepping and troubleshooting.
PR https://github.com/vyos/vyos-build/pull/169
Jun 8 00:59:20 r1-roll ipsec_starter[2373]: charon (2374) started after 400 ms
Jun 8 00:59:20 r1-roll charon: 05[CFG] received stroke: add connection 'peer-192.0.2.2-tunnel-0'
Jun 8 00:59:20 r1-roll charon: 05[CFG] added configuration 'peer-192.0.2.2-tunnel-0'
Jun 8 00:59:20 r1-roll charon: 07[CFG] received stroke: initiate 'peer-192.0.2.2-tunnel-0'
Jun 8 00:59:20 r1-roll charon: 07[IKE] <peer-192.0.2.2-tunnel-0|1> initiating Main Mode IKE_SA peer-192.0.2.2-tunnel-0[1] to 192.0.2.2
Jun 8 00:59:20 r1-roll charon: 07[ENC] <peer-192.0.2.2-tunnel-0|1> generating ID_PROT request 0 [ SA V V V V V ]
Jun 8 00:59:20 r1-roll charon: 07[NET] <peer-192.0.2.2-tunnel-0|1> sending packet: from 192.0.2.1[500] to 192.0.2.2[500] (180 bytes)
Jun 8 00:59:20 r1-roll charon: 09[NET] <peer-192.0.2.2-tunnel-0|1> received packet: from 192.0.2.2[500] to 192.0.2.1[500] (160 bytes)
Jun 8 00:59:20 r1-roll charon: 09[ENC] <peer-192.0.2.2-tunnel-0|1> parsed ID_PROT response 0 [ SA V V V V ]
Jun 8 00:59:20 r1-roll charon: 09[IKE] <peer-192.0.2.2-tunnel-0|1> received XAuth vendor ID
Jun 8 00:59:20 r1-roll charon: 09[IKE] <peer-192.0.2.2-tunnel-0|1> received DPD vendor ID
Jun 8 00:59:20 r1-roll charon: 09[IKE] <peer-192.0.2.2-tunnel-0|1> received FRAGMENTATION vendor ID
Jun 8 00:59:20 r1-roll charon: 09[IKE] <peer-192.0.2.2-tunnel-0|1> received NAT-T (RFC 3947) vendor ID
Jun 8 00:59:20 r1-roll charon: 09[CFG] <peer-192.0.2.2-tunnel-0|1> selected proposal: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
Jun 8 00:59:20 r1-roll charon: 09[ENC] <peer-192.0.2.2-tunnel-0|1> generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
Jun 8 00:59:20 r1-roll charon: 09[NET] <peer-192.0.2.2-tunnel-0|1> sending packet: from 192.0.2.1[500] to 192.0.2.2[500] (244 bytes)
Jun 8 00:59:20 r1-roll charon: 10[NET] <peer-192.0.2.2-tunnel-0|1> received packet: from 192.0.2.2[500] to 192.0.2.1[500] (244 bytes)
Jun 8 00:59:20 r1-roll charon: 10[ENC] <peer-192.0.2.2-tunnel-0|1> parsed ID_PROT response 0 [ KE No NAT-D NAT-D ]
Jun 8 00:59:20 r1-roll charon: 10[ENC] <peer-192.0.2.2-tunnel-0|1> generating ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ]
Jun 8 00:59:20 r1-roll charon: 10[NET] <peer-192.0.2.2-tunnel-0|1> sending packet: from 192.0.2.1[500] to 192.0.2.2[500] (108 bytes)
Jun 8 00:59:20 r1-roll charon: 11[NET] <peer-192.0.2.2-tunnel-0|1> received packet: from 192.0.2.2[500] to 192.0.2.1[500] (76 bytes)
Jun 8 00:59:20 r1-roll charon: 11[ENC] <peer-192.0.2.2-tunnel-0|1> parsed ID_PROT response 0 [ ID HASH ]
Jun 8 00:59:20 r1-roll charon: 11[IKE] <peer-192.0.2.2-tunnel-0|1> IKE_SA peer-192.0.2.2-tunnel-0[1] established between 192.0.2.1[192.0.2.1]...192.0.2.2[192.0.2.2]
Jun 8 00:59:20 r1-roll charon: 11[IKE] <peer-192.0.2.2-tunnel-0|1> scheduling rekeying in 2720s
Jun 8 00:59:20 r1-roll charon: 11[IKE] <peer-192.0.2.2-tunnel-0|1> maximum IKE_SA lifetime 3260s
Jun 8 00:59:20 r1-roll charon: 11[ENC] <peer-192.0.2.2-tunnel-0|1> generating QUICK_MODE request 3783917425 [ HASH SA No KE ID ID ]
Jun 8 00:59:20 r1-roll charon: 11[NET] <peer-192.0.2.2-tunnel-0|1> sending packet: from 192.0.2.1[500] to 192.0.2.2[500] (316 bytes)
Jun 8 00:59:20 r1-roll charon: 12[NET] <peer-192.0.2.2-tunnel-0|1> received packet: from 192.0.2.2[500] to 192.0.2.1[500] (316 bytes)
Jun 8 00:59:20 r1-roll charon: 12[ENC] <peer-192.0.2.2-tunnel-0|1> parsed QUICK_MODE response 3783917425 [ HASH SA No KE ID ID ]
Jun 8 00:59:20 r1-roll charon: 12[CFG] <peer-192.0.2.2-tunnel-0|1> selected proposal: ESP:AES_CBC_256/HMAC_SHA1_96/MODP_1024/NO_EXT_SEQ
Jun 8 00:59:20 r1-roll charon: 12[IKE] <peer-192.0.2.2-tunnel-0|1> CHILD_SA peer-192.0.2.2-tunnel-0{1} established with SPIs c4d940b7_i c9a69e83_o and TS 10.1.0.0/24 === 10.2.3.0/24
Jun 8 00:59:20 r1-roll charon: 12[ENC] <peer-192.0.2.2-tunnel-0|1> generating QUICK_MODE request 3783917425 [ HASH ]
Jun 8 00:59:20 r1-roll charon: 12[NET] <peer-192.0.2.2-tunnel-0|1> sending packet: from 192.0.2.1[500] to 192.0.2.2[500] (60 bytes)trae32566 updated the task description for T3604: Changing BGP Neighbor Peer-Group Association Causes Routing Subsystem Failure.
This is indeed fixed!
Viacheslav closed T3358: VRRP: Is it necessary to support switches between master and backup with script? as Invalid.
@arvin This functions in all versions of VyOS.
Viacheslav changed the subtype of T2763: New SNMP resource request - SNMP over TCP from "Task" to "Feature Request".
I can't reproduce it in 1.2.7 and VyOS 1.3-beta-202105272051
@jingyun Can you describe steps on how to reproduce it? Or re-check it.
My test config after reboot works fine
set interfaces bridge br0 member interface tun0 set interfaces tunnel tun0 encapsulation 'gre-bridge' set interfaces tunnel tun0 local-ip '100.64.0.1' set interfaces tunnel tun0 remote-ip '100.64.0.254'
Viacheslav moved T3138: ddclient improperly updated when apply rfc2136 config from Open to Backport Candidates on the VyOS 1.4 Sagitta board.
c-po updated the task description for T3588: IPSec: migrate no longer available options from CLI which are now hardcoded/enabled in strongSwan.
Viacheslav changed the status of T3602: Renaming BGP Peer Groups Leaves Router Broken, a subtask of T3182: Main blocker Task for FRR 7.4/7.5 series update, from Open to Needs testing.
Viacheslav changed the status of T3602: Renaming BGP Peer Groups Leaves Router Broken from Open to Needs testing.
sarthurdev <965089+sarthurdev@users.noreply.github.com> committed rVYOSONEX05b5cd0d8c11: nhrp: T3599: Update config path to new /run directory.
GitHub <noreply@github.com> committed rVYOSONEX84ec8b75c190: Merge pull request #868 from sarthurdev/current (authored by c-po).
In the crux.
set system conntrack timeout custom rule 10 destination address '203.0.113.74' set system conntrack timeout custom rule 10 destination port '80' set system conntrack timeout custom rule 10 protocol tcp established '300' set system conntrack timeout custom rule 10 source address '192.0.2.168'
commit
vyos@r2-lts# commit [ system conntrack hash-size 32768 ] Updated conntrack hash size. This change will take affect when the system is rebooted.
It looks like your assessment is correct. It also seems like next-hop IP would be sufficient as well if I wasn't dealing with dynamic WAN IPs. For the moment I'm sticking with interface instead of dhcp-interface. The related issue you sent seems exactly related to this.
sarthurdev added a comment to T3588: IPSec: migrate no longer available options from CLI which are now hardcoded/enabled in strongSwan.
Clarifying as requested by c-po:
I believe I have found out why modification/deletion of rules fails. This is the rule definition in iptables:
Jun 6 2021
Jun 6 2021
I think it is also related https://phabricator.vyos.net/T3522
I have checked that functionality , i can replicate the issues .although there is a workaround if you "set protocols static table 11 route 0.0.0.0/0 dhcp-interface " any interfaces , it doesn't see in your table ( table 10 /11 ) we can see theses routes in the default table , let me show :
c-po closed T842: Adopt VyOS CLI to latest StrongSwan options and deprecated Keywords, a subtask of T2816: Rewrite IPsec scripts with the new XML/Python approach, as Resolved.
c-po updated the task description for T3588: IPSec: migrate no longer available options from CLI which are now hardcoded/enabled in strongSwan.
GitHub <noreply@github.com> committed rVYOSONEXf0bceeeb67e0: Merge pull request #846 from erkin/current (authored by c-po).
UnicronNL triaged T3601: Error in ssh keys for vmware cloud-init if ssh keys is left empty. as Normal priority.
c-po updated the task description for T3588: IPSec: migrate no longer available options from CLI which are now hardcoded/enabled in strongSwan.
sarthurdev <965089+sarthurdev@users.noreply.github.com> committed rVYOSONEXb3bce6497cc2: nhrp: T3599: Migrate NHRP to XML/Python.
sarthurdev <965089+sarthurdev@users.noreply.github.com> committed rVYOSONEX68e5ca6b56b2: nhrp: T3599: Remove vpn_ipsec.py from configd until bug is resolved.
GitHub <noreply@github.com> committed rVYOSONEXf9c142bab451: Merge pull request #865 from sarthurdev/current (authored by c-po).
Jun 5 2021
Jun 5 2021
sarthurdev <965089+sarthurdev@users.noreply.github.com> committed rVYOSONEXa7ca03799105: ipsec: T2816: Fix typo from refactor.
GitHub <noreply@github.com> committed rVYOSONEX71313fb44520: Merge pull request #866 from sarthurdev/fix-ipsec (authored by c-po).
Jun 4 2021
Jun 4 2021
sarthurdev changed the status of T3599: Migrate NHRP to XML/Python from In progress to Needs testing.
Hi @francis the latest FRR version lacks support for Cisco authentication https://github.com/FRRouting/frr/blob/master/nhrpd/nhrp_peer.c#L1212
c-po closed T3595: Cannot create new VTI interface, a subtask of T2816: Rewrite IPsec scripts with the new XML/Python approach, as Resolved.
c-po updated the task description for T3588: IPSec: migrate no longer available options from CLI which are now hardcoded/enabled in strongSwan.
@c-po with this merge on FRR https://github.com/FRRouting/frr/pull/8153#event-4589485067 is migration possible? Possibly related to https://phabricator.vyos.net/T2326
I wonder why this is flagged only as refactoring bit you open an entire new CLI tree.
PR draft: https://github.com/vyos/vyos-1x/pull/863
c-po renamed T3318: Update Linux Kernel to v5.4.208 / 5.10.142 from Update Linux Kernel to v5.4.123 / 5.10.41 to Update Linux Kernel to v5.4.124 / 5.10.42.
c-po moved T3195: Add support for cisco style GRE keepalives from Open to Backlog on the VyOS 1.4 Sagitta board.
c-po changed the status of T3195: Add support for cisco style GRE keepalives from Open to Needs testing.