VPN: PPP Tunneled Over SSH Overhead Discussion

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 6.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 6.3. VPN: PPP tunneled over SSH: packet flow through the IP stacks (Network Diagram)

VPN: PPP tunneled over SSH: packet flow through the IP stacks (Network Diagram)

Figure 6.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 6.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.

Figure 6.4. VPN: PPP tunneled over SSH: packet flow through the IP stacks

VPN: PPP tunneled over SSH: packet flow through the IP stacks

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