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

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

A simple work around could be to trigger a podman start command when a restart container $CONTAINER_NAME is entered. If the pod isnt already running or in a stopped state, it will look at the config and start it up.

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

Any update on this, since it's been more than 2 years since the initial request? This would indeed be very useful for hairpin NAT. It it complicated to implement?

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

@Nova_Logic As a workaround can you try the following configuration, this should ensure the behaviour you're after:

policy {
    local-route {
        rule 1 {
            fwmark 201
            inbound-interface eth0
            set {
                table 201
            }
        }
        rule 2 {
            fwmark 202
            inbound-interface eth0
            set {
                table 202
            }
        }
        rule 3 {
            fwmark 203
            inbound-interface eth0
            set {
                table 203
            }
        }
    }
}

I had a closer look at this, the commits here and here should have brought this back from the dead but there is a small issue where the table "ip nat" is used when at the same time all of the nat related chains were refactored into the vyos_nat table. The normal functionality of WLB isn't affected because the mangle table isn't changed.

@thetooth but according to current docs that exactly what is documented in docs: https://docs.vyos.io/en/equuleus/configuration/loadbalancing/index.html

Also, it can be wildcard-address
@Rain Could you create a PR?

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

@Nova_Logic no it would not function as intended, the reason is say you have 3 interfaces, and interface 1 has a metric of 1, 2 a metric of 2, etc. If a packet comes in off one of these interfaces it will be routed to it's destination with the appropriate DNAT rule, the source address is the initiators global unicast address with the mac of the router itself. Now when your service replies it's hosts routing table looks like

0.0.0.0/0 via routers-localaddr

The destination address is of course the remote global unicast address of the client and the source is the local area network address (information is still sufficient at this point), however the routers table will look like

0.0.0.0 via iface1 metric 1
0.0.0.0 via iface2 metric 2
0.0.0.0 via iface3 metric 3

So the reply will always go out iface1, source NAT happens post routing, so the source address of the reply packet from the initiating clients perspective has changed, thus being invalid and dropped by any correctly configured firewall.

so you mean that new WLB implementation(on which I assume we're discussing here) would not mark incoming packets/sessions to allow vyos to DNAT/send replies to correct WAN like pfsense for example does?

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

@Nova_Logic I understand your frustration with the old WLB, it is not compatible with policy routes, DNAT, or fwmarks due to the way it's implemented. However WLB or this new implementation are not ingress capable tools. That is, these fill a niche in SMB setups where BGP peering is not possible (due to the use of commodity ISPs), or the cost and/or complexity of operating an IGP or even physically connecting into something like enterprise ethernet, is just completely out of the question. Despite the limitations these setups still need a way to switch over from faulted links quickly and reliably so you don't have an office full of people twiddling there thumbs while the internet is down.

Also it seems, that’s issue appears on 3 or more wans, as I remember it worked with 2 WAN interfaces

The problem is that failover route will not solve multiwan scenarios where you have 2 or more links for incoming traffic, I.e web. Most good infrastructures would have dedicated management uplink, and also multiple WANs for serving client traffic. That approach increases infrastructure security and provide much more cleaner way to define zone policies. But to do that all traffic, especially incoming one must be correctly marked. I’ve tried a lot of ways to configure wlb, but every time vyos had tried to reply from the wrong interface, that’s why I had crated a bug task here

@tioan , Have you assigned your local-zone to the firewall rule ? Please use the latest version and share the error

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

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

PR for VyOS 1.3 https://github.com/vyos/vyatta-cfg-system/pull/187

Tested with next configuration:

vyos@r14:~$ sudo cat /etc/pam.d/common-auth 
auth  required      pam_env.so
auth  required      pam_faillock.so preauth silent audit deny=3 unlock_time=300
auth  sufficient    pam_unix.so  nullok  try_first_pass
auth  [default=die] pam_faillock.so  authfail  audit  deny=3  unlock_time=300
auth  requisite     pam_succeed_if.so uid >= 1000 quiet_success
auth  required      pam_deny.so
vyos@r14:~$

PR https://github.com/vyos/vyatta-cfg-system/pull/186

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

set service ssh hostkey-algorithm '[email protected]'
set service ssh hostkey-algorithm 'ssh-rsa'

Added more bgpd/ospfd events to the log. The VRF Id seem to be correct. But the events look curious. After session start the interface is first created in vrf default (vrf default, id:0) followed by bgpd/ospfd events, then accel-ppp process moves it to destination vrf (vrf client, id:5) which is follwed by the bgpd/ospfd errors.
Finally, with more or less than 5000 sessions bgpd accidentally becomes unresponsive and utilizes 200% cpu (8 cores are used on VM). Accel-pppd process having all network destinations unreachable also goes unresponsive a bit later.
After that we have to reboot.