Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a wireless gateway that supports site-to-site IPSec. I have configured openswan on Ubuntu Server 12.04 (left side of the tunnel) with the following /etc/ipsec.conf:

version 2.0
config setup
    nat_traversal=yes
    virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12
    oe=off
    protostack=netkey

conn net-to-net
    authby=secret
    left=192.168.0.11
    leftsubnet=10.1.0.0/16
    leftsourceip=10.1.0.1
    right=%any
    rightsubnet=192.168.127.0/24
    rightsourceip=192.168.127.254
    auto=add

I have configured the wireless gateway (right side of the tunnel) similarly. I am using Main Mode (not Aggressive Mode) IKE stage 1, but it looks like it fails before it gets to stage 2. Any thoughts on why?

Here is the output from tcpdump:

# tcpdump -vv -i eth0 udp port 500 or udp port 4500
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
00:11:26.042928 IP (tos 0x0, ttl 235, id 39655, offset 0, flags [none], proto UDP (17), length 196)
    74.198.87.62.44248 > 192.168.0.11.isakmp: [udp sum ok] isakmp 1.0 msgid 00000000 cookie 7d88f683ff25b40a->0000000000000000: phase 1 I ident:
    (sa: doi=ipsec situation=identity
        (p: #1 protoid=isakmp transform=1
            (t: #1 id=ike (type=enc value=aes)(type=keylen value=0100)(type=hash value=md5)(type=auth value=preshared)(type=group desc value=modp1536)(type=lifetype value=sec)(type=lifeduration len=4 value=00015180))))
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
00:11:26.044511 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 172)
    192.168.0.11.isakmp > 74.198.87.62.44248: [bad udp cksum 0x6361 -> 0x70a3!] isakmp 1.0 msgid 00000000 cookie 7d88f683ff25b40a->6569330ef208fe4d: phase 1 R ident:
    (sa: doi=ipsec situation=identity
        (p: #1 protoid=isakmp transform=1
            (t: #1 id=ike (type=enc value=aes)(type=keylen value=0100)(type=hash value=md5)(type=auth value=preshared)(type=group desc value=modp1536)(type=lifetype value=sec)(type=lifeduration len=4 value=00015180))))
    (vid: len=12)
    (vid: len=16)
    (vid: len=16)
00:11:26.683227 IP (tos 0x0, ttl 235, id 39656, offset 0, flags [none], proto UDP (17), length 312)
    74.198.87.62.44248 > 192.168.0.11.isakmp: [udp sum ok] isakmp 1.0 msgid 00000000 cookie 7d88f683ff25b40a->6569330ef208fe4d: phase 1 I ident:
    (ke: key len=192)
    (nonce: n len=16  data=(7d88f683ff25b40ac37b...00000014471b8027b9d2d76240f4329456eb22db))
    (pay20)
    (pay20)
00:11:26.688968 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 312)
    192.168.0.11.isakmp > 74.198.87.62.44248: [bad udp cksum 0x63ed -> 0x4fc7!] isakmp 1.0 msgid 00000000 cookie 7d88f683ff25b40a->6569330ef208fe4d: phase 1 R ident:
    (ke: key len=192)
    (nonce: n len=16  data=(aaeeb24d4daa1e07f949...00000014637d4a0b75f97e0f771664cd9ac0d818))
    (pay20)
    (pay20)
00:11:36.704351 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 312)
    192.168.0.11.isakmp > 74.198.87.62.44248: [bad udp cksum 0x63ed -> 0x4fc7!] isakmp 1.0 msgid 00000000 cookie 7d88f683ff25b40a->6569330ef208fe4d: phase 1 R ident:
    (ke: key len=192)
    (nonce: n len=16  data=(aaeeb24d4daa1e07f949...00000014637d4a0b75f97e0f771664cd9ac0d818))
    (pay20)
    (pay20)
00:11:56.165304 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 312)
    192.168.0.11.isakmp > 74.198.87.62.44248: [bad udp cksum 0x63ed -> 0x4fc7!] isakmp 1.0 msgid 00000000 cookie 7d88f683ff25b40a->6569330ef208fe4d: phase 1 R ident:
    (ke: key len=192)
    (nonce: n len=16  data=(aaeeb24d4daa1e07f949...00000014637d4a0b75f97e0f771664cd9ac0d818))
    (pay20)
    (pay20)

The right side of the tunnel is attempting to initiate the tunnel using Main Mode IKE phase 1. Main Mode involves three 2-way exchanges. OpenSWAN responds to the 1st 2 exchanges, but for some reason the right side doesn't initiate the 3rd exchange. What could possibly fail at that point in the process?

share|improve this question
    
Phase 1 negotiation failures are usually a mismatch in proposals, or a mis-typed preshared key. Have you verified these match and retyped the key on both ends? –  SpacemanSpiff Jul 13 '12 at 3:53
    
The PSK is definitely the same on either end. Maybe the encryption keys exchanged in the second exchange don't agree. Do the IP addresses go into creating those encryption keys? Maybe the right side is using its internal (NAT'ed) IP and the left side is using the right side's public IP? –  Isaac Sutherland Jul 13 '12 at 19:02

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.