In my opinion (I'm not an expert) we should just do the VPN to the subnet where the server is, or add this subnet to the VPN configuration on the clinet side.
Yes. You're right. You have 3 options:
A) Create a VPN connection directly with the server's LAN (if there
is an vpn-capable firewall there connected directly to the Internet).
B) Add the server's subnet to the VPN configuration on both sides of
the tunnel and do some routing configuration (on your client's
network) if the server's LAN is not directly connected to the
firewall or the firewall is not the primary gateway of the server's
network.
C) Do some NAT-wizardry if options A and B are not available (details
below).
Assume the following diagram (your current configuration):
# Duke's Network # # Client's Network #
[ 110.110.1.0/24 ] <----------- VPN Tunnel -----------> [ 192.168.100.0/24 ]
NAT-wizardry Spell #1: The Fireball
On your client's network, choose an available IP address from the 192.168.100.0/24 network (e.g, 192.168.100.254) and create 1-to-1 DNAT and SNAT rules on your clients firewall pointing to the server's IP address.
# Connection from Duke's Network to server on client's network
110.110.1.0/24 ------> 192.168.100.254 [DNAT] ------> 192.168.1.68
# Response from the server
192.168.1.68 --------> [SNAT] 192.168.100.254 ------> 110.110.1.0/24
This will work OK if the firewall is the gateway of the server, or if it is possible to configure some routes on the server or along the path. The connection will also work both ways, meaning that your network or the server can initiate connections to one another.
If your client can't change the routing configuration and the firewall is not the gateway for the server, but the server can still reach the firewall on the client's internal network, do the following:
NAT-wizardry, Spell #2: The Arcane Gate
Here you will create a double NAT, an 1-to-1 and a many-to-1 (a.k.a masquerade, in iptables terminology):
### REQUEST ###
# Duke's network perspective (notice the 1-to-1 DNAT from Spell #1)
[Duke FW OUT ] 110.110.1.0/24 ---- VPN ----> 192.168.100.254 [ Client FW IN ]
# The packet is inside de Client's FW, here we do another NAT (many-to-1)
# and change de source addr of your network to the internal IP addr of the FW
[ Firewall OUT ] 192.168.100.1 (FW LAN IP) -----> 192.168.1.68
This way, the connection will appear to come from the firewall to the server.
When the server responds to the FW, we will invert the NATs.
Notice that, by using this configuration, the connections can only be initiated from your network. The client's server will be able to respond to your packets, but will not be able to initiate any connection to your network.
NAT-Wizardry, Spell #3: The "Weird" (a.k.a The Abismal Administration Nightmare)
Here, the cost of administration and maintenance will increase exponentialy, depending on how many hosts of your network the server needs to initiate connections to.
Essentially, there are two ways to make this configuration and regret for the rest of your days (actually, make the client regret, since it will be performed on his firewall).
3a) Bound a new, non-used, IP address to the LAN interface of the client's firewall, and create a 1-to-1 NAT pointing to the IP address on your network that needs do be accessed by the client's server. You will need to do this to each new IP on your network that has to be accessed by the client's server.
3b) Create a PAT (Port Address Translation). In this configuration, you can map specific TCP|UPD ports from one IP address (the Firewall) to any port of your choice on another IP address (on your network). This will need to be performed for each service/port that has to be accessed by the client's server on your network.
TL;DR: Choose option B and fix any routing issues.
