1

I'm a Java Developer and for a few weeks I'll be in charge of the network as well. A client of ours wants a VPN connection to his network which I already mounted (Using a TP-link router to stablish the IPSEC Tunnel LAN-to-LAN).

Our network: 110.110.1.0/24 Our Server 110.110.1.100/24 Client's network: 192.168.100.0/24

But to my surprise the connection purpose is to be able to connect to a specific Server wich is in a different subnet in the client end.

Client's Server: 192.168.1.68/32

So it's in a different subnet (different netmask ofc)... How can I achieve the connection? I know that the netmask doesn't mean anything in a LAN-to-LAN connection but since the target is in a different subnet with a different netmask.

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.

  • 1
    Could you describe detailed what you have and what you want. – Alexander Tolkachev May 26 '17 at 16:53
0

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.

  • Great response, thanks for your time ill use option B. – Javier May 29 '17 at 10:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.