Hi@kanpov it may be the host configuration was not fully captured back when this guide was written. As you said we could update it to useMASQUERADE, but that would invalidate the results below unless we repeat them. we will look into it but I am initially more inclined to just point to theworking example we have in our integration tests.

Hi@kanpov it may be the host configuration was not fully captured back when this guide was written. As you said we could update it to useMASQUERADE, but that would invalidate the results below unless we repeat them. we will look into it but I am initially more inclined to just point to theworking example we have in our integration tests.

Funnily enough, the working example you link doesn't use a singleSNAT orDNAT rule and does forwarding similarly to what I pointed out instead, so even it isn't what's described on that documentation page. So I think I'm correct in assuming that the configuration presented in the docs is not functional, and yet (as you said) fixing the documentation page would require rerunning the tests which I can't do.

This is completely the double-forward (from tap to vpeer, and from vpeer to host iface) setup I described in my comment where I used 6/7 (7 with guest IP forwarding) rules. So if the tests were run using it, it's actually possible that this latest setup I showed with 1 forwarding chain and 2 NAT rules inside the netns is faster than the one currently being used by CI (2 forwarding chains).

The last rule is DNAT inside the netns to rewrite the globally-routable IP to the one representing the guest inside the netns.

For the full code, you can check out the fcnet crate I made that implements both simple and netns networking. For netns, it uses 1 forwarding chain and 2 rewrites instead of 2 forwarding chains like in CI

I guess that ishttps://github.com/kanpov/fcnet/blob/master/src/netns.rs? Thanks, I will take a look at it.

Provided an updated guide in#4848. I think that at least works with what we have in the integration tests even if it's not optimal. Also removed the performance section since we don't have a way of rerunning those tests.

Thanks for the effort! As for the optimal claim, I don't actually have concrete benchmarks that would prove that FORWARD,MASQUERADE + DNAT for connectivity to the guest and SNAT + FORWARD,MASQUERADE for connectivity from the guest are faster than FORWARD,MASQUERADE + FORWARD,MASQUERADE on both, I made that assumption based on the reduction in iptables rules. So I suppose it'd be interesting to actually make that benchmark, but doing it "properly" in the context of Firecracker would entail recovering those tests or creating new ones.