Last adaptation to the version: 12.6.0
- Layout adjustment
- Screenshots updated
Introduction
In this wiki, we want to deal with the case where a road warrior establishes a VPN connection to different destinations at the same time, but they all use the same subnet. Furthermore, the VPN client also receives an address from the same roadwarrior pool from the VPN servers. In this case, the client would of course have the problem that it cannot distinguish between the destinations.
The NAT type NETMAP can help here.
In our example, we assume the following specifications:
| Roadwarrior Pool: | 192.168.0.0/24 |
| Internal network of the locations: | 192.168.175.0/24 |
| Netmap network of the first location: | 192.168.1.0/24 |
| Netmap network of the second location: | 192.168.2.0/24 |
We also assume that the SSL-VPN Roadwarrior connection is already set up and working.
Configuration of the SSL-VPN roadwarrior server with Netmap
Preparations
| Button | UTMuser@firewall.name.fqdnFirewallNetwork Objects  Change network object to address
|
The following conditions must be observed when using the NETMAP function:
The network object of the internal network must not be set to the interface. If necessary, this can be changed to Address by entering the address in the drop-down button. In this example, we have the network 192.168.175.0/24 on both sides. | |
Setting in the SSL-VPN server
| Button | UTMuser@firewall.name.fqdnVPNSSL-VPN  Netmap address on the Roadwarrior server
|
| Only the Netmap network is entered under Share server networks and not the original subnet of the internal network.
If other subnets are to be transmitted to the client, it must first be checked that these are not also available on other targets. | |
Create network objects
In addition to the existing network object for the Roadwarrior, another one is required for the Netmap network with the following properties in order to create a corresponding packet filter rule:
| Designation | Value | Description | UTMuser@firewall.name.fqdnFirewallNetwork Objects  Network object for Netmap network
|
|---|---|---|---|
| Name: | Netmap-Network | Is freely selectable. | |
| Type: | Network (address) | ||
| Address: | 192.168.1.0/24 | The subnet to be used for Netmap. | |
| Zone: | internal | The network zone in which the network with whose hosts the client is to establish a connection via VPN is located. | |
Packet filter rules
| The first packet filter rule will already be in place, because the SSL-VPN connection has already been created and works if the client does not establish another connection to another destination with the same subnet at the same time. This packet filter rule is about the basic control of data transmission from the Roadwarrior to the internal network with certain services. Nothing changes here either. |
UTMuser@firewall.name.fqdnFirewallPacket filter  Packet filter rule for Roadwarrior
|
| The second packet filter rule is new and relates to the Netmap. It has the following properties: | |||
| Designation | Value | Description | UTMuser@firewall.name.fqdnFirewallPacket filter  Packet filter rule for Netmap
|
|---|---|---|---|
General
| |||
| Source: |  internal-network |
Network to which the Roadwarrior should have access. | |
| Destination: |  Roadwarrior |
Network of the Roadwarrior. | |
| Service: |  any |
The any rule should only be used with Netmap, as it has no restrictions. | |
| Action: | ACCEPT | ||
[ - ] NAT
| |||
| Type: | NETMAP | ||
| Network object: | Netmap network |
||
| Service: | any |
The any rule should only be used with Netmap, as it has no restrictions. | |
The packet filter overview should now contain the following lines:
| # | Source | Destination | Service | NAT | Action | Active | |||
 |
5 | Roadwarrior |
internal-network |
 ms-rdp |
Accept | On | |||
|
6 | internal-network |
Roadwarrior |
any |
NM | Accept | On | ||
Notes
The VPN client must re-establish the connection so that it also receives the correct subnet.
Access from the client to a host in the internal network then takes place via the IP address 192.168.2.x, as the subnet mask /24 has been defined here. The last octet is therefore the original host IP.
So if we want to address the host with the original IP address 192.168.0.1 in this example, the client must use the IP address 192.168.2.1 to reach it.
The client can only access the hosts in the internal network with IP addresses. A DNS query would result in the original IP of the host being transferred and the client would no longer be able to access it.