Appendices : Device Configuration : PPTP VPN configuration for example 2

PPTP VPN configuration for example 2
After the private subnets, device and user account configuration in Two private subnets and user configuration for example 2 is completed, a VPN connection must be created. This example shows the configuration steps that must be performed by the OnBoard appliance administrator and by a user on a remote workstation for setting up an PPTP VPN connection1 that would enable the authorized user allSps to access sp1, sp2, sp3 and sp4.
The OnBoard appliance administrator must do the following to enable the PPTP client:
Figure D.10 shows an example PPTP configuration on the Network-VPN connections screen.
PPTP VPN Configuration Example: Address Pools
Figure D.10 shows the following address pools:
NOTE: The address pools’ IP addresses can be assigned arbitrarily. Make sure that none of the addresses assigned here are being used elsewhere on your network.
Make sure the following are done for the user who needs the PPTP VPN access:
Figure D.11 shows an example PPTP configuration on the Config-Users and groups screen.
PPTP User Configuration Example
NOTE: The user can be configured for PPTP alone or for both PPP/PPTP.
The authorized user must do the following:
The user can test whether the user’s workstation can access the OnBoard appliance by entering the OnBoard appliance’s public IP address in a browser to try to bring up the Web Manager.
Enter the ifconfig or ipconfig command on the command line of the user’s workstation to discover the IP address assigned to the OnBoard appliance’s end of the PPTP VPN tunnel.
When the PPTP tunnel is being activated, the OnBoard appliance chooses an IP address from each of the address pools for the endpoints of the PPTP link. The client’s end of the point-to-point link receives an address from the remote address pool, and the OnBoard appliance receives an address from the local address pool. Usually the first connection obtains the first address from each pool, so the client would be 192.168.3.1 and the OnBoard appliance would be 192.168.2.1.
Enter the OnBoard appliance’s PPTP-assigned address either in a browser or with ssh on the command line to access the OnBoard appliance. In this example the address would be 192.168.2.1.
route add -net 192.168.1.0 mask 255.255.255.0 via 192.168.2.1
route add -net 192.168.4.0 mask 255.255.255.0 via 192.168.2.1
See Enabling native IP and accessing a device’s native features using real IP addresses for example 2.
Enabling native IP and accessing a device’s native features using real IP addresses for example 2
After creating the VPN tunnel as described in IPSec VPN configuration for example 2 or PPTP VPN configuration for example 2, the user uses the OnBoard side IP address configured for the appropriate private subnet to access the OnBoard appliance and then enables native IP access to the desired device.
Enabling native IP access
In this example, to enable native IP access on sp1 or sp2 on sub1, the user would enter the OnBoard side IP address for sub1 (which is 192.168.1.1) in one of the two following ways:
Select the Devices left menu option.
Select sp1 or sp2.
Click Enable Native IP access
Select either sp1 or sp2 from the devices menu.
Select Enable native IP from the list of management actions the user is authorized to perform on the device.
-or-
Enter ssh to execute the nativeipon command directly using the device alias
Accessing native features for example 2
After enabling native IP access, the user can access one of the desired native features that may be available on the device, including a native web application or a native management application.
A native web application may be accessed in one of the following ways:
In the Web Manager on the OnBoard appliance, clicking the Go to native web interface link on the Access Devices screen.
On the user’s workstation, on the command line, entering the ssh command with the name/alias of the device along with the IP address of the OnBoard appliance side address for the subnet where the device resides.
A native management application may be accessed in one of the following ways, depending whether the application is a client on the user’s workstation or resides on the SP:
If the management application resides on the SP, and is an executable that can be invoked on the command line, by accessing the SP’s console first in one of the following two ways:
-or-
In the Web Manager on the OnBoard appliance, clicking the Access Devices-Service Processor Console menu option.
-and
Bringing the management application up from the SP’s command line.
-or-
In the Web Manager on the OnBoard appliance, clicking the Access Devices-Device Console menu option.
Why define virtual (DNAT) addresses?
A virtual network based on DNAT may be defined in the following cases:
CAUTION:When an authorized user has service processor access, device console access or native IP access, there is no way to prevent that user from seeing the IP address of the device while the user is connected.
It is possible and desirable to hide devices’ real IP addresses from users who are authorized to access all other device management capabilities other than native IP, service processor console, or device console.
When multiple private subnets must be supported by a single network route, and you do not want to require authorized users to configure routes to each network.
For example, if three connected devices have addresses 192.168.0.1, 10.0.25 and 17.10.11.12, three private subnets could be defined. A virtual network would map the IP addresses from the three private subnets to virtual IP addresses in the same virtual network range.
Table D.12 describes the information that defines a virtual network.
IP address to assign to the OnBoard appliance from the virtual network address range. For example, if the virtual IP address of the network is 10.0.0.0, 10.0.0.254 would be a valid IP address that could be assigned to the OnBoard appliance. The administrator would then have all the other addresses to assign to devices, except for 10.0.0.0 and 10.0.0.255.
NOTE: Some service processors do not work with virtual network (DNAT) addresses.
Example 3: Virtual network with two private subnets and VPN configuration
This example adds to the configuration of two private subnets with four devices shown in Figure D.6 by configuring a virtual network, which has the following benefits:
The following figure shows the same configuration as Figure D.4, but with the addition of virtual IP addresses.
Figure D.13 shows an example of virtual network configuration that enables virtual addresses to be assigned to connected devices and to the OnBoard appliance. The administrator plans to assign virtual IP addresses in the 172.20.0.1 range to hide the real private subnet IP addresses.
Example 3: Virtual Network Configuration
NOTE: sp4 in Figure D.13 is an SP that does not work with virtual network (DNAT) addresses.
Virtual network and device configuration for example 3
To hide the real addresses of the devices from users according to the ongoing example, the OnBoard appliance administrator would need to do the following configuration:
The device named sp4 with IP 192.168.4.22 does not work with virtual network (DNAT) addressing, so it cannot be contacted using a virtual IP address. Therefore, the administrator does not assign sp4 a virtual IP.
To make it possible to assign the virtual addresses shown in Figure D.13, the OnBoard appliance administrator needs to configure a virtual network with the following values:
Figure D.14 shows the desired values entered on the Web Manager Network-Private subnet: Add Subnet screen.
Example Values for Configuring Two Private Subnets With a Virtual Network
Finally, the administrator also must configure the devices that support virtual addressing with a virtual address from the 172.20.0.0 virtual network IP range. For example, Figure D.15 shows the virtual IP address 172.20.0.2 assigned to the device sp1 on the Web Manager Config Devices screen to implement the configuration shown in Figure D.13.
Example 1: Device Configuration Example
Figure D.16 shows the entries on the Devices screen for the devices shown in Figure D.13. Note that the IP addresses for sp1, sp2, and sp3 are hidden, and the user can only see the devices’ virtual IP addresses. Because sp4 does not work with virtual IPs and no virtual IP was configured for sp4, the user sees sp4’s real IP address.
Access-Devices Screen With Virtual IP Addresses
IPSec VPN configuration for example 3
After the private subnets, device and user account configuration in Virtual network and device configuration for example 3 is completed, a VPN connection must be created. With a virtual network, only one IPSec VPN connection must be configured to create the IPSec VPN tunnel from the user’s workstation to sp1, sp2 and sp3, which are on both private subnets in example 3.
Configuration of connSub2 would be still be needed as in IPSec VPN configuration for example 2, because the only way a user could contact sp4 would be through the private subnet IP.
The values used for enabling an IPSec VPN connection are the same as in IPSec VPN configuration for example 2, except the OnBoard appliance administrator must configure the Left subnet: by entering 172.20.4.0/22 to configure the connection to the virtual network.
Figure D.17 shows the configuration on the Web Manager Network-VPN connections: IPSec Add new connection dialog for a connection named connVirt, with the values specified from the previous paragraph.
Example 3: IPSec Connection Configuration for Access to sub1 Private Subnet and sp1 and sp2 Devices
As in the earlier example, the OnBoard appliance administrator must do the following to enable the IPSec client to access the subnets where the devices reside:
The OnBoard appliance administrator can send a copy of the relevant portions of the ipsec.conf file after the changes are saved and applied in the Web Manager for the user to insert into the ipsec.conf file on the user’s workstation.
The authorized user must do the following to enable the IPSec client running on the user’s workstation to bring up the VPN tunnel to access the subnets where the devices reside and then to access the native IP features on the devices.
If the OnBoard appliance administrator sends the relevant portions of the ipsec.conf file from the OnBoard appliance’s IPSec configuration, use it to replace the same section in the workstation’s ipsec.conf file.
Bring up the IPSec VPN tunnel. For accessing sp1, sp2, or sp3, the user can use the connVirt connection profile. For accessing sp4, the user uses the connSub2 connection profile.
Enabling native IP and accessing the device’s native features is the same as described under Enabling native IP and accessing a device’s native features using real IP addresses for example 2.
PPTP VPN configuration for example 3
After the private subnets, device and user account configuration in Virtual network and device configuration for example 3 is completed, a VPN connection profile must be defined to create a VPN tunnel to the virtual network.
The steps used for enabling a PPTP VPN connection to the virtual network are the same as in PPTP VPN configuration for example 2, except that, after creating the PPTP VPN tunnel, the user must create the static route differently to access the virtual network.
This first set of bullets are a review of the steps for obtaining the PPTP address assigned to the OnBoard appliance:
Enter the ifconfig or ipconfig command on the command line of the user’s workstation to discover the IP address assigned to the OnBoard appliance’s end of the PPTP VPN tunnel.
Enter the OnBoard appliance’s PPTP-assigned address either in a browser or with ssh on the command line to access the OnBoard appliance. In this example the address is 192.168.2.1.
The next bulleted items shows how to create an appropriate route to the virtual network.
In this example, to communicate with sp1, sp2 and sp3, a route would needed to the virtual network whose IP address is 172.20.0.0 as shown below:
route add -net 172.20.0.0 mask 255.255.0.0 via 192.168.2.1
To communicate with sp4, because it cannot be contacted through a virtual network IP address, the same route mentioned in PPTP VPN configuration for example 2 would be needed to sub2, which has the network IP address 192.168.4.1 as shown below:
route add -net 192.168.4.1 mask 255.255.252.0 via 192.168.2.1
Enabling native IP and accessing the device’s native features is the same as described under Enabling native IP and accessing a device’s native features using real IP addresses for example 2.
Enabling native IP and accessing a device’s native features using virtual network addresses for example 3
After creating the VPN tunnel as described in IPSec VPN configuration for example 3 or PPTP VPN configuration for example 3, the user enables native IP and accesses a device’s native features.
In this example, to access sp4, which is a type of service processor that does not work with virtual network addresses because it is not compatible with DNAT, the user would enter the OnBoard’s real address, as described in Enabling native IP and accessing a device’s native features using real IP addresses for example 2.
Enabling native IP access for example 3
In this example, to enable native IP access to sp1, sp2, or sp3, the user would enter the OnBoard’s virtual IP address, which is 172.20.0.1, in one of the two following ways:
Chose the Access - Devices left menu option.
For either sp1, sp2, or sp3, click Enable Native IP access.
Enter ssh to connect to the OnBoard appliance’s console and to access the rmenush menu in one of the following ways:
 
OR
Enter ssh to execute the nativeipon command directly using the device alias:
Accessing native features for example 3
After enabling native IP access, the user can access one of the desired native features that may be available on the device, including:
On the user’s workstation, on the command line, entering the ssh command with the name/alias of the device along with the virtual IP address of the OnBoard appliance.
For example, see the following ssh command line entered by the user named allSPs to access sp2 using the OnBoard appliance’s virtual IP address 172.20.0.1.
A management application, which may be accessed in one of the following ways, depending whether the application is a client on the user’s workstation or resides on the SP:
If the management application resides on the SP, and is an executable that can be invoked on the command line, by accessing the SP’s console first in one of the following two ways:
Invoking ssh with the spconsole command in the following format
-or-
In the Web Manager on the OnBoard appliance, clicking the Service Processor Console link on the Access Devices screen.
-and-
Bringing the management application up from the SP’s command line.
Invoking ssh with the devconsole command in the following format
-or-
In the Web Manager on the OnBoard appliance, clicking the Device Console link on the Access Devices screen.

1
A VPN tunnel must exist before a user can access native IP management features on a device.