This section discusses the packet overhead associated with using a PPP over SSH VPN tunnel. We will use a UDP DNS query packet to examine the average packet overhead. The DNS lookup utility: dig (domain information groper) is used to generate the DNS query packet. The network diagram shown in Figure 7.3, “VPN: PPP tunneled over SSH: packet flow through the IP stacks (Network Diagram)” will be used as the reference network setup for the overhead discussion. A VPN tunnel is establish between 2 private networks through host probe: A (10.222.222.84) and host probe: B (172.16.1.77). The dig command: "dig @172.16.1.20 thunder.unifiedholdings.com" is issued on host: probe: A
Figure 7.4, “VPN: PPP tunneled over SSH: packet flow through the IP stacks” demonstrates the flow through the IP stacks that the DNS query packet must traverse before physically being sent out the network adapter on probe: A network interface: eth0 to the VPN tunnel. The blue shaded area shown on the network diagram in Figure 7.3, “VPN: PPP tunneled over SSH: packet flow through the IP stacks (Network Diagram)” graphical represents the extent of the packet flow discussion. When the packet reaches the VPN tunnel endpoint at probe: B, it will be decrypted, uncompressed, and then forwarded to the DNS server: 172.16.1.20.
We have used the wireshark network protocol analyzer to capture the packet on both the network interface: eth0 and virtual interface: ppp0 on probe: A.
Figure 7.5. Ethereal capture: interface ppp0
Frame 1 (89 bytes on wire, 89 bytes captured)
Arrival Time: Feb 2, 2004 09:57:24.410147000
Time delta from previous packet: 0.000000000 seconds
Time since reference or first frame: 0.000000000 seconds
Frame Number: 1
Packet Length: 89 bytes
Capture Length: 89 bytes
Linux cooked capture
Packet type: Sent by us (4)
Link-layer address type: 512
Link-layer address length: 0
Source: <MISSING>
Protocol: IP (0x0800)
Internet Protocol, Src Addr: 172.16.1.34 (172.16.1.34), Dst Addr: THUNDER (172.16.1.20)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 73
Identification: 0x0000 (0)
Flags: 0x04
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: UDP (0x11)
Header checksum: 0xe04d (correct)
Source: 172.16.1.34 (172.16.1.34)
Destination: THUNDER (172.16.1.20)
User Datagram Protocol, Src Port: 32770 (32770), Dst Port: domain (53)
Source port: 32770 (32770)
Destination port: domain (53)
Length: 53
Checksum: 0x5e49 (correct)
Domain Name System (query)
Transaction ID: 0x1db9
Flags: 0x0100 (Standard query)
0... .... .... .... = Response: Message is a query
.000 0... .... .... = Opcode: Standard query (0)
.... ..0. .... .... = Truncated: Message is not truncated
.... ...1 .... .... = Recursion desired: Do query recursively
.... .... .0.. .... = Z: reserved (0)
.... .... ...0 .... = Non-authenticated data OK: Non-authenticated data is unacceptable
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 0
Queries
thunder.unifiedholdings.com: type A, class inet
Name: thunder.unifiedholdings.com
Type: Host address
Class: inet
0000 00 04 02 00 00 00 99 08 80 00 00 00 68 ff 08 00 ............h...
0010 45 00 00 49 00 00 40 00 40 11 e0 4d ac 10 01 22 E..I..@.@..M..."
0020 ac 10 01 14 80 02 00 35 00 35 5e 49 1d b9 01 00 .......5.5^I....
0030 00 01 00 00 00 00 00 00 07 74 68 75 6e 64 65 72 .........thunder
0040 0f 75 6e 69 66 69 65 64 68 6f 6c 64 69 6e 67 73 .unifiedholdings
0050 03 63 6f 6d 00 00 01 00 01 .com.....
Since both captures occured on the same NST probe, one can use the the packet arrival time difference as an estimation of the delay for sending out the DNS query packet to the network on interface: eth0. The packet arrival time difference is: 0.295 msecs ((eth0: 09:57:24.410442000) - (ppp0: 09:57:24.410147000)). This time difference represents CPU process time for compression and flow through the PPP IP stack.
Figure 7.6. Ethereal capture: interface eth0
Frame 6 (130 bytes on wire, 130 bytes captured)
Arrival Time: Feb 2, 2004 09:57:24.410442000
Time delta from previous packet: 0.592448000 seconds
Time since reference or first frame: 0.592448000 seconds
Frame Number: 6
Packet Length: 130 bytes
Capture Length: 130 bytes
Ethernet II, Src: 00:40:05:86:73:e5, Dst: 00:e0:1e:5c:d5:f2
Destination: 00:e0:1e:5c:d5:f2 (Cisco_5c:d5:f2)
Source: 00:40:05:86:73:e5 (AniCommu_86:73:e5)
Type: IP (0x0800)
Internet Protocol, Src Addr: 10.222.222.84 (10.222.222.84), Dst Addr: rrcs-nys-24-97-150-194.biz.rr.com (24.97.150.194)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x08 (DSCP 0x02: Unknown DSCP; ECN: 0x00)
0000 10.. = Differentiated Services Codepoint: Unknown (0x02)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 116
Identification: 0xccaa (52394)
Flags: 0x04
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: TCP (0x06)
Header checksum: 0xd57b (correct)
Source: 10.222.222.84 (10.222.222.84)
Destination: rrcs-nys-24-97-150-194.biz.rr.com (24.97.150.194)
Transmission Control Protocol, Src Port: 32785 (32785), Dst Port: 22 (22), Seq: 0, Ack: 0, Len: 64
Source port: 32785 (32785)
Destination port: 22 (22)
Sequence number: 0
Next sequence number: 64
Acknowledgement number: 0
Header length: 32 bytes
Flags: 0x0018 (PSH, ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 1... = Push: Set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 15776
Checksum: 0xa0bc (correct)
Options: (12 bytes)
NOP
NOP
Time stamp: tsval 7922224, tsecr 24160092
SSH Protocol
Encrypted Packet: 1F42744747E7C197CF8DB7B548BA0DA3...
0000 00 e0 1e 5c d5 f2 00 40 05 86 73 e5 08 00 45 08 ...\...@..s...E.
0010 00 74 cc aa 40 00 40 06 d5 7b 0a de de 54 18 61 .t..@.@..{...T.a
0020 96 c2 80 11 00 16 77 f2 7c 20 79 a6 07 88 80 18 ......w.| y.....
0030 3d a0 a0 bc 00 00 01 01 08 0a 00 78 e2 30 01 70 =..........x.0.p
0040 a7 5c 1f 42 74 47 47 e7 c1 97 cf 8d b7 b5 48 ba .\.BtGG.......H.
0050 0d a3 52 3e de dc 07 48 65 62 4e b2 cd 92 86 5a ..R>...HebN....Z
0060 64 04 e3 b4 4f bc ea 32 00 ee 22 bc 1b 43 07 60 d...O..2.."..C.`
0070 ee ce 57 c5 1d a1 29 68 83 1a 6a 91 6c 0e b2 1f ..W...)h..j.l...
0080 62 68 bh
The lower portion of Figure 7.4, “VPN: PPP tunneled over SSH: packet flow through the IP stacks” shows a breakout of the size of the DNS query packet as it flows through the IP stacks. In this example, the DNS query packet is actually being compressed by the PPPD Deflate compression scheme and packaged by the SSH protocol as a 64 byte payload. The compression algorithm used by the PPPD daemon helps erase some of the overhead sized added by tunnelling the packet through the SSH session. If this DNS query was sent directly to the eth0 network interface, the packet size would be: 87 bytes (DNS (45B) + UDP (8B) + IP (20B) + Link (14B)). So for this example an extra 42 bytes of data was necessary to tunnel the DNS query securely through the VPN.
Data that can be compressed (ie. text) can actually be passed through the VPN tunnel at effective rates that erase all overhead associated with this type of VPN tunnel. It really depends on the entropy of the data. I have measured some throughput rates using the measurement tool: ttcp with this type of tunnel that have provided a 32 times increase.