[Openswan Users] OpenSwan and Palo Alto PA-4020

[Patrick Naubert]

Rescued from the Spam bucket.  Please remember to subscribe to the mailing list before you post to it.

From: David Jones <david at proficienthealth.com>
Subject: Re: OpenSwan and Palo Alto PA-4020
Date: May 20, 2014 at 1:57:51 PM EDT
To: users at lists.openswan.org


Can anyone help me with this or tell me to include more information or something?

Thanks,

David


On Wed, Apr 30, 2014 at 12:04 PM, David jones <david at proficienthealth.com> wrote:
Hi, 

First-time poster here.  To set the mood, I am new to OpenSwan and network security in general but a chain of events have left me having to manage something better suited by someone else :-)

I have set up numerous IPSec connections using OpenSwan interfacing with Ciso, Sonicwall, and others but this Palo Alto is causing me some pain.

Here is the scenario…  I have an existing IPSec connection with a client that is working perfectly, with a Cisco 300 Series VPN appliance as there endpoint.  They are replacing it with this Palo Alto and gave me the new information for it.  I created a new connection and secret and updated the rightIP and subnets, but left everything else the same except for setting PFS =Yes in the conf.   

Linux version 3.2.0-2-amd64 (Debian 3.2.18-1) (debian-kernel at lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-1) ) #1 SMP Mon May 21 17:45:41 UTC 2012

Version: Linux Openswan U2.6.38-g312f1b8a-dirty/K3.2.0-2-amd64

example
WORKS!
conn clientvpn_old
    authby=secret
    left=xxx.xxx.xxx.167
    leftsourceip=xxx.xxx.xxx.167
    leftnexthop=xxx.xxx.xxx.161
    right=xxx.xxx.xxx.5
    rightsubnet=xxx.xxx.xxx.133/32
    auto=route
    pfs=no

DOESNT WORK!
conn clientvpn_new
    authby=secret
    left=xxx.xxx.xxx.167
    leftsourceip=xxx.xxx.xxx.167
    leftnexthop=xxx.xxx.xxx.161
    right=xxx.xxx.xxx.2
    rightsubnets={xxx.xxx.xxx6.34/32,xxx.xxx.xxx.35/32}
    auto=route
    pfs=yes



root at xxx:~# ipsec auto —status | grep clientvpn_new
000 "clientvpn_new/0x1": xxx.xxx.xxx.167/32===xxx.xxx.xxx.167<xxx.xxx.xxx.167>---xxx.xxx.xxx.161...xxx.xxx.xxx.2<xxx.xxx.xxx.2>===xxx.xxx.xxx.34/32; unrouted; eroute owner: #0
000 "clientvpn_new/0x1":     myip=xxx.xxx.xxx.167; hisip=unset;
000 "clientvpn_new/0x1":   ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0 
000 "clientvpn_new/0x1":   policy: PSK+ENCRYPT+TUNNEL+PFS+IKEv2ALLOW+SAREFTRACK+lKOD+rKOD; prio: 32,32; interface: eth1; 
000 "clientvpn_new/0x1":   newest ISAKMP SA: #0; newest IPsec SA: #0; 
000 "clientvpn_new/0x1":   aliases: clientvpn_new 
000 "clientvpn_new/0x2": xxx.xxx.xxx.167/32===xxx.xxx.xxx.167<xxx.xxx.xxx.167>---xxx.xxx.xxx.161...xxx.xxx.xxx.2<xxx.xxx.xxx.2>===xxx.xxx.xxx.35/32; unrouted; eroute owner: #0
000 "clientvpn_new/0x2":     myip=xxx.xxx.xxx.167; hisip=unset;
000 "clientvpn_new/0x2":   ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0 
000 "clientvpn_new/0x2":   policy: PSK+ENCRYPT+TUNNEL+PFS+IKEv2ALLOW+SAREFTRACK+lKOD+rKOD; prio: 32,32; interface: eth1; 
000 "clientvpn_new/0x2":   newest ISAKMP SA: #0; newest IPsec SA: #0; 
000 "clientvpn_new/0x2":   aliases: clientvpn_new 



root at xxx:~# grep clientvpn_new /var/log/auth.log
Apr 30 01:00:05 xxx pluto[13917]: added connection description "clientvpn_new/0x1"
Apr 30 01:00:05 xxx pluto[13917]: added connection description "clientvpn_new/0x2"
Apr 30 01:00:05 xxx pluto[13917]: loading secrets from "/etc/ipsec.d/clientvpn_new.secrets"


So it looks like everything comes up properly but when the other side tries to connect, they get a timeout and I get nothing in my auth.log or ipsec auto —status.  I have verified a trace route form their side and they can reach my IP just fine.  Im completely lost at this point and looking for some suggestions.  My assumption is that there is something not right on their side but I dont know how to prove it.  

Thanks,


David Jones











-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openswan.org/pipermail/users/attachments/20140521/a60a8815/attachment.html>