Good morning,
I have this problem:
I created a VPN with openvpn, but my network has the same IP class as the network I need to connect to, 192.168.144.xxx.
In this way the VPN goes up correctly, but when I try to open the remote desktop to connect to a remote machine everything doesn’t work because my PC searches on my local network but not on the remote one.
If you’re using IPFire as your router on the client side, you can set up an SNAT (Source Network Address Translation) rule. This rule will change the source IP address of the traffic heading to the VPN server. Choose an IP for the SNAT rule that avoids any IP address conflicts with both your local and the remote network.
You can change the IPs with SNAT the other way around. In this scenario, since IPFire is on the server side and the client is using the OpenVPN GUI, the SNAT configuration would be implemented on the IPFire server, which is hosting the OpenVPN service. The purpose of this SNAT rule is to modify the source IP address of the traffic that is returning from the IPFire/OpenVPN server to the client.
When your OpenVPN client sends traffic to the server, it uses its local IP address as the source. This is where the conflict arises if the remote network (the one behind the IPFire server) uses the same IP range. To resolve this, you set up an SNAT rule on the IPFire server. This rule changes the source IP address of the traffic as it is sent back from the server to the client. Essentially, it “masquerades” the traffic from the server to appear as if it’s coming from a different IP range, one that doesn’t conflict with your local network. As a result, when your client receives the traffic, it sees it as coming from this new, non-conflicting IP range, not from an IP range that it thinks is local. This way, the client can correctly route responses back to the server, rather than mistakenly trying to find the destination within the local network.
The SNAT rule effectively differentiates the traffic, preventing routing conflicts.
This will not help because the client will not send the packets to the IPFire if the destination IP is in the same subnet and If you set a custom static route for one specific IP IPFire will not route this to the VPN if the IP’s match with a local zone.
This is what I think too, in fact if I try to open the address of the remote server with a brouser, with the VPN active, the NAS I have on the client’s local network will respond in any case.
I thought of using the second network card of the server, I manage it, and connecting it to the BLUE port of IPFire, assigning it an address belonging to a different class and enabling the VPN client to also access this interface.