Openvpn and ip address seen by the orange network


I am using ipfire 178.
When I connect to a server on the orange network through OpenVPN, the connection is seen as a connection from the real IP address and not from the openvpn IP.

my real ip: for example
my openvpn ip :
my orange server see the ip, i was expected

any idea of my trouble?

I am not sure I fully understand your network… so this may not be correct.

If you are trying to connect from a local zone (like green or blue) to orange then you’d want the 192.168.6.x ip addresses (yes, via VPN)

If you are trying to connect from a external IP address to orange then you want the real IP address like And you’d need a firewall rule to get from external to orange (via VPN)

I will try to give more details.

public home address: for example
orange network :
vpn network :
When from an external network (gsm network or hotel network), I have the local (hotel) ip I connect to the IPFire openVPN which give me the ip

In that case, my server on the orange network see me as not as And I don’t understand why. For me, the only IP which should be visible should be on the all internal networks (orange, blue and green).
The good things is when I try to go on, which is an external address, this external server see me as my home public ip address which is expected.

I hope I am more clear now. not sure.

Do you route all traffic from client through VPN to orange ?

I have the global option “Redirect-Gateway def1” enabled.
I have also Orange and Green network selected for the option “Client has access to these networks on IPFire’s site” (client option)

1 Like

yes, I have an hypothesis. It appears that both your server (WEB server?) and OpenVPN server share the same public IP address on the red interface of IPFire. When your OpenVPN client establishes a connection with the OpenVPN server, it uses this shared public IP. Subsequently, when it tries to connect to the (web?) server, it also targets the same public IP. This leads to a split-tunneling scenario from the client side, as routing traffic for the (web?) server through the VPN tunnel in this case could create a routing loop or even disrupt the VPN connection itself.

If my understanding is correct, you should be able to access your server inside the tunnel by directing your browser (if it is a web server) to the server’s private IP address.

you are right. And I think you have the explanation.

So, I don’t understand this option :
Redirect-Gateway def1 - Directs all IP traffic through the VPN client

I understand that all traffic is going through the vpn so I should see the vpn ip address on my orange web server.

I will see if it is possible to add ‘additional configuration’ to do what I want.

Thanks for the answer

Redirect-Gateway def1 - Directs all IP traffic through the VPN client (e.g. web browser).

To clarify, this is a client side directive. You are on your client, you open a tunnel to the server, you open a browser, the traffic goes through the tunnel. If the “redirect-gateway” directive is not specified, only traffic destined for the network on the other side of the VPN tunnel will go through the tunnel by default. This is known as “split tunneling.” In this case, traffic intended for the Internet will not go through the VPN but will use the client’s regular gateway and only traffic intended for the remote network specified in the VPN configuration will go through the VPN tunnel.

so, there is a conflict between this option which is enable on my openvpn, this explanation and the hypothesis you made 2 posts before.

I suggest a simple test.
Disable Redirect-Gateway def1 then make a test.

while I am sure that this is problem happens because both servers are in the same subnet and share the same public IP, I am not exactly sure what happens in detail. I would assume that the routing is impossible therefore the client is using a split tunnel regardless of the directive, but I am not convinced that this is true.

it is exactly the same behavior.

I have play with all the possibility with the 2 options :
1- “Redirect-Gateway def1” enabled.
2- Orange and Green network selected for the option “Client has access to these networks on IPFire’s site” (client option)

I always see the external IP (

Have you added any firewall rules?

Do you also have redirection disabled in the advanced client options?

After some reflection, now I believe what you’re experiencing may not be split tunneling but rather a NAT loopback, also known as hairpinning. Let’s simplify the scenario by assuming your server is a web server. When the client establishes the VPN tunnel using the “redirect-gateway def1” directive, all its traffic is routed through the tunnel, including the traffic from the web browser. Upon reaching the OpenVPN server, where is this traffic directed? To the web server’s public IP address as OpenVPN see that in the destination.

As a result, the traffic is sent back to IPFire, which recognizes the destination as the web server based on the IPFire public IP and web port numbers. To ensure that the response from the web server goes back through the same interface (THIS IS THE KEY), IPFire (or OpenVPN) before delivering the packets to the web server performs a source NAT. It changes the source IP in the packets back to the client’s public IP, rather than using the OpenVPN-assigned private IP. This is known as NAT hairpinning or loopback.

For a more detailed explanation of this process, you can refer to this excellent thread on the topic.

no, both are disabled

interesting I will read it :slight_smile: