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?

I think this should be re-opened. The solution that is documented does not follow the spirit of hairpin NAT, which is that traffic on port N not actually destined to the inside target should not be redirected.

https://github.com/vyos/vyos-1x/pull/1646

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.