- •Table of Contents
- •Preface
- •What This Book Covers
- •What You Need for This Book
- •Conventions
- •Reader Feedback
- •Customer Support
- •Errata
- •Questions
- •The Need for Cryptography
- •Privacy
- •Security
- •A History of the Internet
- •Holding the Internet Together
- •The Creation of ICANN
- •ICANN Bypassed
- •The Root Name Servers
- •Running the Top-Level Domains
- •History of Internet Engineering
- •The Internet Engineering Task Force (IETF)
- •RFCs—Requests For Comments
- •IETF and Crypto
- •The War on Crypto
- •Dual Use
- •Public Cryptography
- •The Escrowed Encryption Standard
- •Export Laws
- •The Summer of '97
- •The EFF DES Cracker
- •Echelon
- •The End of the Export Restrictions
- •Free Software
- •Free as in Verifiable
- •The Open Source Movement
- •The History of Openswan
- •IETF Troubles over DNS
- •Super FreeS/WAN
- •The Arrival of Openswan
- •NETKEY
- •Further Reading
- •Using Openswan
- •Copyright and License Conditions
- •Writing and Contributing Code
- •Legality of Using Openswan
- •International Agreements
- •International Law and Hosting Openswan
- •Unrecognized International Claims
- •Patent Law
- •Expired and Bogus Patents
- •Useful Legal Links
- •Summary
- •A Very Brief Overview of Cryptography
- •Valid Packet Rewriting
- •Ciphers
- •Algorithms
- •Uniqueness
- •Public-Key Algorithms
- •Exchanging Public Keys
- •Digital Signatures
- •Diffie-Hellman Key Exchange
- •Avoiding the Man in the Middle
- •Session Keys
- •Crypto Requirements for IPsec
- •IPsec: A Suite of Protocols
- •Kernel Mode: Packet Handling
- •Authentication Header (AH)
- •Encapsulated Security Payload (ESP)
- •Transport and Tunnel Mode
- •Choosing the IPsec Mode and Type
- •The Kernel State
- •Encryption Details
- •Manual Keying
- •Final Note on Protocols and Ports
- •Usermode: Handling the Trust Relationships
- •The IKE Protocol
- •Phase 1: Creating the ISAKMP SA
- •Phase 2: Quick Mode
- •The NAT Problem
- •Summary
- •Linux Distributions
- •Debian
- •SuSE
- •Slackware
- •Gentoo
- •Linux 'Router' Distributions
- •Deciding on the Userland
- •Pluto
- •Racoon
- •Isakmpd
- •More Reasons to Pick Pluto
- •Choosing the Kernel IPsec Stack
- •KLIPS, the Openswan Stack
- •ipsecX Interfaces
- •First Packet Caching
- •Path MTU Discovery
- •KLIPS' Downside
- •NETKEY, the 2.6 IPsec Stack
- •The USAGI / SuSE IPsec Stack
- •Making the Choice
- •GPL Compliance and KLIPS
- •Binary Installation of the Openswan Userland
- •Checking for Old Versions
- •Installing the Binary Package for Openswan
- •Building from Source
- •Using RPM-based Distributions
- •Rebuilding the Openswan Userland
- •Building src.rpm from Scratch
- •Openswan Options
- •Building the Openswan Userland from Source
- •Downloading the Source Code
- •Configuring the Userland Tools
- •Optional Features
- •Compile Flags
- •File Path Options
- •Obscure Pluto Options
- •Compiling and Installing
- •Binary Installation of KLIPS
- •Building KLIPS from Source
- •Kernel Prerequisites
- •Identifying your Kernel's Abilities
- •Using Both KLIPS and NETKEY
- •The Kernel Build Options
- •Required Kernel Options
- •Desired Options
- •NETKEY Stack Options
- •KLIPS Stack Options
- •L2TP Options
- •Patching the Kernel
- •NAT-Traversal Patch
- •KLIPS Compile Shortcut
- •Activating KLIPS
- •Determining the Stack in Use
- •Building KLIPS into the Linux Kernel Source Tree
- •Building a Standard Kernel
- •NAT Traversal
- •Patching KLIPS into the Linux Kernel
- •Verifying the Installation
- •Summary
- •Manual versus Automatic
- •PSK versus RSA
- •Pitfalls of Debugging IPsec
- •Pre-Flight Check
- •The ipsec verify Command
- •NAT and Masquerading
- •Checking External Commands
- •Opportunistic Encryption
- •The ipsec livetest Command
- •Configuration of Openswan
- •The ipsec.conf File
- •Host-to-Host Tunnel
- •Left and Right
- •The type Options
- •The auto Option
- •The rsasigkey Options
- •Bringing Up the IPsec Tunnels
- •Listing IPsec Connections
- •Testing the IPsec Tunnel
- •Connecting Subnets Through an IPsec Connection
- •Testing Subnet Connections
- •Testing Properly
- •Encrypting the Host and the Network Behind It
- •Employing Advanced Routing
- •Creating More Tunnels
- •Avoiding Duplication
- •The Also Keyword
- •KLIPS and the ipsecX Interfaces
- •Pre-Shared Keys (PSKs)
- •Proper Secrets
- •Dynamic IP Addresses
- •Hostnames
- •Roadwarriors
- •Multiple Roadwarrior Connections
- •Dynamic IP and PSKs
- •Mixing PSK and RSA
- •Connection Management
- •Subnet Extrusion
- •NAT Traversal
- •Deprecated Syntax
- •Confirming a Functional NAT-T
- •Dead Peer Detection
- •DPD Works Both Ways
- •Configuring DPD
- •Buggy Cisco Routers
- •Ciphers and Algorithms
- •Using ike= to Specify Phase 1 Parameters
- •Using esp= to Specify Phase 2 Parameters
- •Defaults and Strictness
- •Unsupported Ciphers and Algorithms
- •Aggressive Mode
- •XAUTH
- •XAUTH Gateway (Server Side)
- •XAUTH Client (Supplicant Side)
- •Fine Tuning
- •Perfect Forward Secrecy
- •Rekeying
- •Key Rollover
- •Summary
- •X.509 Certificates Explained
- •X.509 Objects
- •X.509 Packing
- •Types of Certificates
- •Passphrases, PIN Codes, and Interactivity
- •IKE and Certificates
- •Using the Certificate DN as ID for Openswan
- •Generating Certificates with OpenSSL
- •Setting the Time
- •Configuring OpenSSL
- •Be Consistent with All Certificates
- •OpenSSL Commands for Common Certificate Actions
- •Configuring Apache for IPsec X.509 Files
- •Creating X.509-based Connections
- •Using a Certificate Authority
- •Using Multiple CAs
- •Sending and Receiving Certificate Information
- •Creating your own CA using OpenSSL
- •Creating Host Certificates with Your Own CA
- •Host Certificates for Microsoft Windows (PKCS#12)
- •Certificate Revocation
- •Dynamic CRL Fetching
- •Configuring CRL
- •Online Certificate Status Protocol (OCSP)
- •Summary
- •History of Opportunistic Encryption
- •Trusting Third Parties
- •Trusting the DNS?
- •OE in a Nutshell
- •An OE Security Gateway
- •DNS Key Records
- •Forward and Reverse Zones
- •The OE DNS Records
- •Different Types of OE
- •Policy Groups
- •Internal States
- •Configuring OE
- •Configuring Policies
- •Full OE or Initiate-Only
- •Generating Correct DNS Records
- •Name Server Updates
- •Verifying Your OE Setup
- •Testing Your OE Setup
- •The trap eroute
- •The pass eroute
- •The hold eroute
- •Manipulating OE Connections Manually
- •Advanced OE Setups
- •Caveats
- •Summary
- •Where to Firewall?
- •Allowing IPsec Traffic
- •NAT and IPsec Passthrough
- •Configuring the Firewall on the Openswan Host
- •Firewalling and KLIPS
- •Firewalling and NETKEY
- •Packet Size
- •Summary
- •Microsoft Windows
- •Layer 2 Tunneling Protocol (L2TP)
- •Assigning an IP for VPN Access
- •L2TP Properties
- •Pure IPsec versus L2TP/IPsec
- •Client and Server Configurations for L2TP/IPsec
- •The L2TP Openswan Server
- •Configuring Openswan for L2TP/IPsec
- •Linux Kernel Runtime Parameters for L2TP/IPsec
- •Protecting the L2TP Daemon with IPsec using iptables
- •Choosing an L2TP Daemon
- •Configuring L2TPD
- •Configuring User Authentication for pppd
- •Microsoft Windows XP L2TP Configuration
- •Microsoft Windows 2000 L2TP Configuration
- •Apple Mac OS X L2TP Configuration
- •Server Configuration for X.509 IPsec without L2TP
- •Openswan Configuration for X.509 without L2TP
- •Client Configuration for X.509 IPsec without L2TP
- •Microsoft's IKE Daemon
- •Microsoft's Certificate Store
- •Clients using Microsoft Native IPsec Implementation
- •The ipsec.exe Wrapper
- •The Linsys IPsec Tool (lsipsectool)
- •Securepoint IPsec Client
- •TauVPN (iVPN)
- •The WaveSEC Client
- •Third-Party Replacement Clients for Windows
- •The GreenBow VPN Client
- •Astaro Secure Client
- •Mac OS X IPSecuritas
- •VPNtracker
- •Manual Racoon Configuration
- •Importing X.509 Certificates into Windows
- •Importing X.509 Certificates on Mac OS X (Tiger)
- •Summary
- •Openswan as a Client to an Appliance
- •Preparing the Interop
- •The Human Factor
- •Terminology
- •Preparation
- •IPsec Passthrough
- •Tunnel Limitations
- •Anticipate Known Problems
- •Update the Firmware
- •GUI Issues
- •Keepalives
- •ISP Filtering
- •Frequently used VPN Gateways
- •Webmin with Openswan
- •Cisco VPN 3000
- •Cisco PIX Concentrator
- •Nortel Contivity
- •Checkpoint
- •WatchGuard Firebox
- •Symantec
- •Frequently used VPN Client Appliances
- •ZyXEL
- •DrayTek Vigor
- •The Vigor Web Interface
- •Windows Logon Issues
- •Other Vigorisms
- •Unresolved Issues
- •NetScreen
- •Known Issues
- •SonicWALL
- •BinTec
- •LANCOM
- •Linksys
- •Lucent Brick
- •NETGEAR
- •KAME/Racoon
- •Aftercare
- •Summary
- •Methods of Encryption
- •Host-to-Host Mesh
- •Host-to-Gateway Setup
- •Single IP Extrusiautomation or L2TP
- •Opportunistic Encryption in the LAN
- •Non-OE-Capable Machines
- •Designing a Solution for Encrypting the LAN
- •Design Goals
- •Separation of WiFi and Crypto
- •Link Layer Protection
- •The Logical Choice: IPsec
- •Hotspot
- •WaveSEC
- •Full WaveSEC
- •Catch 22 Traffic
- •Building a WaveSEC Server
- •DHCP Server Setup
- •DNS Server Setup
- •Openswan Server Setup
- •Catch 22 Traffic Setup
- •Building a WaveSEC Client
- •DH Client Setup
- •Openswan Setup
- •Testing the WaveSEC
- •Starting the WaveSEC Connection
- •Known Issues with WaveSEC
- •WaveSEC for Windows
- •Design Limitations
- •Building a WaveSEC for Windows Server
- •Obtaining the Certificate and Client Software
- •Our Prototype Experiences
- •Openswan Issues
- •Windows Kernel Issues
- •Summary
- •Cipher Performance
- •Handling Thousands of Tunnels
- •Managing Large Configuration Files
- •Standard Naming Convention
- •The also= Parameter
- •The include Parameter
- •Openswan Startup Time
- •Limitations of the Random Device
- •Other Performance-Enhancing Factors
- •Logging to Disk
- •Disable Dead Peer Detection
- •Reducing the Number of Tunnels
- •OSPF Setup
- •BGPv4 Setup
- •High Availability
- •Heartbeat
- •Xen Migration
- •Using Anycast
- •Summary
- •Do Not Lock Yourself Out!
- •Narrowing Down the Problem
- •Host Issues
- •Configuration Problems
- •Connection Names
- •Interoperability
- •Hunting Ghosts
- •Rekey Problems (After an Hour)
- •Openswan Error Messages
- •IKE: Unknown VendorIDs
- •Network Issues
- •Firewalls
- •MTU and Fragmentation Issues
- •Debugging IPsec on Apple Mac OS X
- •Debugging IPsec on Microsoft Windows
- •Oakley Debugging
- •Debugging ipsec.exe
- •Microsoft L2TP Errors
- •You Suddenly Cannot Log in Anymore over the VPN
- •Software Bugs
- •Userland Issues: Assertion Failed or Segmentation Faults
- •Kernel Issues: Crashes and Oopses
- •Memory Issues
- •Common IKE Error Messages
- •Common Kernel-Related Error Messages
- •Common Errors when Upgrading
- •Using tcpdump to Debug IPsec
- •Situation A: No Communication on Port 500
- •Situation B: Failure at Third Exchange
- •Situation C: QUICK Mode Initiates, but Never Completes
- •Situation D: All IKE Messages Occur, but no Traffic Flows
- •A Final tcpdump Example
- •User Mode Linux Testing
- •Preparing the Openswan for the UML Build Process
- •Running the UMLs
- •Writing a UML Test Case
- •Debugging the Kernel with GDB
- •Asking the Openswan Community for Help
- •Internet Relay Chat (IRC)
- •The Openswan Mailing Lists
- •Posting to the Lists
- •Research First, Ask Later
- •Free, as in Beer
- •Do not Anonymize
- •Summary
- •Linux Kernel Developments
- •Kernel API Changes between 2.6.12 and 2.6.14
- •Red Hat Kernel Developments
- •Fedora Kernel Source/Headers Packaging Change
- •MD5 Insecurities
- •Discontinuation of Openswan 1 by the End of 2005
- •Update on UML Testing Suite Installation
- •Openswan GIT Repositories
- •Openswan on Windows and Mac OS X Updates
- •Known Outstanding Bugs
- •Vulnerability Fixes in Openswan 2.4.4
- •The OSI Model and the IP Model
- •No Layers, Just Packets
- •The Protocol
- •IP Network Overview
- •IP Address Management
- •The Old IP Classes
- •Classless IP Networks
- •The Definition of a Subnet
- •Calculating with Subnets: The Subnet Mask
- •The Rest of the Network
- •Linux Networking Commands
- •Routing
- •Routing Decisions
- •Peering
- •Network Address Translation
- •Port Forwarding
- •Openswan Links
- •Community Documentation
- •Generic Linux Distributions Containing Openswan
- •Specialized Linux Distributions Containing Openswan
- •Overview RFCs
- •Basic Protocols
- •Key Management
- •Procedural and Operational RFCs
- •Detailed RFCs on Specific Cryptographic Algorithms and Ciphers
- •Dead Peer Detection RFCs
- •NAT-Traversal and UDP Encapsulation RFCs
- •RFCs for Secure DNS Service, which IPSEC May Use
- •RFCs Related to L2TP, Often Used in Combination with IPsec
- •RFCs on IPsec in Relation to Other Protocols
- •RFCs Not in Use or Implemented across Multiple Vendors
- •Index
Chapter 12
Let us have a look at how tcpdump can assist in these situations.
Situation A: No Communication on Port 500
Use tcpdump on sg1 and on sg2 at the same time:
# tcpdump -i eth1 -n -p udp port 500 or udp port 4500
The following table explains the options used here.
-i eth1 |
Only look on this interface. Some distributions include support for dumping on all |
|
interfaces. Avoid using that, as it will confuse. |
-n |
Do not perform reverse DNS resolution. |
-p |
Do not use promiscuous mode. We only want to see packets for this host. |
udp port 500 |
Only look for UDP packets with a source or destination port of 500. |
or udp port 4500 |
Or look for UDP packets with a source or destination port of 4500. This happens with |
|
NAT-Traversal. |
|
|
Now repeat the --replace and --up commands mentioned before the previous two tables. If there are no problems, then each packet leaving sg1 should be seen arriving at sg2. If one of these gateways has many tunnels, you will want to limit tcpdump to only show the packets for this particular sg1-sg2 combination. You can do this by extending the tcpdump filter we used above:
sg1# tcpdump -i eth1 -n -p ip host 1.2.3.4 and '(' udp port 500 or udp port 4500 ')' sg2# tcpdump -i eth1 -n -p ip host 5.6.7.8 and '(' udp port 500 or udp port 4500 ')'
1.2.3.4 is the IP of sg2 and 5.6.7.8 is the IP of sg1. Note each system filters for the IP of the opposite system.
You may be tempted to just look at all traffic from the opposite security gateway. This can be done, but be careful if you are SSHed into one security gateway from another. You will dump port 22 traffic, which is your SSH session with your tcpdump running. Since capturing these packets shows up in tcpdump, this will be transferred to you by SSH, using port 22. This will create more port-22 traffic for tcpdump, leading to an endless loop. You can, however, also listen to everything and just exclude the port-22 traffic using:
sg1# tcpdump -i eth1 -n -p ip host 1.2.3.4 and not port 22
What we are looking for are packets that start at sg1, and do not get to sg2. It may be helpful to include the -v option to tcpdump, which will decode the initial main mode proposal, since those first two exchanges are not encrypted.
There are two possible outcomes:
A1: All Packets Arrive on sg2
If all the packets arrive on sg2, but the Pluto running on it does not acknowledge them, then the problem is likely firewalling on sg2. You can confirm this by enabling plutodebug=all, and checking that Pluto does not receive a single packet. Or you can temporarily add an ACCEPT rule for all packets from and to sg1 using:
291
Debugging and Troubleshooting
sg2: # iptables -I INPUT -s ip_of_sg1 -j ACCEPT sg2: # iptables -I OUTPUT -d ip_of_sg1 -j ACCEPT
A2: No Packets Arrive on sg2
This most likely means there is a firewall somewhere in between that is filtering your packets, or there is a NAT involved that you do not know about.
Situation B: Failure at Third Exchange
First, examine the logs on sg2. If it is complaining about being unable to find the appropriate keys, then the problem is not a communication failure. It will log that it received MI3 and complain about a failure to authenticate when RSA keys are used. If this conn uses PSK (authby=secret) then this error will appear as a failure to decrypt properly.
Assuming that there are no log entries on sg2, then the third packet may not be received. There are a number of possible reasons for this. Use tcpdump on both ends again, but include -v:
sg1# tcpdump -i eth1 -v -n -p udp port 500 or udp port 4500 sg2# tcpdump -i eth1 -v -n -p udp port 500 or udp port 4500
Look for the third exchange; it will be marked as [E].
The first exchange will look like:
11:14:25.516187 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto 17, length: 320) 205.150.200.247.500 > 205.150.200.252.500: isakmp 1.0 msgid : phase 1 I ident: [|sa]
11:14:25.537388 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto 17, length: 128) 205.150.200.252.500 > 205.150.200.247.500: isakmp 1.0 msgid : phase 1 R ident: [|sa]
And the second exchange will look like:
11:14:25.547023 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto 17, length: 272) 205.150.200.247.500 > 205.150.200.252.500: isakmp 1.0 msgid : phase 1 I ident: [|ke]
11:14:25.772504 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto 17, length: 272) 205.150.200.252.500 > 205.150.200.247.500: isakmp 1.0 msgid : phase 1 R ident: [|ke]
And the third exchange will look like:
11:14:25.781501 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto 17, length: 232) 205.150.200.247.500 > 205.150.200.252.500: isakmp 1.0 msgid : phase 1 I ident[E]: [encrypted id]
11:14:25.865700 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto 17, length: 360) 205.150.200.252.500 > 205.150.200.247.500: isakmp 1.0 msgid : phase 1 R ident[E]: [encrypted id]
The above is what it should look like: you should see the same thing at each end. Variations that one might see are:
•the packet may have been fragmented
•traffic on port 4500
•the IP addresses may also have changed if a NAT is involved
•any combination of the above
292
Chapter 12
Fragmentation Problem
If certificates are involved, and they are being sent inline, that may lead to I3/R3 packets that are larger than 1500 bytes, which requires that the packet be fragmented. This will be indicated by having a non-zero 'id' field, and the flags will include '[+]'. The above filter will not show the fragments.
If you are seeing fragmentation, then adjust the filter to show all packets going to the other end. Be careful, as this may result in a lot of traffic:
sg1# tcpdump -i eth1 -v -n -p ip host 1.2.3.4 and not port 22 sg2# tcpdump -i eth1 -v -n -p ip host 5.6.7.8 and not port 22
Very carefully check for fragments leaving one system and not arriving at the other system. Note that Linux sends the fragments before the initial fragment.
It is also possible that the local system is filtering the fragments itself; in which case, no packet will emerge at all. This can be due to local firewalling, but can also be due to UDP on the 2.6 kernel having the Don't Fragment bit set.
If you enable partial logging for Pluto using plutodebug=emitting, the logs will show you how big the UDP packet is that is being sent. This way you can confirm that large packets are being sent, and that receiving these packets is the problem.
The most common situation is ISPs, poorly designed routers, or over-zealous firewall admins who have filtered out fragments. Often they will claim that they have not done that. Test the situation with:
sg1# ping -s 5000 1.2.3.4
You may also want to try this using the hping2 utility:
sg1# hping2 -2 -x -y --destport 500 1.2.3.4
A way to determine that this is in fact the problem is to omit the certificate payload by putting leftsendcert=never. Copy the certificate to sg2, and point the conn at it. While you may not want to operate like this permanently, it can help to diagnose the problem.
Port 4500 is Closed
If NAT was detected, which will be logged by Pluto when you use the --up command, and you see the I3 packet leaving sg1 to port 4500, but not arriving at sg2, then the likely reason is that port 4500 has been blocked. If you see the packet arrive, but Pluto on sg2 never sees it, then the problem is probably firewalling on sg2 or on a firewall in front of sg2, or the fault of sg2's ISP.
Be careful with firewall rules: port 4500 traffic, unlike port 500 traffic, does not always originate on port 4500. For example:
# iptables -I INPUT -s 0.0.0.0/0 -d 0.0.0.0/0 -p udp --sport 500 --dport 500 -j ACCEPT
This rule will work fine for plain IKE traffic when there is no NAT involved, but you cannot use a similar rule for UDP 4500, since the source port might be a random high port instead of 4500. Instead, you need rules like:
#iptables -A INPUT -s 0.0.0.0/0 -d 0.0.0.0/0 -p udp --sport 4500 -j ACCEPT
#iptables -A INPUT -s 0.0.0.0/0 -d 0.0.0.0/0 -p udp --dport 4500 -j ACCEPT
293
Debugging and Troubleshooting
However, this is a rather liberal rule set. For example, it would permit traffic from port 4500 to port 138, which is not the intended behavior. Either place these firewall rules after all your other firewall rules (and use -A to append, not -I to insert, the rule), or further tighten the IP address of the machines you are willing to talk IKE with. Of course if you have roadwarriors, then you will need to open up IKE to the world.
Situation C: QUICK Mode Initiates, but Never Completes
This situation can be diagnosed from the logs on sg2. tcpdump does not help at all in this case.
Situation D: All IKE Messages Occur, but no Traffic Flows
If you are using KLIPS, you have access to the ipsecX interfaces. You can run tcpdump on them to see if encrypted packets on the Ethernet device are being decrypted properly and sent out on the ipsecX device. First start tcpdump again on both machines, but now on the ipsecX device:
sg1# tcpdump -i ipsec0 -n -p sg2# tcpdump -i ipsec0 -n -p
Then, send some traffic. Do you see the traffic you are sending? If sg1 is a very busy IPsec machine, then you might want to add some additional filters to limit the decrypted traffic you want to see.
If you see traffic, but the traffic does not get through to its final destination, then you could have a firewall problem on sg2, or perhaps a routing problem. Alternatively, you might not have enabled
IP forwarding in /etc/sysctl.conf.
If you see no traffic on sg1, then you may have a firewall problem there. Also read the logs on both ends. Was the SA set up properly? Look for errors from the ip or route commands.
If you see traffic on sg1, but none on sg2, then you need to investigate if the session layer ESP traffic is getting through.
Third, is there NAT involved? It could be that a NAT device will try to be helpful. As a result, the two gateways may not detect that there is a NAT involved, and may not switch from using port 500 and protocol 50 (ESP) packets to UDP port 4500 packets with encapsulated ESP as payload.
As of version 2.3.0, Pluto will log what it is going to do:
004 "sg1--sg2-net" #797: STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0xaa6fa19a <0xa2f3b68d xfrm=3DES_0-HMAC_SHA1 NATD=none DPD=enabled}
If it says "NATD=none", and you think that there is NAT, then you may have to set
forceencaps=yes in the conn definition.
If this is not the case, then on each end issue the following:
sg1# tcpdump -i eth1 -v -n -p ip host 1.2.3.4 and ip proto 50 sg2# tcpdump -i eth1 -v -n -p ip host 5.6.7.8 and ip proto 50
You should see ESP packets with SPI 0xaa6fa19a leaving sg1 (this the => in the log entry), and ESP packets with SPI 0xa2f3b68d arriving on sg1. On sg2, you should see the opposite.
Ensure that you do not only see traffic going in one direction.
294