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've configured a 3G IP Gateway of mine to connect using IKE Phase 1 Aggressive Mode with PSK to my openswan installation running on Ubuntu server 12.04. I've configured openswan as follows:

/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
    leftid=@left.paxcoda.com
    leftsubnet=10.1.0.0/16
    leftsourceip=10.1.0.1
    right=%any
    rightid=@right.paxcoda.com
    rightsubnet=192.168.127.0/24
    rightsourceip=192.168.127.254
    aggrmode=yes
    ike=aes128-md5;modp1536
    auto=add

/etc/ipsec.secrets:

@left.paxcoda.com @right.paxcoda.com: PSK "testpassword"

Note that both left and right are NAT'd, with dynamic public IP's. My left ISP gives my router a public IP, but my right ISP gives me a shared dynamic public IP and dynamic private IP. I have dynamic dns for the public ip on the left side. Here is what I see when I sniff the ISAKMP protocol:

21:17:31.228715 IP (tos 0x0, ttl 235, id 43639, offset 0, flags [none], proto UDP (17), length 437)
    74.198.87.93.49604 > 192.168.0.11.isakmp: [udp sum ok] isakmp 1.0 msgid 00000000 cookie da31a7896e2a1958->0000000000000000: phase 1 I agg:
    (sa: doi=ipsec situation=identity
        (p: #1 protoid=isakmp transform=1
            (t: #1 id=ike (type=enc value=aes)(type=keylen value=0080)(type=hash value=md5)(type=auth value=preshared)(type=group desc value=modp1536)(type=lifetype value=sec)(type=lifeduration len=4 value=00015180))))
    (ke: key len=192)
    (nonce: n len=16  data=(da31a7896e2a19582b33...0000001462b01880674b3739630ca7558cec8a89))
    (id: idtype=FQDN protoid=0 port=0 len=17 right.paxcoda.com)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
21:17:31.236720 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 456)
    192.168.0.11.isakmp > 74.198.87.93.49604: [bad udp cksum 0x649c -> 0xcd2f!] isakmp 1.0 msgid 00000000 cookie da31a7896e2a1958->5b9776d4ea8b61b7: phase 1 R agg:
    (sa: doi=ipsec situation=identity
        (p: #1 protoid=isakmp transform=1
            (t: #1 id=ike (type=enc value=aes)(type=keylen value=0080)(type=hash value=md5)(type=auth value=preshared)(type=group desc value=modp1536)(type=lifetype value=sec)(type=lifeduration len=4 value=00015180))))
    (ke: key len=192)
    (nonce: n len=16  data=(32ccefcb793afb368975...000000144a131c81070358455c5728f20e95452f))
    (id: idtype=FQDN protoid=0 port=0 len=16 left.paxcoda.com)
    (hash: len=16)
    (vid: len=16)
    (pay20)
    (pay20)
    (vid: len=16)

However, my 3G Gateway (on the right) doesn't respond, and I don't know why. I think left's response is indeed getting through to my gateway, because in another question, I was trying to set up a similar scenario with Main Mode IKE, and in that case it looks as though at least one of the three 2-way main mode exchanges succeeded.

What other explanation for the failure is there?

(The 3G Gateway I'm using on the right is a Moxa G3150, by the way.)

share|improve this question
    
Around here, you have to pay extra for any kind of VPN connectivity for a 3G/4G+ account. Something to consider/look into. –  gravyface Jul 14 '12 at 2:32
    
As I said, I don't think ISP restrictions are the problem here -- in similar setups I have seen UDP port 500 (ISAKMP) packets get through in both directions. I was told to try Aggressive Mode, so here I am -- but IKE Phase 1 is still failing half-way through. –  Isaac Sutherland Jul 14 '12 at 3:32
add comment

1 Answer

Check Moxa OnCell's system logs - it might be unhappy with OpenSWAN's response and just abort the exchange without further notice. Tinkering with the CLI also might be worth the effort - most manufacturers allow for some kind of debugging / packet tracing through the CLI.

Also if possible try to check if the response packet leaves your @left NAT router on its public interface and the address is being re-written to the public IP to rule out a possible routing / packet filtering problem in your infrastructure.

share|improve this answer
add comment

Your Answer

 
discard

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.