- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Oct 29 2022
Still on track for 1.4 ?
Oct 28 2022
There's something weird happening with this. If you change simply persistent-keepalive from 25 to 30 or 30 to 25 will reactivate the peer. At least thats my experience. Doing anything else didnt work for me including:
Best suggestion seems to be introducing a script to call podman stop -t N on shutdown/reboot to reduce the timeout before SIGKILL is sent.
Backported in https://github.com/vyos/vyatta-cfg-quagga/pull/97
Is there some progress? VPP is available for AArch64 in meantime.
Here some news about VPP performance:
Oct 27 2022
Oct 26 2022
Oct 25 2022
Oct 24 2022
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.
Oct 23 2022
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.
Oct 21 2022
@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
Oct 20 2022
Also, it can be wildcard-address
@Rain Could you create a PR?
@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.