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: 45.46.47.48 for example
my openvpn ip : 192.168.6.3
my orange server see the ip 45.46.47.48, i was expected 192.168.6.3
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 45.46.47.48. And youâd need a firewall rule to get from external to orange (via VPN)
public home address: 77.77.77.77 for example
orange network : 192.168.1.0/24
vpn network : 192.168.6.0./24
When from an external network (gsm network or hotel network), I have the local (hotel) ip 45.46.47.48. I connect to the IPFire openVPN which give me the ip 192.168.6.3.
In that case, my server on the orange network see me as 45.46.47.48 not as 192.168.6.3. And I donât understand why. For me, the only IP which should be visible should be 192.168.6.3 on the all internal networks (orange, blue and green).
The good things is when I try to go on my-ip.com, which is an external address, this external server see me as my home public ip address 77.77.77.77 which is expected.
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)
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.
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.
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.
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)
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.