I think the only solution is to use network namespaces
https://docs.strongswan.org/docs/5.9/howtos/nameSpaces.html

Usernames usually take the following format: abc-1234-12
Passwords are a combination of alphanumeric characters.

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?

Thanks for opening the task; note that Viacheslav had opened
https://vyos.dev/T5185
as well, and the updates on the now fixed issue can be found there. This task can be merged into that one and closed.

Merged and repos updated, so this will be in the next nightly build. Note that for a local build, one will need an updated Docker image for the update to vyos1x-config.

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?

This is a simple bug in the recently introduced configtree node name comparison function; fixed and should be in next rolling.

Do you have users/passwords with specsymbols or not utf-8 or some ascii symbols?

hmmm very strange.... here is my configuration (IP addresses removed):

Could you provide l2tp configuration? show conf com | match l2tp
I cannot reproduce it

vyos@r14:~$ 
vyos@r14:~$ show l2tp-server sessions 
 ifname | username |      ip      | ip6 | ip6-dp |  calling-sid  | rate-limit | state  |  uptime  | rx-bytes | tx-bytes 
--------+----------+--------------+-----+--------+---------------+------------+--------+----------+----------+----------
 l2tp0  | alice    | 100.64.203.0 |     |        | 192.168.122.1 |            | active | 00:00:10 | 246 B    | 208 B
vyos@r14:~$ 
vyos@r14:~$ 
vyos@r14:~$ show version 
Version:          VyOS 1.4-rolling-202304261027
Release train:    current

@Viacheslav It hangs for a while and then eventually the following output:

@joshua.hanley Could you provide the output of the next command?

sudo accel-cmd -p 2004 show sessions

PR with dependencies: https://github.com/vyos/vyos-build/pull/341

PR https://github.com/vyos/vyos-1x/pull/1971

PR (for build): https://github.com/vyos/vyos-build/pull/340

PR: https://github.com/vyos/vyos-build/pull/339

Incorrect modify modify_section: starting search for '^vrf protocols' until '^exit-vrf'

vyos@r14# delete vrf name red vni 
[edit]
vyos@r14# commit
[ vrf name red vni 3000 ]
{'name': {'protocols': {'bgp': {'address_family': {'ipv4_unicast': {'redistribute': {'connected': {}}},
                                                   'l2vpn_evpn': {'advertise': {'ipv4': {'unicast': {}}}}},
                                'system_as': '65001'}},
          'table': '3000'}}
load_configuration: Configuration loaded from FRR daemon zebra
load_configuration:  loaded      0 !
load_configuration:  loaded      1 frr version 8.5
load_configuration:  loaded      2 frr defaults traditional
load_configuration:  loaded      3 hostname debian
load_configuration:  loaded      4 log syslog
load_configuration:  loaded      5 log facility local7
load_configuration:  loaded      6 hostname r14
load_configuration:  loaded      7 service integrated-vtysh-config
load_configuration:  loaded      8 !
load_configuration:  loaded      9 vrf red
load_configuration:  loaded     10  vni 3000
load_configuration:  loaded     11 exit-vrf
load_configuration:  loaded     12 !
load_configuration:  loaded     13 end
modify_section: starting search for '^vrf protocols' until '^exit-vrf'

Two cents from the fields. It will be nice to see vrf aware cg-nat solution, when subscribers from a number of "inside" vrfs NAT'ed into one outside vrf. Of course if that's possible.

Test case above produces:

PR:
https://github.com/vyos/vyos-1x/pull/1970

Merged T5178 into this one; cf. the description there for background of the issue.

PR for equuleus:
https://github.com/vyos/vyos-1x/pull/1969

PR for equuleus:
https://github.com/vyos/vyos-http-api-tools/pull/5

According to nft changelog, this feature is available in 1.0.7 in a much better way:

@Harliff Could you check it? Available in the latest rolling release

vyos@r14# set  protocols failover route 192.0.2.55/32 next-hop 192.168.122.1 check policy 
Possible completions:
   all-available        All targets must be alive
   any-available        Any target must be alive (default)

Hi guys,

This has a simple fix: starlette commit c568b55d set the attribute

Request._form = None

to support use of Request.form() as a context manager. Since we override the Request class for backwards-compatibility support (translation) of form-data requests, we need to check for value, not existence, of the attribute. Adding this fix allows updating FastAPI past 0.91.0.