It seems this problem is not caused by IPsec, but it was caused by GRE implementation.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Sep 10 2024
Aug 27 2024
Sep 28 2023
Jul 19 2023
FRR upstream accepted this patch. https://github.com/FRRouting/frr/pull/13140
May 16 2023
In T3655#148609, @bbabich wrote:In T3655#131502, @Viacheslav wrote:I have NAT working with vrf in VyOS 1.4-rolling-202208290458 + custom nat offload
set interfaces ethernet eth0 address '192.168.122.14/24' set interfaces ethernet eth1 address '192.0.2.1/24' set interfaces ethernet eth1 vrf 'foo' set protocols static route 192.0.2.0/24 interface eth1 vrf 'foo' set system conntrack set vrf name foo protocols static route 0.0.0.0/0 next-hop 192.168.122.1 interface 'eth0' set vrf name foo protocols static route 0.0.0.0/0 next-hop 192.168.122.1 vrf 'default' set vrf name foo table '1010'Nftables
root@r14:/home/vyos# cat nat.nft flush ruleset table ip filter { flowtable fastnat { hook ingress priority filter devices = { eth0, eth1 } } chain forward { type filter hook forward priority filter; policy accept; ip protocol { tcp, udp } flow add @fastnat } } table ip nat { chain POSTROUTING { type nat hook postrouting priority srcnat; policy accept; ip saddr 192.0.2.0/24 oif "eth0" snat to 192.168.122.14 persistent } chain PREROUTING { type nat hook prerouting priority dstnat; policy accept; } }Conntrack table
vyos@r14:~$ sudo conntrack -F conntrack v1.4.6 (conntrack-tools): connection tracking table has been emptied. vyos@r14:~$ vyos@r14:~$ sudo conntrack -L tcp 6 431999 ESTABLISHED src=192.168.122.14 dst=192.168.122.1 sport=22 dport=44462 src=192.168.122.1 dst=192.168.122.14 sport=44462 dport=22 [ASSURED] mark=0 use=1 udp 17 src=192.0.2.2 dst=1.1.1.1 sport=33018 dport=53 src=1.1.1.1 dst=192.168.122.14 sport=53 dport=33018 [OFFLOAD] mark=0 use=2 udp 17 src=192.0.2.2 dst=1.1.1.1 sport=37517 dport=53 src=1.1.1.1 dst=192.168.122.14 sport=53 dport=37517 [OFFLOAD] mark=0 use=2 udp 17 src=192.0.2.2 dst=1.1.1.1 sport=59794 dport=53 src=1.1.1.1 dst=192.168.122.14 sport=53 dport=59794 [OFFLOAD] mark=0 use=2 udp 17 src=192.0.2.2 dst=1.1.1.1 sport=39288 dport=53 src=1.1.1.1 dst=192.168.122.14 sport=53 dport=39288 [OFFLOAD] mark=0 use=2 udp 17 src=192.0.2.2 dst=1.1.1.1 sport=39616 dport=53 src=1.1.1.1 dst=192.168.122.14 sport=53 dport=39616 [OFFLOAD] mark=0 use=2 icmp 1 29 src=192.0.2.2 dst=1.1.1.1 type=8 code=0 id=12387 src=1.1.1.1 dst=192.168.122.14 type=0 code=0 id=12387 mark=0 use=1 udp 17 src=192.0.2.2 dst=1.1.1.1 sport=41155 dport=53 src=1.1.1.1 dst=192.168.122.14 sport=53 dport=41155 [OFFLOAD] mark=0 use=2 udp 17 src=192.0.2.2 dst=1.1.1.1 sport=39829 dport=53 src=1.1.1.1 dst=192.168.122.14 sport=53 dport=39829 [OFFLOAD] mark=0 use=2 udp 17 src=192.0.2.2 dst=1.1.1.1 sport=33655 dport=53 src=1.1.1.1 dst=192.168.122.14 sport=53 dport=33655 [OFFLOAD] mark=0 use=2 udp 17 src=192.0.2.2 dst=1.1.1.1 sport=44835 dport=53 src=1.1.1.1 dst=192.168.122.14 sport=53 dport=44835 [OFFLOAD] mark=0 use=2 udp 17 src=192.0.2.2 dst=1.1.1.1 sport=40213 dport=53 src=1.1.1.1 dst=192.168.122.14 sport=53 dport=40213 [OFFLOAD] mark=0 use=2 udp 17 src=192.0.2.2 dst=1.1.1.1 sport=33729 dport=53 src=1.1.1.1 dst=192.168.122.14 sport=53 dport=33729 [OFFLOAD] mark=0 use=2 udp 17 src=192.0.2.2 dst=1.1.1.1 sport=48344 dport=53 src=1.1.1.1 dst=192.168.122.14 sport=53 dport=48344 [OFFLOAD] mark=0 use=2 conntrack v1.4.6 (conntrack-tools): 14 flow entries have been shown. vyos@r14:~$This works for me too on current rolling releases from Jan-2023 to now.
May 12 2023
In T5186#148559, @c-po wrote:Reverted Kernel back to 5.4.234 for upcoming 1.3.3. release.
May 8 2023
On 1.4-rolling-202305080742, speed limit and protocol detection still not worked out correctly too.
In T3655#143947, @fernando wrote:it doesn't seem the same problem as here, this logic that was applied over this version was vrf not on the table . Could you share full configuration ? there is some point over vrfs / vrf default /leaking that are not clear. So I can replicate the scenery and we see what is going on .
In T5116#147654, @Viacheslav wrote:I think the only solution is to use network namespaces
https://docs.strongswan.org/docs/5.9/howtos/nameSpaces.html
Apr 27 2023
Ok, if we merge the patch (backported to frr v8.5), this task can be close.
In T5116#147640, @c-po wrote:Do you know how to tell Linux to use nameservers within a VRF?
What you mean IPSec/OpenVPN "punch a tunnel through a VRF" ? So the underlay should run via a VRF? source-interface binding does not work?
Mar 30 2023
In T5123#145898, @fernando wrote:cool , it could be useful.
Mar 29 2023
In T5123#145870, @fernando wrote:I don't see it as bug , this information can be obtained from OSPF database using LSA or summary:
vyos@cust-pe2:~$ show ip ospf database OSPF Router with ID (1.1.1.1) Router Link States (Area 0.0.0.0) Link ID ADV Router Age Seq# CkSum Link count 1.1.1.1 1.1.1.1 696 0x80000007 0xd2d4 2 10.255.254.2 10.255.254.2 630 0x80000008 0x682a 3 Net Link States (Area 0.0.0.0) Link ID ADV Router Age Seq# CkSum 10.180.3.2 10.255.254.2 640 0x80000004 0x6f0a vyos@cust-pe2:~$ vyos@cust-pe2:~$ vyos@cust-pe2:~$ show ip ospf database router OSPF Router with ID (1.1.1.1) Router Link States (Area 0.0.0.0) LS age: 703 Options: 0x2 : *|-|-|-|-|-|E|- LS Flags: 0x3 Flags: 0x0 LS Type: router-LSA Link State ID: 1.1.1.1 Advertising Router: 1.1.1.1 LS Seq Number: 80000007 Checksum: 0xd2d4 Length: 48 Number of Links: 2 Link connected to: Stub Network (Link ID) Net: 1.1.1.1 (Link Data) Network Mask: 255.255.255.255 Number of TOS metrics: 0 TOS 0 Metric: 1 Link connected to: a Transit Network (Link ID) Designated Router address: 10.180.3.2 (Link Data) Router Interface address: 10.180.3.3 Number of TOS metrics: 0 TOS 0 Metric: 1 LS age: 637 Options: 0x2 : *|-|-|-|-|-|E|- LS Flags: 0x6 Flags: 0x0 LS Type: router-LSA Link State ID: 10.255.254.2 Advertising Router: 10.255.254.2 LS Seq Number: 80000008 Checksum: 0x682a Length: 60 Number of Links: 3 Link connected to: Stub Network (Link ID) Net: 10.255.254.2 (Link Data) Network Mask: 255.255.255.255 Number of TOS metrics: 0 TOS 0 Metric: 1 Link connected to: a Transit Network (Link ID) Designated Router address: 10.180.3.2 (Link Data) Router Interface address: 10.180.3.2 Number of TOS metrics: 0 TOS 0 Metric: 1 Link connected to: Stub Network (Link ID) Net: 172.16.50.0 (Link Data) Network Mask: 255.255.255.0 Number of TOS metrics: 0 TOS 0 Metric: 1also FRR doesn't show the information on that way , so you should use those commands or enable the log .
In T4516#145664, @Viacheslav wrote:
Mar 28 2023
I think it is good to implement a append kernel boot parameter in configuration file. Like mitigations=off to help old platforms to perform well.
Mar 21 2023
Mar 20 2023
Workaround: put these lines to /config/scripts/vyos-postconfig-bootup.script
Mar 16 2023
Mar 16 12:47:29 bsp-asbr2-cm charon-systemd[45036]: authentication of 'domain1' with RSA_EMSA_PKCS1_SHA2_256 successful Mar 16 12:47:29 bsp-asbr2-cm charon[45036]: 14[IKE] <JXNCCT|2> peer supports MOBIKE Mar 16 12:47:29 bsp-asbr2-cm charon-systemd[45036]: peer supports MOBIKE Mar 16 12:47:29 bsp-asbr2-cm charon[45036]: 14[IKE] <JXNCCT|2> authentication of 'domain2' (myself) with RSA_EMSA_PKCS1_SHA2_256 successful Mar 16 12:47:29 bsp-asbr2-cm charon-systemd[45036]: authentication of 'domain2' (myself) with RSA_EMSA_PKCS1_SHA2_256 successful Mar 16 12:47:29 bsp-asbr2-cm charon[45036]: 14[IKE] <JXNCCT|2> IKE_SA JXNCCT[2] established between <pubIP2>[domain2]...<pubIP1>[domain1] Mar 16 12:47:29 bsp-asbr2-cm charon-systemd[45036]: IKE_SA JXNCCT[2] established between <pubIP2>[domain2]...<pubIP1>[domain1] Mar 16 12:47:29 bsp-asbr2-cm charon[45036]: 14[IKE] <JXNCCT|2> scheduling rekeying in 28200s Mar 16 12:47:29 bsp-asbr2-cm charon-systemd[45036]: scheduling rekeying in 28200s Mar 16 12:47:29 bsp-asbr2-cm charon[45036]: 14[IKE] <JXNCCT|2> maximum IKE_SA lifetime 31080s Mar 16 12:47:29 bsp-asbr2-cm charon-systemd[45036]: maximum IKE_SA lifetime 31080s Mar 16 12:47:29 bsp-asbr2-cm charon[45036]: 14[CFG] <JXNCCT|2> selected proposal: ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ Mar 16 12:47:29 bsp-asbr2-cm charon-systemd[45036]: selected proposal: ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ Mar 16 12:47:29 bsp-asbr2-cm charon[45036]: 14[KNL] <JXNCCT|2> received netlink error: Invalid argument (22) Mar 16 12:47:29 bsp-asbr2-cm charon-systemd[45036]: received netlink error: Invalid argument (22) Mar 16 12:47:29 bsp-asbr2-cm charon[45036]: 14[KNL] <JXNCCT|2> unable to install source route for 192.168.127.32 Mar 16 12:47:29 bsp-asbr2-cm charon-systemd[45036]: unable to install source route for 192.168.127.32 Mar 16 12:47:29 bsp-asbr2-cm charon[45036]: 14[IKE] <JXNCCT|2> CHILD_SA JXNCCT-tunnel-1{2} established with SPIs c4ba20f9_i c3ba4340_o and TS 192.168.127.32/32 === 192.168.63.32/32 Mar 16 12:47:29 bsp-asbr2-cm charon-systemd[45036]: CHILD_SA JXNCCT-tunnel-1{2} established with SPIs c4ba20f9_i c3ba4340_o and TS 192.168.127.32/32 === 192.168.63.32/32 Mar 16 12:47:29 bsp-asbr2-cm charon[45036]: 14[ENC] <JXNCCT|2> generating IKE_AUTH response 1 [ IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) ] Mar 16 12:47:29 bsp-asbr2-cm charon-systemd[45036]: generating IKE_AUTH response 1 [ IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) ] Mar 16 12:47:29 bsp-asbr2-cm charon[45036]: 14[NET] <JXNCCT|2> sending packet: from <pubIP2>[4500] to <pubIP1>[4500] (476 bytes) Mar 16 12:47:29 bsp-asbr2-cm charon-systemd[45036]: sending packet: from <pubIP2>[4500] to <pubIP1>[4500] (476 bytes) Mar 16 12:47:59 bsp-asbr2-cm charon[45036]: 06[NET] <JXNCCT|2> received packet: from <pubIP1>[4500] to <pubIP2>[4500] (76 bytes) Mar 16 12:47:59 bsp-asbr2-cm charon-systemd[45036]: received packet: from <pubIP1>[4500] to <pubIP2>[4500] (76 bytes) Mar 16 12:47:59 bsp-asbr2-cm charon[45036]: 06[ENC] <JXNCCT|2> parsed INFORMATIONAL request 2 [ ] Mar 16 12:47:59 bsp-asbr2-cm charon-systemd[45036]: parsed INFORMATIONAL request 2 [ ] Mar 16 12:47:59 bsp-asbr2-cm charon[45036]: 06[ENC] <JXNCCT|2> generating INFORMATIONAL response 2 [ ] Mar 16 12:47:59 bsp-asbr2-cm charon-systemd[45036]: generating INFORMATIONAL response 2 [ ] Mar 16 12:47:59 bsp-asbr2-cm charon[45036]: 06[NET] <JXNCCT|2> sending packet: from <pubIP2>[4500] to <pubIP1>[4500] (76 bytes) Mar 16 12:47:59 bsp-asbr2-cm charon-systemd[45036]: sending packet: from <pubIP2>[4500] to <pubIP1>[4500] (76 bytes)
Mar 7 2023
In T3655#143947, @fernando wrote:it doesn't seem the same problem as here, this logic that was applied over this version was vrf not on the table . Could you share full configuration ? there is some point over vrfs / vrf default /leaking that are not clear. So I can replicate the scenery and we see what is going on .
Mar 4 2023
In T3655#143947, @fernando wrote:it doesn't seem the same problem as here, this logic that was applied over this version was vrf not on the table . Could you share full configuration ? there is some point over vrfs / vrf default /leaking that are not clear. So I can replicate the scenery and we see what is going on .
Mar 3 2023
In T5048#143916, @Viacheslav wrote:As I understand there no percent or auto and it now expects only rate, needs to check
vyos@r14# set qos policy shaper test default bandwidth Possible completions: <number> Bits per second <number>bit Bits per second <number>kbit Kilobits per second <number>mbit Megabits per second <number>gbit Gigabits per second <number>tbit Terabits per second <number>
I don't know why when I set bandwidth from 10k-10mbit/s, the QoS shaper works correctly but when I set to 100mbit/s~600mbit/s, I only get fews of mbit/s or tens of mbit/s. When I set above about 800mbit/s it looks like no limitation at all. When I manually set limit by tc commands, it seems okay.
I don't know why I set a 100mbit/s shaper, but result in lots of retry and 5~10mbit/s speed.
In T5048#143912, @Viacheslav wrote:Try the latest rolling release
I have almost same problem here. Can't NAT between two VRFs correctly. The outgoing packet has been NATed correctly but the incoming packet seems be dropped, can't reach the source, it seems the return packet can't be tracked correctly.
Btw, in this rolling release, OSPF BFD in tunnel doesn't work correctly too.
You can manually modify strongswan's systemd service file to add 'ip vrf exec charond'. But it causes other problem.