Table of contents
You are currently comparing two old versions - only when you are comparing against the latest version can you revert. Return to version archive.
Combined revision comparison
...
Please refer to #10.11 Exploit SecureNAT for Remote Access into Firewall without Any Permission# for for details on how to set up the SecureNAT function.
...
| This feature means that no System Administrator authority is required to use the SecureNAT function. Please refer to 3.2 Operating Modes When general users with permission from the Network Administrator or System Administrator but without a System Administrator account use the SecureNAT function, it becomes possible to realize VPN communication typically not within general user authority. Please refer to In addition, System Administrators can use SecureNAT as safe NAT software. Typical NAT programs run as kernel modules. If there is vulnerability such as a buffer overrun in part of the NAT program, it may lead to system invasion and kernel authority theft by a black hat or an entire system crash due to a bug. In contrast, the SoftEther VPN SecureNAT program can be run completely in user space without the need for special system authority. Even if a failure occurs in the SecureNAT program, the effect is limited to the user space which launched the VPN Server / VPN Bridge, thus eliminating the risk of effects to other users and the system overall. |
...
- Use as a Simple Network Gateway
Even setting up the VPN Server and Virtual Hub and remotely connecting to that hub only results in closed communication within the Virtual Hub, so it is possible to communicate with the physical network connected to the computer running the VPN Server. Using local bridging in this case commonly involves a layer 2 connection between the Virtual Hub and the physical network, but using the SecureNAT function enables communication with the network connected to the computer operating the VPN Server via the Virtual Hub's virtual host network interface. Therefore, it is possible to make use of SecureNAT's virtual NAT function when preferring not to use the local bridging function, or unable to use it due to not possessing the computer's System Administrator authority or due to use of a UNIX OS version of the VPN Server or VPN Bridge other than Windows, Linux or Solaris. - As a DHCP Server
Of the SecureNAT functions, it is possible to enable only the DHCP server. In other words, it is possible to use only the DHCP server function operating within the Virtual Hub Ethernet segment. This allows VPN Clients and local bridge destination client computers remotely accessing the Virtual Hub to receive IP addresses assigned by the virtual DHCP server.
Normally, using DHCP automatic IP address assignment requires locally bridging that Virtual Hub to a separate network of the DHCP server or connecting to the Virtual Hub from the DHCP server with the VPN Client using the Virtual Network Adapter, but the SecureNAT function's Virtual DHCP server function eliminates this need. - As a Simple Gateway to Remotely Access Remote Sites
Remote access VPN to a remote site (for instance, sites on which equipment maintenance is to be carried out via the network) using the SoftEther VPN typically involves installing the VPN Server and VPN Bridge on that remote site's computer and connecting to it with a VPN Client or setting up a continuous cascade connection from that site to a VPN Server set up in a separate location, thus enabling communication with a computer node on that remote site using the SoftEther VPN. However, the SecureNAT function can be used as an alternative when a local bridge cannot be set up on a remote site's computer for security or costs limitations or when the OS does not support the SoftEther VPN local bridging function. Please refer to#10.11 Exploit SecureNAT for Remote Access into Firewall without Any Permission#for for details on these methods of use.
...
- Using Virtual NAT
The use of virtual NAT is recommended for environments running the VPN Server / VPN Bridge without System Administrator authority or OS support for local bridging, i.e. when a computer in the Virtual Hub's layer 2 segment is unable to use the local bridge function and needs to access a physical network host via the physical network interface of the computer actually running the Virtual Hub (particularly where the uses given in#10.11 Exploit SecureNAT for Remote Access into Firewall without Any Permission#are applicable).
Where local bridging can be used to connect a Virtual Hub and a physical network and in the absence of security issues, it is not necessary to connect a virtual network to a physical network using the virtual NAT function. - Preventing Connections causing Infinite Looping of Packets
Where a computer with VPN Client installed connects to a virtual NAT-enabled Virtual Hub either from the Virtual Network Adapter of its own Virtual Hub or by local bridging to said hub from a physical Network Adapter, and where the default gateways for those Network Adapters designate IP addresses assigned by the Virtual HUBfs SecureNAT virtual host network interface, communication attempting to connect to an arbitrary IP address tries to use the Virtual Hub's Virtual NAT, which in turn tries to communicate with the destination IP address by calling the operating system's network communication API, resulting in the connection packet falling into an infinite loop. The virtual NAT function is not typically used at the same time as local bridge connections and VPN connections to localhost using the VPN Client. If these types of connections are being made then there is a likelihood that the network design is incorrect. - Precautions relating to Performance
By possessing an internal virtual TCP/IP stack, SecureNAT performs the highly advanced process of reassembling the TCP/IP stream packetized once by the TCP/IP stack and further TCP/IP packetizing via the operating system. The overhead resulting from these processes is large, such that throughput via the virtual NAT is considerably decreased when compared to physical maximum throughput, even when using a computer with sufficiently high speed. That is why virtual NAT should not be used for performance-centric applications. As previously stated, virtual NAT is a function which can be used as an alternative when the local bridge function cannot be used for security or technical reasons. Where high-speed methods such as local bridging are available, those methods should be used. - Handling ICMP Packets
When virtual NAT is enabled, sending ICMP packets via IP addresses assigned by a virtual host network interface as routers, and further sending said packets to a separate host results in the virtual NAT returning dummy ICMP echo response packets to all ICMP echo request packets. This is a specification of the SoftEther VPN whereby this operation becomes inevitable because most operating systems do not allow the transmission of arbitrary ICMP packets in network APIs which can be called up with user authority. When using Virtual NAT it is therefore impossible to confirm the existence of a host on the other side of a Virtual NAT router using ICMP packets. - DNS Redirect
When Virtual NAT is enabled, UDP 53 port destination packets (DNS packets) to the IP address of the virtual host network interface are automatically forwarded to the DNS server being used as the DNS Server by the computer running the Virtual Hub. This is the same operation carried out by typical broadband routers. - Unsupported Functions
The User Mode TCP/IP stack used internally by Virtual NAT is not equipped with some sophisticated TCP/IP functions such as the Window Scale option, Selective ACKs and Nagle algorithms. In addition, the nature of Virtual NAT means that IP routing and NAT between virtual networks is not supported. The virtual layer 3 switch function should be used for inter-virtual network IP routing.
...
Version from 18:58, 3 Mar 2013
...
Please refer to #10.11# for details on how to set up the SecureNAT function.
...
| This feature means that no System Administrator authority is required to use the SecureNAT function. Please refer to When general users with permission from the Network Administrator or System Administrator but without a System Administrator account use the SecureNAT function, it becomes possible to realize VPN communication typically not within general user authority. Please refer to In addition, System Administrators can use SecureNAT as safe NAT software. Typical NAT programs run as kernel modules. If there is vulnerability such as a buffer overrun in part of the NAT program, it may lead to system invasion and kernel authority theft by a black hat or an entire system crash due to a bug. In contrast, the SoftEther VPN SecureNAT program can be run completely in user space without the need for special system authority. Even if a failure occurs in the SecureNAT program, the effect is limited to the user space which launched the VPN Server / VPN Bridge, thus eliminating the risk of effects to other users and the system overall. |
...
- Use as a Simple Network Gateway
Even setting up the VPN Server and Virtual Hub and remotely connecting to that hub only results in closed communication within the Virtual Hub, so it is possible to communicate with the physical network connected to the computer running the VPN Server. Using local bridging in this case commonly involves a layer 2 connection between the Virtual Hub and the physical network, but using the SecureNAT function enables communication with the network connected to the computer operating the VPN Server via the Virtual Hub's virtual host network interface. Therefore, it is possible to make use of SecureNAT's virtual NAT function when preferring not to use the local bridging function, or unable to use it due to not possessing the computer's System Administrator authority or due to use of a UNIX OS version of the VPN Server or VPN Bridge other than Windows, Linux or Solaris. - As a DHCP Server
Of the SecureNAT functions, it is possible to enable only the DHCP server. In other words, it is possible to use only the DHCP server function operating within the Virtual Hub Ethernet segment. This allows VPN Clients and local bridge destination client computers remotely accessing the Virtual Hub to receive IP addresses assigned by the virtual DHCP server.
Normally, using DHCP automatic IP address assignment requires locally bridging that Virtual Hub to a separate network of the DHCP server or connecting to the Virtual Hub from the DHCP server with the VPN Client using the Virtual Network Adapter, but the SecureNAT function's Virtual DHCP server function eliminates this need. - As a Simple Gateway to Remotely Access Remote Sites
Remote access VPN to a remote site (for instance, sites on which equipment maintenance is to be carried out via the network) using the SoftEther VPN typically involves installing the VPN Server and VPN Bridge on that remote site's computer and connecting to it with a VPN Client or setting up a continuous cascade connection from that site to a VPN Server set up in a separate location, thus enabling communication with a computer node on that remote site using the SoftEther VPN. However, the SecureNAT function can be used as an alternative when a local bridge cannot be set up on a remote site's computer for security or costs limitations or when the OS does not support the SoftEther VPN local bridging function. Please refer to#10.11#for details on these methods of use.
...
- Using Virtual NAT
The use of virtual NAT is recommended for environments running the VPN Server / VPN Bridge without System Administrator authority or OS support for local bridging, i.e. when a computer in the Virtual Hub's layer 2 segment is unable to use the local bridge function and needs to access a physical network host via the physical network interface of the computer actually running the Virtual Hub (particularly where the uses given in#10.11#are applicable).
Where local bridging can be used to connect a Virtual Hub and a physical network and in the absence of security issues, it is not necessary to connect a virtual network to a physical network using the virtual NAT function. - Preventing Connections causing Infinite Looping of Packets
Where a computer with VPN Client installed connects to a virtual NAT-enabled Virtual Hub either from the Virtual Network Adapter of its own Virtual Hub or by local bridging to said hub from a physical Network Adapter, and where the default gateways for those Network Adapters designate IP addresses assigned by the Virtual HUBfs SecureNAT virtual host network interface, communication attempting to connect to an arbitrary IP address tries to use the Virtual Hub's Virtual NAT, which in turn tries to communicate with the destination IP address by calling the operating system's network communication API, resulting in the connection packet falling into an infinite loop. The virtual NAT function is not typically used at the same time as local bridge connections and VPN connections to localhost using the VPN Client. If these types of connections are being made then there is a likelihood that the network design is incorrect. - Precautions relating to Performance
By possessing an internal virtual TCP/IP stack, SecureNAT performs the highly advanced process of reassembling the TCP/IP stream packetized once by the TCP/IP stack and further TCP/IP packetizing via the operating system. The overhead resulting from these processes is large, such that throughput via the virtual NAT is considerably decreased when compared to physical maximum throughput, even when using a computer with sufficiently high speed. That is why virtual NAT should not be used for performance-centric applications. As previously stated, virtual NAT is a function which can be used as an alternative when the local bridge function cannot be used for security or technical reasons. Where high-speed methods such as local bridging are available, those methods should be used. - Handling ICMP Packets
When virtual NAT is enabled, sending ICMP packets via IP addresses assigned by a virtual host network interface as routers, and further sending said packets to a separate host results in the virtual NAT returning dummy ICMP echo response packets to all ICMP echo request packets. This is a specification of the SoftEther VPN whereby this operation becomes inevitable because most operating systems do not allow the transmission of arbitrary ICMP packets in network APIs which can be called up with user authority. When using Virtual NAT it is therefore impossible to confirm the existence of a host on the other side of a Virtual NAT router using ICMP packets. - DNS Redirect
When Virtual NAT is enabled, UDP 53 port destination packets (DNS packets) to the IP address of the virtual host network interface are automatically forwarded to the DNS server being used as the DNS Server by the computer running the Virtual Hub. This is the same operation carried out by typical broadband routers. - Unsupported Functions
The User Mode TCP/IP stack used internally by Virtual NAT is not equipped with some sophisticated TCP/IP functions such as the Window Scale option, Selective ACKs and Nagle algorithms. In addition, the nature of Virtual NAT means that IP routing and NAT between virtual networks is not supported. The virtual layer 3 switch function should be used for inter-virtual network IP routing.
...
Version as of 16:57, 4 Mar 2013
...
Please refer to 10.11 Exploit SecureNAT for Remote Access into Firewall without Any Permission for details on how to set up the SecureNAT function.
...
| This feature means that no System Administrator authority is required to use the SecureNAT function. Please refer to 3.2 Operating Modes for details on how to launch the VPN Server / VPN Bridge as a general user. When general users with permission from the Network Administrator or System Administrator but without a System Administrator account use the SecureNAT function, it becomes possible to realize VPN communication typically not within general user authority. Please refer to 10.11Exploit SecureNAT for Remote Access into Firewall without Any Permission for specific methods of use. In addition, System Administrators can use SecureNAT as safe NAT software. Typical NAT programs run as kernel modules. If there is vulnerability such as a buffer overrun in part of the NAT program, it may lead to system invasion and kernel authority theft by a black hat or an entire system crash due to a bug. In contrast, the SoftEther VPN SecureNAT program can be run completely in user space without the need for special system authority. Even if a failure occurs in the SecureNAT program, the effect is limited to the user space which launched the VPN Server / VPN Bridge, thus eliminating the risk of effects to other users and the system overall. |
...
- Use as a Simple Network Gateway
Even setting up the VPN Server and Virtual Hub and remotely connecting to that hub only results in closed communication within the Virtual Hub, so it is possible to communicate with the physical network connected to the computer running the VPN Server. Using local bridging in this case commonly involves a layer 2 connection between the Virtual Hub and the physical network, but using the SecureNAT function enables communication with the network connected to the computer operating the VPN Server via the Virtual Hub's virtual host network interface. Therefore, it is possible to make use of SecureNAT's virtual NAT function when preferring not to use the local bridging function, or unable to use it due to not possessing the computer's System Administrator authority or due to use of a UNIX OS version of the VPN Server or VPN Bridge other than Windows, Linux or Solaris. - As a DHCP Server
Of the SecureNAT functions, it is possible to enable only the DHCP server. In other words, it is possible to use only the DHCP server function operating within the Virtual Hub Ethernet segment. This allows VPN Clients and local bridge destination client computers remotely accessing the Virtual Hub to receive IP addresses assigned by the virtual DHCP server.
Normally, using DHCP automatic IP address assignment requires locally bridging that Virtual Hub to a separate network of the DHCP server or connecting to the Virtual Hub from the DHCP server with the VPN Client using the Virtual Network Adapter, but the SecureNAT function's Virtual DHCP server function eliminates this need. - As a Simple Gateway to Remotely Access Remote Sites
Remote access VPN to a remote site (for instance, sites on which equipment maintenance is to be carried out via the network) using the SoftEther VPN typically involves installing the VPN Server and VPN Bridge on that remote site's computer and connecting to it with a VPN Client or setting up a continuous cascade connection from that site to a VPN Server set up in a separate location, thus enabling communication with a computer node on that remote site using the SoftEther VPN. However, the SecureNAT function can be used as an alternative when a local bridge cannot be set up on a remote site's computer for security or costs limitations or when the OS does not support the SoftEther VPN local bridging function. Please refer to 10.11 Exploit SecureNAT for Remote Access into Firewall without Any Permission for details on these methods of use.
...
- Using Virtual NAT
The use of virtual NAT is recommended for environments running the VPN Server / VPN Bridge without System Administrator authority or OS support for local bridging, i.e. when a computer in the Virtual Hub's layer 2 segment is unable to use the local bridge function and needs to access a physical network host via the physical network interface of the computer actually running the Virtual Hub (particularly where the uses given in 10.11 Exploit SecureNAT for Remote Access into Firewall without Any Permission are applicable).
Where local bridging can be used to connect a Virtual Hub and a physical network and in the absence of security issues, it is not necessary to connect a virtual network to a physical network using the virtual NAT function. - Preventing Connections causing Infinite Looping of Packets
Where a computer with VPN Client installed connects to a virtual NAT-enabled Virtual Hub either from the Virtual Network Adapter of its own Virtual Hub or by local bridging to said hub from a physical Network Adapter, and where the default gateways for those Network Adapters designate IP addresses assigned by the Virtual HUBfs SecureNAT virtual host network interface, communication attempting to connect to an arbitrary IP address tries to use the Virtual Hub's Virtual NAT, which in turn tries to communicate with the destination IP address by calling the operating system's network communication API, resulting in the connection packet falling into an infinite loop. The virtual NAT function is not typically used at the same time as local bridge connections and VPN connections to localhost using the VPN Client. If these types of connections are being made then there is a likelihood that the network design is incorrect. - Precautions relating to Performance
By possessing an internal virtual TCP/IP stack, SecureNAT performs the highly advanced process of reassembling the TCP/IP stream packetized once by the TCP/IP stack and further TCP/IP packetizing via the operating system. The overhead resulting from these processes is large, such that throughput via the virtual NAT is considerably decreased when compared to physical maximum throughput, even when using a computer with sufficiently high speed. That is why virtual NAT should not be used for performance-centric applications. As previously stated, virtual NAT is a function which can be used as an alternative when the local bridge function cannot be used for security or technical reasons. Where high-speed methods such as local bridging are available, those methods should be used. - Handling ICMP Packets
When virtual NAT is enabled, sending ICMP packets via IP addresses assigned by a virtual host network interface as routers, and further sending said packets to a separate host results in the virtual NAT returning dummy ICMP echo response packets to all ICMP echo request packets. This is a specification of the SoftEther VPN whereby this operation becomes inevitable because most operating systems do not allow the transmission of arbitrary ICMP packets in network APIs which can be called up with user authority. When using Virtual NAT it is therefore impossible to confirm the existence of a host on the other side of a Virtual NAT router using ICMP packets. - DNS Redirect
When Virtual NAT is enabled, UDP 53 port destination packets (DNS packets) to the IP address of the virtual host network interface are automatically forwarded to the DNS server being used as the DNS Server by the computer running the Virtual Hub. This is the same operation carried out by typical broadband routers. - Unsupported Functions
The User Mode TCP/IP stack used internally by Virtual NAT is not equipped with some sophisticated TCP/IP functions such as the Window Scale option, Selective ACKs and Nagle algorithms. In addition, the nature of Virtual NAT means that IP routing and NAT between virtual networks is not supported. The virtual layer 3 switch function should be used for inter-virtual network IP routing.
...
