[Openswan Users] INVALID_ID_INFORMATION between OpenSwan and Checkpoint

Thu Jul 30 08:30:46 EDT 2015

Rescued from the spam bucket.  Please remember to subscribe to the mailing list before posting to it.

From: Daniel Cave <dan.cave at icloud.com>
Subject: Re: [Openswan Users] INVALID_ID_INFORMATION between OpenSwan and Checkpoint
Date: July 29, 2015 at 3:14:17 PM EDT
To: Simon Deziel <simon at xelerance.com>
Cc: "users at lists.openswan.org" <users at lists.openswan.org>

Fwiw. This article below does. It cover the following gotchas and problems caused by a potential lack of understanding of how AWs ec2 instances and security policy 

1. To allow traffic to pass through your VPN server you must disable check source address checking which can be done by right clicking the instance in the EC2 manager and going to security settings. This allows traffic from another network outside of that used by your vpc/classic instance so your end to end routing works 

2. Disable iptables on linux 

3. Create a security group for your cons networks and add the subnets into that from all the networks which are going INTO the vpn instance and apply that security group to the EC2 instance where applicable 

#lotsOfLessonsLearnedFromExperience

Hope that helps

Sent from my iPhone

> On 29 Jul 2015, at 16:31, Simon Deziel <simon at xelerance.com> wrote:
> 
> Hi Daniel,
> 
> You might find the following wiki page helpful:
> https://github.com/xelerance/Openswan/wiki/Amazon-ec2-example
> 
> Regards,
> Simon
> 
>> On 07/24/2015 02:51 AM, Daniel Carraro wrote:
>> Hi All,
>> 
>> I'm running OpenSwan on an Amazon Linux EC2 Instance (inside a VPC) and
>> am trying to connect to a Checkpoint 4800 Series appliance (running R75.45).
>> 
>> Phase 1 passes successfully, however I'm having issues with Phase 2.
>> Specifically, INVALID_ID_INFORMATION gets sent from my EC2 instance back
>> to the Client.
>> 
>> I'll give a quick summary of the networks:
>> - Our VPC is 10.200.0.0/16 <http://10.200.0.0/16>; the OpenSwan instance
>> is 54.66.155.156 (10.200.0.171)
>> - Their Network is 192.168.187.0/24 <http://192.168.187.0/24>; Their
>> Public Endpoint is 203.39.70.3 (192.168.187.253)
>> 
>> What's odd as well, I'm able to ping/telnet servers inside their network
>> (192.168.187.0/24 <http://192.168.187.0/24>), but they're unable to
>> ping/ssh inside my network (10.200.0.0/16 <http://10.200.0.0/16>)
>> 
>> I've included relevant config/log files below, trying to condense when
>> possible:
>> 
>> /etc/ipsec.conf:
>> version 2.0     # conforms to second version of ipsec.conf specification
>> # basic configuration
>> config setup
>>       # Debug-logging controls:  "none" for (almost) none, "all" for lots.
>>        klipsdebug=none
>>        plutodebug="control parsing"
>>       # For Red Hat Enterprise Linux and Fedora, leave protostack=netkey
>>       protostack=netkey
>>       nat_traversal=yes
>>       virtual_private=
>>       oe=off
>>       # Enable this if you see "failed to find any available worker"
>>       # nhelpers=0
>>       # custom config options
>>       force_keepalive=yes
>>       keep_alive=10
>> #You may put your configuration (.conf) file in the "/etc/ipsec.d/" and
>> uncomment this.
>> include /etc/ipsec.d/*.conf
>> 
>> /etc/ipsec.d/wc-vpn.conf:
>> conn wc-vpn
>>       type=tunnel
>>       auth=esp
>>       authby=secret
>> 
>>       left=10.200.0.171
>>       leftid=54.66.155.156
>>       leftnexthop=%defaultroute
>>       leftsubnet=10.200.0.0/16 <http://10.200.0.0/16>
>>       leftprotoport=0/0
>> 
>>       right=203.39.70.3
>>       rightid=203.39.70.3/32 <http://203.39.70.3/32>
>>       rightsubnet=192.168.187.0/24 <http://192.168.187.0/24>
>>       rightnexthop=192.168.187.253
>>       rightprotoport=0/0
>> 
>>       keyexchange=ike
>>       ike=aes256-sha1;modp1024!
>>       ikelifetime=28800s
>> 
>>       phase2alg=aes256-sha1
>>       keylife=3600s
>> 
>>       dpddelay=3
>>       dpdtimeout=10
>>       dpdaction=clear
>> 
>>       pfs=no
>>       auto=start
>>       forceencaps=yes
>>       compress=no
>> 
>> /etc/ipsec.d/wc-vpn.secrets (with actual PSK changed):
>> 54.66.155.156 203.39.70.3 <http://203.39.70.3>: PSK "1234567890"
>> 
>> Finally, a snippet from /var/log/secure:
>> Jul 19 23:10:28 ip-10-200-0-171 pluto[22644]: "wc-vpn" #616: sending
>> encrypted notification INVALID_ID_INFORMATION to 203.39.70.3:500
>> <http://203.39.70.3:500>
>> Jul 19 23:10:32 ip-10-200-0-171 pluto[22644]: "wc-vpn" #616: the peer
>> proposed: 10.200.0.0/16:0/0 <http://10.200.0.0/16:0/0> ->
>> 203.39.70.3/32:0/0 <http://203.39.70.3/32:0/0>
>> Jul 19 23:10:32 ip-10-200-0-171 pluto[22644]: "wc-vpn" #616: cannot
>> respond to IPsec SA request because no connection is known for
>> 10.200.0.0/16===10.200.0.171
>> <http://10.200.0.0/16===10.200.0.171><10.200.0.171>[54.66.155.156,+S=C]...203.39.70.3<203.39.70.3>[+S=C]
>> 
>> Any help would be greatly appreciated.
>> 
>> Thanks,
>> Daniel
>> 
>> 
>> _______________________________________________
>> Users at lists.openswan.org
>> https://lists.openswan.org/mailman/listinfo/users
>> Micropayments: https://flattr.com/thing/38387/IPsec-for-Linux-made-easy
>> Building and Integrating Virtual Private Networks with Openswan:
>> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
> 
> _______________________________________________
> Users at lists.openswan.org
> https://lists.openswan.org/mailman/listinfo/users
> Micropayments: https://flattr.com/thing/38387/IPsec-for-Linux-made-easy
> Building and Integrating Virtual Private Networks with Openswan:
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155

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