1

I noticed that when connecting from a container c1 in network lxdbr0 (10.0.0.1/24) to a container c2 in network lxdbr1 (10.0.1.1/24) , the target container sees the address of the lxdbr0 gateway (10.0.0.1) and not the original internal IP of the source container.

In my case c2 hosts a web application and c1 is the reverse proxy. The application needs the original IP of the client in some cases and it has a mechanism to obtain it from the reverse proxy. But here a cross-bridge-network connection doesn’t preserve the reverse proxy IP.

Is there a way to change this behaviour or to get the original IP of c1?

2

Would network zones help here?

3

Hi,

how do you think it could help?

I reviewed Network Zones and, if my understanding is correct, it’s about being able to access internal services cross-network with their domain name, instead of IP.

This isn’t what I want to achieve. What I want to achieve is to have c2 seeing c1 internal IP address and not c2 network gateway IP.

4

Just to add that any application that applies some IP-based logic, probably a security one, would be unable to do that if the Ip is always the one of the gateway of the target network.

For one example when we want to limit an HTTP endpoint to local IPs: ex. server-status in Apache or administrator in Joomla.

Feedback is highly welcome.

5

This is expected because by default LXD bridge networks come with ipv4.nat enabled.
This means that any cross-network traffic is source-natted to the IP host on the interface being used for egress traffic.

In this case it means that the target bridge IP will be seen as the source address.

You could try setting ipv4.nat to false, although if you also rely on that SNAT functionality for egress traffic onto the external network then that may cause problems.

6

Thanks for the feedback.

I tried ipv4.nat=false in lxdbr1, and the behaviour is the same. I’m using lxd 5.0.2.

P.S. actually in my initial post, the correct statement is that the “target container sees the address of the lxdbr1 gateway”

7

Hello @tomp , I’m now having the same question as related to an OVN network. Is it possible to pass-through the source ip up to containers that rely on OVN connectivity?