EdgeRouter - IPsec Policy-Based Site-to-Site VPN to pfSense

 Overview


Readers will learn how to configure a Policy-Based Site-to-Site IPsec VPN between an EdgeRouter and pfSense.

A Policy-Based VPN is characterized by the definition of local and remote subnets (Proxy IDs) and the usage of IKEv1 when connecting to Azure. 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), pfSense and advanced networking skills are required. Please see the Related Articles below for more information.

 

Equipment used in this article:

EdgeRouter X (ER-X)

- pfSense Community Edition 2.3.4 (i386)

- Test clients behind the peers (Host1, Host2 and Server1)


Table of Contents


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


Network Diagram


Back to Top

The network topology is shown below. The following interfaces / IP addresses are in use on the EdgeRouter (ER) and Azure VPN Gateway (GW):

ER-X

  • eth0 (WAN) - 203.0.113.1
  • eth1 (LAN) - 192.168.1.1/24
  • eth2 (LAN) - 10.0.1.1/24

pfSense

  • em0 (WAN) - 192.0.2.1
  • em1 (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 has the 192.168.1.0/24 and 10.0.1.0/24 present on the LAN side, whereas pfSense uses 172.16.1.0/24. This means that two tunnels need to be created between the peers.

The first part of the configuration focuses on the ER, afterwards the gateway will be set up in pfSense.

info_i_25x25.png Note: It is currently not possible to configure Route-Based (VTI) IPsec site-to-site VPNs on pfSense. 

 

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

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

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

  • Show advanced options
  • 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

+Add Subnets

Local subnet: 10.0.1.0/24
Remote subnet: 172.16.1.0/24

 

 

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. Display the current IPsec VPN peer configuration (only relevant output is shown).

show vpn
ipsec {

   esp-group FOO0 {
       lifetime 3600
       pfs enable
       proposal 1 {
           encryption aes256
           hash sha1
       }
   }
   ike-group FOO0 {
       key-exchange ikev1
       lifetime 28800
       proposal 1 {
           dh-group 14
           encryption aes256
           hash sha1
       }
   }
... 
info_i_25x25.png Note: The choices for SAs in this example are based on optimizing the VPN for performance, stability and security. The IKE proposal focuses on security (AES256 + SHA256), whereas the ESP proposal focuses on performance (AES128 + MD5). Whatever set of SAs are chosen, make sure that the settings for Phase 1 (P1) and Phase 2 (P2) match on both sides of the connection.

3. Change the IKE proposal (P1) and Security Associations (SAs).

set vpn ipsec ike-group FOO0 lifetime 86400
set vpn ipsec ike-group FOO0 proposal 1 hash sha256

4. Change the ESP proposal (P2) and Security Associations (SAs).

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

5. Disable Perfect Forward Secrecy (PFS).

set vpn ipsec esp-group FOO0 pfs disable

6. (Optional) 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. 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

(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

7. (Optional) Enable the IPsec offloading feature to increase ESP (not IKE) performance.

set system offload ipsec enable (this requires a reboot to become active) 

8. Commit the changes.

commit

9. Save the configuration.

save

Steps - Azure Gateway


Back to Top

Please make sure that the latest stable version of pfSense is being used and that the device is capable of reaching the internet. The version used in this article is the pfSense 2.3.4 Community Edition (CE) running on the i386 (32-bit) architecture in VMware (pfSense-CE-2.3.4-RELEASE-i386). The pfSense side of the Site-to-Site VPN connection is based on the IPsec article linked below:

VPN Capability IPsec

 

www.png  GUI STEPS: Access the pfSense Management Interface (GUI).

1. Add the firewall rules for the relevant IPsec ports and protocols.

Firewall > Rules > WAN > Add

Action: Pass
Interface: WAN
Address Family: IPv4
Protocol: UDP
Source: any
Destination: any
Destination Port Range: From ISAKMP (500) to ISAKMP (500)
Description: IKE

Action: Pass
Interface: WAN
Address Family: IPv4
Protocol: ESP
Source: any
Destination: any
Description: ESP

Action: Pass
Interface: WAN
Address Family: IPv4
Protocol: UDP
Source: any
Destination: any
Destination Port Range: From IPsec NAT-T (4500) to IPsec NAT-T (4500)
Description: NAT-T

2. Define the P1 IKE settings (replace <secret> with your desired passphrase).

VPN > IPsec > Tunnels > + Add P1

Key Exchange Version: IKEv1
Internet Protocol: IPv4
Interface: WAN
Remote Gateway: 203.0.113.1
Description: IPsec

Authentication Method: Mutual PSK
Negotiation Mode: Main
My Identifier: My IP address
Peer Identifier: Peer IP address
Pre-Shared Key: <secret>

Encryption Algorithm: AES 256 bits
Hash Algorithm: SHA256
DH Group: 14 (2048 bit)
Lifetime (Seconds): 86400

Uncheck 'Dead Peer Detection'
NAT Traversal: Auto

3. Save the P1 IKE settings.

 

info_i_25x25.png Note: If you are using IKEv2, make sure to check ‘Split Connections’. Otherwise pfSense will try to route both networks over a single tunnel, whereas the ER will try to use two tunnels.

4. Define the P2 ESP setting for the first tunnel.

VPN > IPsec > Tunnels > Show Phase 2 Entries > +Add P2

Mode: Tunnel IPv4
Local Network: Network 172.16.1.0/24
NAT/BINAT Translation: None
Remote Network: Network 192.168.1.0/24

Protocol: ESP
Encryption Algorithms: AES 128 bits
Hash Algorithms: MD5 (uncheck SHA1)
PFS Key Group: off
Lifetime: 43200

5. Save the P2 ESP settings for the first tunnel.

6. Define the P2 ESP setting for the second tunnel.

VPN > IPsec > Tunnels > Show Phase 2 Entries > +Add P2

Mode: Tunnel IPv4
Local Network: Network 172.16.1.0/24
NAT/BINAT Translation: None
Remote Network: Network 10.0.1.0/24

Protocol: ESP
Encryption Algorithms: AES 128 bits
Hash Algorithms: MD5 (uncheck SHA1)
PFS Key Group: off
Lifetime: 43200

7. Save the P2 ESP settings for the second tunnel.

8. Enable both the P1 and P2 tunnels by clicking on ‘Enable’ (if not already enabled).

9. Apply the changes.

 

info_i_25x25.png Note: The output should look like the image above. A green button that displays ‘Enable’ means that IPsec is NOT enabled.

10. Verify that the IPsec process has started.

Status > Services

11. Add a firewall rule to permit IPsec traffic from the remote subnet to the local subnet for the first and second tunnel.

Firewall > Rules > IPsec > Add

Action: Pass
Interface: IPsec
Address Family: IPv4
Protocol: Any
Source: Network 192.168.1.0/24
Destination: Network 172.16.1.0/24

Action: Pass
Interface: IPsec
Address Family: IPv4
Protocol: Any
Source: Network 10.0.1.0/24
Destination: Network 172.16.1.0/24

11. Add a firewall rule to permit IPsec traffic from the remote subnet to the local subnet for the first and second tunnel.

 


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: #4, ESTABLISHED, IKEv1, 13c7358806637c9a:273821a382aa6025

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 186s ago, reauth in 85238s
peer-192.0.2.1-tunnel-1: #1, INSTALLED, TUNNEL, ESP:AES_CBC-128/HMAC_MD5_96
installed 186 ago, rekeying in 42449s, expires in 43014s
in c92300a0, 420 bytes, 7 packets, 153s ago
out c11f0c6c, 540 bytes, 9 packets, 153s ago
local 192.168.1.0/24
remote 172.16.1.0/24
peer-192.0.2.1-tunnel-2: #2, INSTALLED, TUNNEL, ESP:AES_CBC-128/HMAC_MD5_96
installed 166 ago, rekeying in 41989s, expires in 43034s
in cff79744, 360 bytes, 6 packets, 87s ago
out c1461735, 720 bytes, 12 packets, 87s ago
local 10.0.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: 27 minutes, since Jan 02 04:02:43 2015
malloc: sbrk 376832, mmap 0, used 273520, free 103312
worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 4
Listening IP addresses:
203.0.113.1
192.168.1.1
10.0.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
peer-192.0.2.1-tunnel-2: child: 10.0.1.0/24 === 172.16.1.0/24 TUNNEL
Routed Connections:
peer-192.0.2.1-tunnel-2{2}: ROUTED, TUNNEL
peer-192.0.2.1-tunnel-2{2}: 10.0.1.0/24 === 172.16.1.0/24
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[5]: ESTABLISHED 2 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[5]: IKEv1 SPIs: d5f32fbc2a3954aa_i* b77873a4d9f9a023_r, pre-shared key reauthentication in 23 hours
peer-192.0.2.1-tunnel-1[5]: 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: c1ff794a_i c7f2ce03_o
peer-192.0.2.1-tunnel-1{1}: AES_CBC_128/HMAC_MD5_96, 3840 bytes_i (64 pkts, 108s ago), 3840 bytes_o (64 pkts, 108s ago)
peer-192.0.2.1-tunnel-1{1}: 192.168.1.0/24 === 172.16.1.0/24
peer-192.0.2.1-tunnel-2{2}: INSTALLED, TUNNEL, ESP SPIs: c65139f1_i cc099181_o
peer-192.0.2.1-tunnel-2{2}: AES_CBC_128/HMAC_MD5_96, 120 bytes_i (2 pkts, 1s ago), 120 bytes_o (2 pkts, 1s ago)
peer-192.0.2.1-tunnel-2{2}: 10.0.1.0/24 === 172.16.1.0/24

2. Verify the pfSense IPsec Security Associations (SAs) and status:

3. 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

conn peer-192.0.2.1-tunnel-2
left=203.0.113.1
right=192.0.2.1
leftsubnet=10.0.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-2

4. Verify the pfSense IPsec strongSwan configuration and process:

cat /var/etc/ipsec/ipsec.conf
# This file is automatically generated. Do not edit
config setup
uniqueids = yes

conn bypasslan
leftsubnet = 172.16.1.0/24
rightsubnet = 172.16.1.0/24
authby = never
type = passthrough
auto = route

conn con1000
fragmentation = yes
keyexchange = ikev1
reauth = yes
forceencaps = no
mobike = no

rekey = yes
installpolicy = yes
type = tunnel
dpdaction = none
auto = route
left = 192.0.2.1
right = 203.0.113.1
leftid = 192.0.2.1
ikelifetime = 86400s
lifetime = 43200s
ike = aes256-sha256-modp2048!
esp = aes128-md5,aes128-md5!
leftauth = psk
rightauth = psk
rightid = 203.0.113.1
aggressive = no
rightsubnet = 192.168.1.0/24
leftsubnet = 172.16.1.0/24

conn con1001
fragmentation = yes
keyexchange = ikev1
reauth = yes
forceencaps = no
mobike = no

rekey = yes
installpolicy = yes
type = tunnel
dpdaction = none
auto = route
left = 192.0.2.1
right = 203.0.113.1
leftid = 192.0.2.1
ikelifetime = 86400s
lifetime = 43200s
ike = aes256-sha256-modp2048!
esp = aes128-md5,aes128-md5!
leftauth = psk
rightauth = psk
rightid = 203.0.113.1
aggressive = no
rightsubnet = 10.0.1.0/24
leftsubnet = 172.16.1.0/24

ipsec statusall
Status of IKE charon daemon (strongSwan 5.5.1, FreeBSD 10.3-RELEASE-p19, i386):
uptime: 37 minutes, since Aug 17 12:20:00 2017
worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 2
Listening IP addresses:
192.0.2.1
172.16.1.1
Connections:
bypasslan: %any...%any IKEv1/2
bypasslan: local: uses public key authentication
bypasslan: remote: uses public key authentication
bypasslan: child: 172.16.1.0/24|/0 === 172.16.1.0/24|/0 PASS
con1000: 192.0.2.1...203.0.113.1 IKEv1
con1000: local: [192.0.2.1] uses pre-shared key authentication
con1000: remote: [203.0.113.1] uses pre-shared key authentication
con1000: child: 172.16.1.0/24|/0 === 192.168.1.0/24|/0 TUNNEL
con1001: child: 172.16.1.0/24|/0 === 10.0.1.0/24|/0 TUNNEL
Shunted Connections:
bypasslan: 172.16.1.0/24|/0 === 172.16.1.0/24|/0 PASS
Routed Connections:
con1001{11}: ROUTED, TUNNEL, reqid 11
con1001{11}: 172.16.1.0/24|/0 === 10.0.1.0/24|/0
con1000{10}: ROUTED, TUNNEL, reqid 10
con1000{10}: 172.16.1.0/24|/0 === 192.168.1.0/24|/0
Security Associations (1 up, 0 connecting):
con1000[5]: ESTABLISHED 9 minutes ago, 192.0.2.1[192.0.2.1]...203.0.113.1[203.0.113.1]
con1000[5]: IKEv1 SPIs: 9a7c63068835c713_i 2560aa82a3213827_r*, pre-shared key reauthentication in 23 hours
con1000[5]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
con1000{12}: INSTALLED, TUNNEL, reqid 10, ESP SPIs: c11f0c6c_i c92300a0_o
con1000{12}: AES_CBC_128/HMAC_MD5_96, 540 bytes_i (9 pkts, 566s ago), 840 bytes_o (7 pkts, 566s ago)
con1000{12}: 172.16.1.0/24|/0 === 192.168.1.0/24|/0
con1001{13}: INSTALLED, TUNNEL, reqid 11, ESP SPIs: c1461735_i cff79744_o
con1001{13}: AES_CBC_128/HMAC_MD5_96, 720 bytes_i (12 pkts, 500s ago), 720 bytes_o (6 pkts, 500s ago)
con1001{13}: 172.16.1.0/24|/0 === 10.0.1.0/24|/0

5. 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.

6. 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[4] 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] (140 bytes)
[ENC] parsed ID_PROT response 0 [ SA V V V ]
[IKE] received XAuth vendor ID
[IKE] received DPD vendor ID
[IKE] received NAT-T (RFC 3947) vendor ID
[ENC] generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
[NET] sending packet: from 203.0.113.1[500] to 192.0.2.1[500] (396 bytes)
[NET] received packet: from 192.0.2.1[500] to 203.0.113.1[500] (396 bytes)
[ENC] parsed ID_PROT response 0 [ KE No NAT-D NAT-D ]
[ENC] generating ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ]
[NET] sending packet: from 203.0.113.1[500] to 192.0.2.1[500] (108 bytes)
[NET] received packet: from 192.0.2.1[500] to 203.0.113.1[500] (92 bytes)
[ENC] parsed ID_PROT response 0 [ ID HASH ]
[IKE] IKE_SA peer-192.0.2.1-tunnel-1[4] established between 203.0.113.1[203.0.113.1]...192.0.2.1[192.0.2.1]
[IKE] scheduling reauthentication in 85424s
[IKE] maximum IKE_SA lifetime 85964s
[ENC] generating QUICK_MODE request 3938124991 [ HASH SA No ID ID ]
[NET] sending packet: from 203.0.113.1[500] to 192.0.2.1[500] (188 bytes)
[NET] received packet: from 192.0.2.1[500] to 203.0.113.1[500] (188 bytes)
[ENC] parsed QUICK_MODE response 3938124991 [ HASH SA No ID ID ]
[IKE] CHILD_SA peer-192.0.2.1-tunnel-1{1} established with SPIs c9200a0_i c11f0c6c_o and TS 192.168.1.0/24 === 172.16.1.0/24
[ENC] generating QUICK_MODE request 3938124991 [ HASH ]
[NET] sending packet: from 203.0.113.1[500] to 192.0.2.1[500] (76 bytes)
[NET] received packet: from 192.0.2.1[500] to 203.0.113.1[500] (188 bytes)
[ENC] parsed QUICK_MODE request 3677282270 [ HASH SA No ID ID ]
[ENC] generating QUICK_MODE response 3677282270 [ HASH SA No ID ID ]
[NET] sending packet: from 203.0.113.1[500] to 192.0.2.1[500] (188 bytes)
[NET] received packet: from 192.0.2.1[500] to 203.0.113.1[500] (76 bytes)
[ENC] parsed QUICK_MODE request 3677282270 [ HASH ]
[IKE] CHILD_SA peer-192.0.2.1-tunnel-2{2} established with SPIs cff9744_i c1461735_o and TS 10.0.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.

7. Send traffic over the tunnel from Server1 to Host1 and Host2 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=45.9 ms
64 bytes from 172.16.1.10: icmp_seq=2 ttl=63 time=45.2 ms
64 bytes from 172.16.1.10: icmp_seq=3 ttl=63 time=45.5 ms

ping 10.0.1.10
PING 10.0.1.10 (10.0.1.10) 56(84) bytes of data.
64 bytes from 10.0.1.10: icmp_seq=1 ttl=63 time=43.9 ms
64 bytes from 10.0.1.10: icmp_seq=2 ttl=63 time=44.1 ms
64 bytes from 10.0.1.10: icmp_seq=3 ttl=63 time=44.4 ms


Related Articles


Back to Top