It seems this problem is not caused by IPsec, but it was caused by GRE implementation.

FRR upstream accepted this patch. https://github.com/FRRouting/frr/pull/13140

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.

In T5186#148559, @c-po wrote:

Reverted Kernel back to 5.4.234 for upcoming 1.3.3. release.

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

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?

In T5123#145898, @fernando wrote:

cool , it could be useful.

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: 1

also FRR doesn't show the information on that way , so you should use those commands or enable the log .

In T4516#145664, @Viacheslav wrote:

@diodep There is the task for it T3001

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.

Workaround: put these lines to /config/scripts/vyos-postconfig-bootup.script

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 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 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.