info_i_25x25.png See important information about Ubiquiti Devices and KRACK Vulnerability in this article. We will update this document as more information becomes available.

EdgeRouter - IPsec Site-to-Site VPN Additions and Changes (CLI)

 Overview


Readers will learn how to configure a Policy-Based Site-to-Site IPsec VPN between two EdgeRouters and modifying the default (GUI) settings. This guide should be referenced if you are interested in all the different IPsec options/customization that are configurable in EdgeOS. Please refer to either the EdgeRouter - IPsec Route-Based (VTI) Site-to-Site VPN or the EdgeRouter - IPsec Policy-Based Site-to-Site VPN article.

A Policy-Based VPN is characterized by the definition of local and remote subnets (proxy IDs). This type of VPN differs from a Route-Based VPN which is characterized by the usage of Virtual Tunnel Interfaces (VTIs) and routing entries.

book_25x25.png    NOTES & REQUIREMENTS:

Applicable to EdgeOS 1.9.7 + firmware in all EdgeRouter models. Knowledge of the Command Line Interface (CLI) and advanced networking knowledge is required. Please see the Related Articles below for more information and see the attachments for the configurations used in this article.

 

Equipment used in this article:

- EdgeRouter-X (ER-X)

- Test clients behind the peers (Host1 and Server1)

Table of Contents


  1. Network Diagram
  2. Steps: Policy-Based VPN
  3. Steps: VPN Additions & Changes
  4. Steps: Testing & Verification
  5. Related Articles

Network Diagram


Back to Top

The network topology is shown below. The following interfaces are in use on the EdgeRouters:

ER-Left

  1. eth0 (WAN) - 203.0.113.1
  2. eth1 (LAN) - 192.168.1.1/24

ER-Right

  1. eth0 (WAN) - 192.0.2.1
  2. eth1 (LAN) - 172.16.1.1/24


Steps: Policy-Based VPN


Back to Top

For the purpose of this article it is assumed that the routing and interface configuration is already in place and that reachability has been tested.

The UDP ports and protocols relevant to IPsec are:

  1. UDP 500 (IKE)
  2. ESP (Protocol 50)
  3. UDP 4500 (NAT-T)

The type of VPN that will be created is called a Policy-Based VPN which uses remote and local subnets, otherwise known as proxy IDs. These values need to match exactly between the two peers and need to be mirrored images of each other. Only the prefixes defined in the proxy IDs will be carried over the tunnel. In the example ER-Left has the 192.168.1.0/24 present on the LAN side, whereas the ER-Right side uses 172.16.1.0/24.

The configuration will mainly focus on ER-Left. The configuration of ER-Right will be nearly identical with the exception of the defined subnets. Only the places where the configuration of ER-Right differs will be included in the output below.

www.png  GUI STEPS: Access the router's Web-Management Portal (GUI).

1. Define the IPsec peer and Security Associations (SAs) on ER-Right (replace <secret> with your desired passphrase).

VPN > IPsec Site-to-Site > +Add Peer

  • Show advanced options
  • Uncheck: Automatically open firewall and exclude from NAT
Peer: 192.0.2.1
Description: IPsec
Local IP: 203.0.113.1
Encryption: AES-256
Hash: SHA1
DH Group: 14
Pre-shared Secret: <secret>
Local subnet: 192.168.1.0/24
Remote subnet: 172.16.1.0/24 
info_i_25x25.png Note: The different encryption and hashing choices are discussed in greater detail below. The GUI does not show all of the available options such as SHA256/384/512 and the Galois/Counter Mode (GCM) ciphers.

 

 

2. Define the IPsec peer and Security Associations (SAs) on ER-Left (replace <secret> with your desired passphrase).

VPN > IPsec Site-to-Site > +Add Peer

  • Show advanced options
  • Uncheck: Automatically open firewall and exclude from NAT
Peer: 203.0.113.1
Description: IPsec
Local IP: 192.0.2.1
Encryption: AES-256
Hash: SHA1
DH Group: 14
Pre-shared Secret: <secret>
Local subnet: 172.16.1.0/24 
Remote subnet: 192.168.1.0/24
info_i_25x25.png Note: Because the automatic creation of firewall rules and NAT exclusion has been disabled, the VPN will NOT establish until firewall rules are created manually.

 


Steps: VPN Additions & Changes 


Back to Top

IPsec VPNs consist of two phases that each uses its own set of SAs (hashing/encryption methods). Phase 1 (P1) is used to authenticate the peers and establish the VPN, whereas the actual data (traffic) flows over Phase 2 (P2). Because of this, we can define P2 SAs that focus on performance, and P1 SAs that focus on security. The ground rule of any form of encryption/hashing is that an increase in security will (usually) lead to a decrease in performance.

 

CLI_circle.png  CLI STEPS: Access the command line interface (CLI). You can do this using the CLI button in the GUI or by using a program such as PuTTY.

1. Enter configuration mode.

configure

2. View the function of the automatic firewall and NAT exclusion feature.

The automatic function adds these rules to iptables in the background:

  • Allow UDP port 500 (IKE), UDP port 4500 (NAT-T) and ESP in the local direction.
  • Allow IPsec traffic from the remote subnet to the local subnet in the local and inbound direction.
  • Exclude all traffic from the local subnet to the remote subnet from (source) NAT.

You can verify this with (assuming you checked the 'Automatically open firewall and exclude from NAT' feature):

show vpn
ipsec {
   auto-firewall-nat-exclude enable
}

...

sudo iptables -L -vn
Chain UBNT_VPN_IPSEC_FW_HOOK (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 500,4500
0 0 ACCEPT esp -- * * 0.0.0.0/0 0.0.0.0/0

Chain UBNT_VPN_IPSEC_FW_IN_HOOK (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * * 172.16.1.0/24 192.168.1.0/24

sudo iptables -t nat -L -vn
Chain POSTROUTING (policy ACCEPT 1556 packets, 209K bytes)
pkts bytes target prot opt in out source destination
51461 13M UBNT_VPN_IPSEC_SNAT_HOOK all -- * * 0.0.0.0/0 0.0.0.0/0
21500 2316K MASQUERADE all -- * eth0 0.0.0.0/0 0.0.0.0/0 /* NAT-5010 */

Chain UBNT_VPN_IPSEC_SNAT_HOOK (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * * 192.168.1.0/24 172.16.1.0/24
info_i_25x25.png Note: If you have previously enabled the ‘automatic firewall and NAT exclusion' feature and want to turn it off, you will need to reboot the device to get rid of the iptables rules.

3. Manually add firewall rules for IKE, NAT-T, ESP and IPsec (local direction).

warning_25x25.png Attention: Make sure that these firewall rules do not override your existing rules (same applies to the firewall creation in step 4). Verify which rules are in place with the show firewall name WAN_LOCAL configuration mode statement, or by looking in the GUI under Firewall/NAT > Firewall Policies >
WAN_LOCAL > Actions > Edit Ruleset.
set firewall name WAN_LOCAL rule 30 action accept
set firewall name WAN_LOCAL rule 30 description IKE
set firewall name WAN_LOCAL rule 30 destination port 500
set firewall name WAN_LOCAL rule 30 log disable
set firewall name WAN_LOCAL rule 30 protocol udp

set firewall name WAN_LOCAL rule 40 action accept
set firewall name WAN_LOCAL rule 40 description ESP
set firewall name WAN_LOCAL rule 40 log disable
set firewall name WAN_LOCAL rule 40 protocol esp

set firewall name WAN_LOCAL rule 50 action accept
set firewall name WAN_LOCAL rule 50 description NAT-T
set firewall name WAN_LOCAL rule 50 destination port 4500
set firewall name WAN_LOCAL rule 50 log disable
set firewall name WAN_LOCAL rule 50 protocol udp

set firewall name WAN_LOCAL rule 60 action accept
set firewall name WAN_LOCAL rule 60 description IPsec
set firewall name WAN_LOCAL rule 60 destination address 192.168.1.0/24
set firewall name WAN_LOCAL rule 60 source address 172.16.1.0/24
set firewall name WAN_LOCAL rule 60 log disable
set firewall name WAN_LOCAL rule 60 ipsec match-ipsec
info_i_25x25.png Note: The name of the local firewall rule applied to the WAN interface might be different in your environment. Whatever the naming scheme, make sure that the correct firewall rule is applied under the WAN interface.

4. Manually add firewall rules for IPsec traffic between the subnets (inbound direction).

set firewall name WAN_IN rule 30 action accept
set firewall name WAN_IN rule 30 description IPsec
set firewall name WAN_IN rule 30 destination address 192.168.1.0/24
set firewall name WAN_IN rule 30 source address 172.16.1.0/24
set firewall name WAN_IN rule 30 log disable
set firewall name WAN_IN rule 30 ipsec match-ipsec

5. Exclude the traffic between the subnets from being translated by NAT.

set service nat rule 5000 description IPsec
set service nat rule 5000 destination address 172.16.1.0/24
set service nat rule 5000 exclude
set service nat rule 5000 outbound-interface eth0
set service nat rule 5000 protocol all
set service nat rule 5000 source address 192.168.1.0/24
set service nat rule 5000 type masquerade

6. Display the current IPsec VPN SA configuration (only relevant output is shown).

show vpn
ipsec {
auto-firewall-nat-exclude disable
   esp-group FOO0 {
       proposal 1 {
           encryption aes256
hash sha1
       }
}
   esp-group FOO0 {
       proposal 1 {
dh-group 14
           encryption aes256
hash sha1
       }
}
}
...

As is shown in the output above, both P1 (ike-group FOO0) and P2 (esp-group FOO0) use the same set of SAs (AES256 and SHA1).

7. Change the P1 and P2 Security Associations (SAs) on ER-Left and ER-Right.

set vpn ipsec esp-group FOO0 proposal 1 encryption aes128
set vpn ipsec esp-group FOO0 proposal 1 hash md5

set vpn ipsec ike-group FOO0 proposal 1 encryption aes256
set vpn ipsec ike-group FOO0 proposal 1 hash sha256

Available encryption options:

  • AES128 - Recommended for P2 (ESP), faster than AES256
  • AES256 - Recommended for P1 (IKE), more secure than AES128
  • AES128GCM128 - Not recommended for P2 (ESP), currently incompatible with offloading
  • AES256GCM128 - Not recommended for P2 (ESP), currently incompatible with offloading
  • 3DES - Not recommended, insecure.

Available hashing options:

  • MD5 - Recommended for P2 (ESP), faster than SHA1
  • SHA1 - Good candidate for P2 (ESP), more secure but slower than MD5
  • SHA2-256 - Recommended for P1 (IKE), more secure than SHA1/MD5, not recommended P2 (ESP)
  • SHA2-384 - Not recommended P2 (ESP), currently incompatible with offloading
  • SHA2-512 - Not recommended P2 (ESP), currently incompatible with offloading
info_i_25x25.png Note: Using the Galois/Counter Mode (GCM) ciphers and SHA256/384/512 for P2 (ESP) is not recommended as it is not compatible with IPsec offloading. More information about the functionality of EdgeRouter offloading can be found in the Ubiquiti Hardware Offloading article. The offloading of IPsec traffic only applies to P2 (ESP) traffic. For this reason you can use SHA256 for P1 for example without affecting the performance. 

8. Change the ESP/IKE lifetimes (in seconds) so that the tunnel renegotiates less frequently.

set vpn ipsec esp-group FOO0 lifetime 43200
set vpn ipsec ike-group FOO0 lifetime 86400

9. Disable Perfect Forward Secrecy (PFS) so that the tunnel renegotiates less frequently.

set vpn ipsec esp-group FOO0 pfs disable

10. Change the IKE Key Exchange from version 1 to version 2.

set vpn ipsec ike-group FOO0 key-exchange ikev2

11. Change the IKE Key Exchange to Aggressive Mode (not recommended).

set vpn ipsec ike-group FOO0 mode aggressive

12. Change the IPsec connection type.

set vpn ipsec site-to-site peer 192.0.2.1 connection-type respond
info_i_25x25.png Note: This mainly influences how many times a non-functional connection is renegotiated (keyingtries). With respond this value is set to 1 retry, with initiate the connection is retried indefinitely. You can safely change this value if you are having trouble with the stability of the VPN or you are connecting to a non-EdgeMAX peer (it is a locally significant value).

13. Force the use of NAT-T (UDP 4500 encapsulation).

set vpn ipsec site-to-site peer 192.0.2.1 force-encapsulation enable

This option forces ESP to always be encapsulated into UDP4500, even if no NAT situation is detected. Forcing encapsulation can lead to performance increases in some areas and help circumvent restrictive firewall policies.

14. Change the local IPsec interface address.

Use the following command to specify the local IP address to be used as the source for IPsec packets destined for the remote peer. The dhcp-interface and local-address statements CANNOT be used simultaneously. Decide on which command is best for your situation using these options:

 

(A) You are using multiple WAN interfaces and want the VPN to respond on multiple interfaces.

With this statement any IPv4 address present on the system can be used as the source of the VPN. This configuration CANNOT be used with a Route-Based (VTI) IPsec VPN. You can also use this command if your WAN interface receives an address through PPPoE.

set vpn ipsec site-to-site peer 192.0.2.1 local-address 0.0.0.0
info_i_25x25.png Note: We currently recommend using local-address 0.0.0.0 over local-address any. In some scenarios you can also use local-address default which uses the interface that has an outgoing default route (0.0.0.0/0).

(B) Your WAN interface receives an address through DHCP.

delete vpn ipsec site-to-site peer 192.0.2.1 local-address
set vpn ipsec site-to-site peer 192.0.2.1 dhcp-interface eth0

15. Change the peer address to 0.0.0.0 if the remote peer is behind NAT (or uses DynDNS).

If for example, ER-X-Right is behind NAT, you can configure the peer address to 0.0.0.0 on ER-X-Left. The left router will not initiate any tunnels (because the router doesn’t know who the peer is), but will respond to any requests. You will need to recreate the rest of the configuration as well.

delete vpn ipsec site-to-site peer 192.0.2.1
set vpn ipsec site-to-site peer 0.0.0.0 …

info_i_25x25.png Note: In the case of DynDNS you can choose to connect using the FQDN (hostname) of the peer or by using 0.0.0.0.

 

A local IPsec L2TP server must not be configured if the IPsec site-to-site peer address is set to 0.0.0.0. Neither protocol will function properly in this scenario because it is unclear whether the incoming IKE connection requests are from a site-to-site client with a dynamic IP address, or an L2TP remote access client.

16. Enable Dead Peer Detection.

Unlike a Route-Based VPN, a Policy-Based VPN will only initiate P2 when traffic is detected. Dead Peer Detection (DPD) is a method to send ‘keepalive’ messages over the tunnel to keep the tunnel established.

set vpn ipsec ike-group FOO0 dead-peer-detection action [ hold | clear | restart ]
set vpn ipsec ike-group FOO0 dead-peer-detection interval 30 (default)
set vpn ipsec ike-group FOO0 dead-peer-detection timeout 120 (default)

(B) Your WAN interface receives an address through DHCP.

delete vpn ipsec site-to-site peer 192.0.2.1 local-address
set vpn ipsec site-to-site peer 192.0.2.1 dhcp-interface eth0
  • hold - The VPN state is put ‘on-hold’ but the policies are kept until traffic is reinitiated
  • clear - The VPN state and policies are cleared and the tunnel is torn down
  • restart - The VPN state and policies are restarted and the router attempts to renegotiate the tunnel

The DPD interval is the time in seconds after which these messages start. The timeout is the number of seconds the messages are resent after a failed attempt.

info_i_25x25.png Note: There is no need for DPD when IKEv2 is used.

17. Commit the changes and save the configuration.

commit ; save
warning_25x25.png Attention: There are some IPsec related commands that have been deprecated in later firmware. The commands below have been deprecated in EdgeOS firmware v1.8.5 and v1.8.0. More information can be found under the 'Enhancements and bug fixes' sections in the EdgeMAX EdgeRouter software releases.

The deprecated IPsec commands are listed below:

set vpn ipsec ipsec-interfaces interface eth0
set vpn ipsec nat-traversal enable
set vpn ipsec nat-networks allowed-network 0.0.0.0/0

Steps: Testing & Verification


Back to Top

After configuring the IPsec VPN, verify the connection/state using the following commands.

1. Verify the IPsec Security Associations (SAs) and status on the ER:

show vpn ipsec sa
peer-192.0.2.1-tunnel-1: #1, ESTABLISHED, IKEv1, 184447c009d51f80:14cc0f13aff401c0
local '203.0.113.1' @ 203.0.113.1
remote '192.0.2.1' @ 192.0.2.1
AES_CBC-256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
established 237s ago, reauth in 85347s
peer-192.0.2.1-tunnel-1: #1, INSTALLED, TUNNEL, ESP:AES_CBC-128/HMAC_MD5_96
installed 237 ago, rekeying in 41939s, expires in 42964s
in cb321982, 180 bytes, 3 packets, 231s ago
out 5d4174b1, 180 bytes, 3 packets, 231s ago
local 192.168.1.0/24
remote 172.16.1.0/24

sudo ipsec statusall
Status of IKE charon daemon (strongSwan 5.2.2, Linux 3.10.14-UBNT, mips):
uptime: 10 minutes, since Mar 12 09:05:48 2017
malloc: sbrk 376832, mmap 0, used 269320, free 107512
worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 2
Listening IP addresses:
203.0.113.1
192.168.1.1
Connections:
peer-192.0.2.1-tunnel-1: 203.0.113.1...192.0.2.1 IKEv1
peer-192.0.2.1-tunnel-1: local: [203.0.113.1] uses pre-shared key authentication
peer-192.0.2.1-tunnel-1: remote: [192.0.2.1] uses pre-shared key authentication
peer-192.0.2.1-tunnel-1: child: 192.168.1.0/24 === 172.16.1.0/24 TUNNEL
Routed Connections:
peer-192.0.2.1-tunnel-1{1}: ROUTED, TUNNEL
peer-192.0.2.1-tunnel-1{1}: 192.168.1.0/24 === 172.16.1.0/24
Security Associations (1 up, 0 connecting):
peer-192.0.2.1-tunnel-1[1]: ESTABLISHED 5 minutes ago, 203.0.113.1[203.0.113.1]...192.0.2.1[192.0.2.1]
peer-192.0.2.1-tunnel-1[1]: IKEv1 SPIs: 184447c009d51f80_i* 14cc0f13aff401c0_r, pre-shared key reauthentication in 23 hours
peer-192.0.2.1-tunnel-1[1]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
peer-192.0.2.1-tunnel-1{1}: INSTALLED, TUNNEL, ESP SPIs: cb321982_i 5d4174b1_o
peer-192.0.2.1-tunnel-1{1}: AES_CBC_128/HMAC_MD5_96, 180 bytes_i (3 pkts, 324s ago), 180 bytes_o (3 pkts, 324s ago)
peer-192.0.2.1-tunnel-1{1}: 192.168.1.0/24 === 172.16.1.0/24

2. Verify the ER IPsec strongSwan configuration:

sudo cat /etc/ipsec.conf
# generated by /opt/vyatta/sbin/vpn-config.pl


config setup

conn %default
       keyexchange=ikev1

conn peer-192.0.2.1-tunnel-1
       left=203.0.113.1
       right=192.0.2.1
       leftsubnet=192.168.1.0/24
       rightsubnet=172.16.1.0/24
       ike=aes256-sha256-modp2048!
       keyexchange=ikev1
       ikelifetime=86400s
       esp=aes128-md5!
       keylife=43200s
       rekeymargin=540s
       type=tunnel
       compress=no
       authby=secret
       auto=route
       keyingtries=%forever
#conn peer-192.0.2.1-tunnel-1

3. Capture the arrival of IKE traffic on the ER external WAN interface:

sudo tcpdump -i eth0 -n udp dst port 500   
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
IP 203.0.113.1.500 > 192.0.2.1.500: isakmp: phase 1 I ident
IP 192.0.2.1.500 > 203.0.113.1.500: isakmp: phase 1 R ident
IP 203.0.113.1.500 > 192.0.2.1.500: isakmp: phase 1 I ident[E]
IP 192.0.2.1.500 > 203.0.113.1.500: isakmp: phase 1 R ident[E]
IP 203.0.113.1.500 > 192.0.2.1.500: isakmp: phase 2/others I oakley-quick[E]
IP 192.0.2.1.500 > 203.0.113.1.500: isakmp: phase 2/others R oakley-quick[E]
info_i_25x25.png Note: This is a live capture. If there is no output that means that the traffic is either not being generated on the client, or there is something blocking the traffic upstream.

4. Capture the ER IPsec VPN logs:

sudo swanctl --log
[KNL] creating acquire job for policy 192.168.1.10/32[icmp/8] === 172.16.1.10/32[icmp/8] with reqid {1}

[IKE] initiating Main Mode IKE_SA peer-192.0.2.1-tunnel-1[1] to 192.0.2.1
[ENC] generating ID_PROT request 0 [ SA V V V V ]
[NET] sending packet: from 203.0.113.1[500] to 192.0.2.1[500] (160 bytes)
[NET] received packet: from 192.0.2.1[500] to 203.0.113.1[500] (108 bytes)
[ENC] parsed ID_PROT response 0 [ SA V ]
[IKE] received NAT-T (RFC 3947) vendor ID
[ENC] generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
[ENC] parsed ID_PROT response 0 [ KE No V V V V NAT-D NAT-D ]
[ENC] generating ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ]
[ENC] parsed ID_PROT response 0 [ ID HASH ]
[IKE] IKE_SA peer-192.0.2.1-tunnel-1[1] established between 203.0.113.1[203.0.113.1]...192.0.2.1[192.0.2.1]
[ENC] generating QUICK_MODE request 561157166 [ HASH SA No ID ID ]
[ENC] parsed QUICK_MODE response 561157166 [ HASH SA No ID ID N((24576)) ]
[IKE] CHILD_SA peer-192.0.2.1-tunnel-1{1} established with SPIs cb321982_i 5d4174b1_o and TS 192.168.1.0/24 === 172.16.1.0/24
info_i_25x25.png Note: This is also live capture. If there is no output that means that the traffic is either not being allowed through the firewall. Alternatively you can use the show vpn log | no-more command to view the entire IPsec log history.

5. Verify the state and counters of the firewall and NAT rules (if created):

show firewall name WAN_LOCAL statistics 
----------------------------------------------
IPv4 Firewall "WAN_LOCAL" [WAN to router]

Active on (eth0,LOCAL)

rule packets bytes action description
---- ------- ----- ------ -----------
10 2364 203306 ACCEPT Allow established/related
20 0 0 DROP Drop invalid state
30 1 188 ACCEPT IKE
40 2 240 ACCEPT ESP
50 0 0 ACCEPT NAT-T
60 2 112 ACCEPT IPsec
10000 9 1692 DROP DEFAULT ACTION

show firewall name WAN_IN statistics
------------------------------------
IPv4 Firewall "WAN_IN" [WAN to internal]

Active on (eth0,IN)

rule packets bytes action description
---- ------- ----- ------ -----------
10 30 1784 ACCEPT Allow established/related
20 0 0 DROP Drop invalid state
30 2 120 ACCEPT IPsec
10000 1 60 DROP DEFAULT ACTION

show nat statistics
rule count type IN OUT description
---- ---------- ---- -------- -------- -----------
5000 30 MASQ - eth0 IPsec
5010 2752 MASQ - eth0 masquerade for WAN

6. Send traffic over the tunnel from Server1 to Host1 and vice versa:

ping 192.168.1.10
PING 192.168.1.10 (192.168.1.10) 56(84) bytes of data.

64 bytes from 192.168.1.10: icmp_seq=1 ttl=63 time=45.9 ms
64 bytes from 192.168.1.10: icmp_seq=2 ttl=63 time=45.2 ms
64 bytes from 192.168.1.10: icmp_seq=3 ttl=63 time=45.5 ms

ping 172.16.1.10
PING 172.16.1.10 (172.16.1.10) 56(84) bytes of data.

64 bytes from 172.16.1.10: icmp_seq=1 ttl=63 time=43.9 ms
64 bytes from 172.16.1.10: icmp_seq=2 ttl=63 time=44.1 ms
64 bytes from 172.16.1.10: icmp_seq=3 ttl=63 time=44.4 ms

Related Articles


Back to Top