From garrydt at msn.com  Fri Dec  2 19:08:19 2016
From: garrydt at msn.com (Garry Taylor)
Date: Sat, 3 Dec 2016 00:08:19 +0000
Subject: [Openswan Users] Having problems with a command
Message-ID: <MWHPR17MB1534B8BEE67A463E6FE094D5AA810@MWHPR17MB1534.namprd17.prod.outlook.com>

Trying to issue the following command for a class and receiving the following error "no such dir"


cp/etc/ipsec.conf/etc/ipsec_old.conf


have tried many configs to this command and still no joy.

Thanks for time and effort on solving this.


Garry

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

From tjchamberlain at hotmail.com  Fri Dec  2 20:21:56 2016
From: tjchamberlain at hotmail.com (Toby Chamberlain)
Date: Sat, 3 Dec 2016 01:21:56 +0000
Subject: [Openswan Users] Having problems with a command
In-Reply-To: <MWHPR17MB1534B8BEE67A463E6FE094D5AA810@MWHPR17MB1534.namprd17.prod.outlook.com>
References: <MWHPR17MB1534B8BEE67A463E6FE094D5AA810@MWHPR17MB1534.namprd17.prod.outlook.com>
Message-ID: <SC1P152MB17755BBE6D2B68CE76041D5BA9810@SC1P152MB1775.LAMP152.PROD.OUTLOOK.COM>

Hi Garry,

You did put spaces in right?

cp /etc/ipsec.conf /etc/ipsec_old.conf

(that's cp<space>/etc/ipsec.conf<space>/etc/ipsec_old.conf)

Toby


From: garrydt at msn.com<mailto:garrydt at msn.com>
Sent: Saturday, December 03, 2016 11:08 AM
To: users at lists.openswan.org<mailto:users at lists.openswan.org>
Subject: [Openswan Users] Having problems with a command


Trying to issue the following command for a class and receiving the following error "no such dir"


cp/etc/ipsec.conf/etc/ipsec_old.conf


have tried many configs to this command and still no joy.

Thanks for time and effort on solving this.


Garry

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

From giovanni.messina at bizmate.it  Tue Dec  6 09:42:19 2016
From: giovanni.messina at bizmate.it (Giovanni Messina - Bizmate s.r.l)
Date: Tue, 06 Dec 2016 15:42:19 +0100
Subject: [Openswan Users] Ipsec tunnel up but no traffic is sent through
Message-ID: <5846CE4B.30701@bizmate.it>

Hi all!

I am a new openswan user and I start to enjoy this tool.

I'm configuring a site to site ipsec tunnel, and I have some problems: 
the tunnel is up but no traffic is passing through. In the following the 
description of the scenario.

I have to establish a ipsec tunnel between our customer site(on amazon 
cloud) and a provider site. An host in our customer site needs to 
connect to two different host in the provider site, through the ipsec 
tunnel. The ipsec endpoint for our customer is a linux server; the linux 
server is behind a firewall and doesn't have a pubblic ip. The ipsec 
endpoint of the provider is a Cisco ASA: i have no control on this 
endpoint. The endpoint LAN ip address is 192.168.60.10 and the host who 
needs to use the ipsec tunnel has ip 192.168.50.4. For a requirement of 
the provider, we have to use as encrypted domain (our left subnet) the 
network 10.129.46.168/29; so i have configured a SNAT that translate the 
ip of the host (192.168.50.4) to an ip of the encrypted domain 
(10.129.46.169). On the provider side, the encryption domain (the right 
subnet) is composed by two different ip: 
10.129.128.101/32,10.128.243.223/32, so in the configuration you can 
find the "righsubnets" parameter.

I have the following ipsec.conf:

# /etc/ipsec.conf - Openswan IPsec configuration file

# This file:  /usr/share/doc/openswan/ipsec.conf-sample
#
# Manual:     ipsec.conf.5


version    2.0    # conforms to second version of ipsec.conf specification

# basic configuration
config setup
     # Do not set debug options to debug configuration issues!
     # plutodebug / klipsdebug = "all", "none" or a combation from below:
     # "raw crypt parsing emitting control klips pfkey natt x509 dpd 
private"
     # eg:
     # plutodebug="control parsing"
     #
     # enable to get logs per-peer
      plutoopts="--perpeerlog"
     #
     # Again: only enable plutodebug or klipsdebug when asked by a developer
     #
     # NAT-TRAVERSAL support, see README.NAT-Traversal
     nat_traversal=yes
     # exclude networks used on server side by adding %v4:!a.b.c.0/24
virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12
     # OE is now off by default. Uncomment and change to on, to enable.
     #oe=off
     # which IPsec stack to use. auto will try netkey, then klips then mast
     protostack=netkey
     interfaces=%defaultroute
     klipsdebug=all
     plutodebug=all
         plutostderrlog=/var/log/pluto.log
conn provider
     type=tunnel
     left=192.168.60.10
     leftnexthop=%defaultroute
     leftsubnet=10.129.46.168/29
     right=PROVIDER_PUBLIC_IP
     #rightnexthop=%defaultroute
     #rightsubnet=10.129.128.101/32
     rightsubnets={10.129.128.101/32,10.128.243.223/32}
     ike=3des-md5;modp1024
     auth=esp
     phase2alg=3des-md5
     keyexchange=ike
     authby=secret
     pfs=no
     auto=start
     aggrmode=no
         ikelifetime=28800s
         salifetime=3600s
     forceencaps=yes


and the tunnel seems to be up:

#/etc/init.d/ipsec status
IPsec running  - pluto pid: 28315
pluto pid 28315
2 tunnels up
some eroutes exist

and ipsec auto --status:
000 #460: "provider/0x1":4500 STATE_QUICK_I2 (sent QI2, IPsec SA 
established); EVENT_SA_REPLACE in 1678s; newest IPSEC; eroute owner; 
isakmp#458; idle; import:admin initiate
000 #460: "provider/0x1" esp.908d713a at PROVIDER_PUBLIC_IP 
esp.43855675 at 192.168.60.10 tun.0 at PROVIDER_PUBLIC_IP tun.0 at 192.168.60.10 
ref=0 refhim=4294901761
000 #458: "provider/0x1":4500 STATE_MAIN_I4 (ISAKMP SA established); 
EVENT_SA_REPLACE in 27088s; newest ISAKMP; lastdpd=17s(seq in:0 out:0); 
idle; import:admin initiate
000 #459: "provider/0x2":4500 STATE_QUICK_I2 (sent QI2, IPsec SA 
established); EVENT_SA_REPLACE in 1947s; newest IPSEC; eroute owner; 
isakmp#458; idle; import:admin initiate
000 #459: "provider/0x2" esp.5efdb3f7 at PROVIDER_PUBLIC_IP 
esp.67195cef at 192.168.60.10 tun.0 at PROVIDER_PUBLIC_IP tun.0 at 192.168.60.10 
ref=0 refhim=4294901761
000


Here is the Source Nat configuration on the ipsec endpoint:

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
SNAT       all  --  192.168.50.4         10.129.128.101 to:10.129.46.170
SNAT       all  --  192.168.50.4         10.128.243.223 to:10.129.46.169
MASQUERADE  all  --  192.168.50.0/24      anywhere

If I try a telnet from the host on the customer site to  one of the host 
in provider site, the telnet doesn't work. I can see in the file of the 
nat translation the following:
packets=6 bytes=360 [UNREPLIED] src=10.129.128.101 dst=10.129.46.170 
sport=23 dport=46032 packets=0 bytes=0 mark=0 secmark=0 use=2

I've asked to the provider IT Group to check if they receive traffic 
from our host...They used an ACL to log the traffic from our host; they 
confirmed that the tunnels are up but no traffic was arrived into their 
network:

access-list outside_cryptomap_161 extended permit ip host 10.129.128.101 
10.129.46.168 255.255.255.248

       local ident (addr/mask/prot/port): 
(10.129.128.101/255.255.255.255/0/0)

       remote ident (addr/mask/prot/port): 
(10.129.46.168/255.255.255.248/0/0)

       current_peer: CUSTOMER_PUBLIC_IP



       #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0

       #pkts decaps: 0, #pkts decrypt: 0, #pkts verify:

Here there are the ip xfrm policy:

src 10.129.46.168/29 dst 10.129.128.101/32
     dir out priority 2176 ptype main
     tmpl src 192.168.60.10 dst PROVIDER_PUBLIC_IP
         proto esp reqid 16385 mode tunnel
src 10.129.46.168/29 dst 10.128.243.223/32
     dir out priority 2176 ptype main
     tmpl src 192.168.60.10 dst PROVIDER_PUBLIC_IP
         proto esp reqid 16389 mode tunnel
src 10.128.243.223/32 dst 10.129.46.168/29
     dir fwd priority 2176 ptype main
     tmpl src PROVIDER_PUBLIC_IP dst 192.168.60.10
         proto esp reqid 16389 mode tunnel
src 10.128.243.223/32 dst 10.129.46.168/29
     dir in priority 2176 ptype main
     tmpl src PROVIDER_PUBLIC_IP dst 192.168.60.10
         proto esp reqid 16389 mode tunnel
src 10.129.128.101/32 dst 10.129.46.168/29
     dir fwd priority 2176 ptype main
     tmpl src PROVIDER_PUBLIC_IP dst 192.168.60.10
         proto esp reqid 16385 mode tunnel
src 10.129.128.101/32 dst 10.129.46.168/29
     dir in priority 2176 ptype main
     tmpl src PROVIDER_PUBLIC_IP dst 192.168.60.10
         proto esp reqid 16385 mode tunnel
src ::/0 dst ::/0
     dir 4 priority 0 ptype main
src ::/0 dst ::/0
     dir 3 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
     dir 4 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
     dir 3 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
     dir 4 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
     dir 3 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
     dir 4 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
     dir 3 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
     dir 4 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
     dir 3 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
     dir 4 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
     dir 3 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
     dir 4 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
     dir 3 priority 0 ptype main


Here is the traceroute from the customer host:
traceroute to 10.129.128.101 (10.129.128.101), 30 hops max, 60 byte packets
  1  192.168.60.10 (192.168.60.10)  0.356 ms  0.335 ms  0.344 ms
  2  * * *
  3  * * *
  4  * * *
  5  * * *
  6  * * *


I haven't iptables rules that are blocking the traffic:

iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
DROP       all  --  MALICIUS_HOST_IP        anywhere     (old rule,it's 
not related to the ipsec tunnel)

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination


Here is the ipsec verify output:

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
     LANGUAGE = (unset),
     LC_ALL = (unset),
     LANG = "it_IT.UTF-8"
     are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path                                 [OK]
Linux Openswan U2.6.28/K2.6.32-5-xen-686 (netkey)
Checking for IPsec support in kernel                            [OK]
NETKEY detected, testing for disabled ICMP send_redirects       [OK]
NETKEY detected, testing for disabled ICMP accept_redirects     [OK]
Checking that pluto is running                                  [OK]
Pluto listening for IKE on udp 500                              [OK]
Pluto listening for NAT-T on udp 4500                           [OK]
Two or more interfaces found, checking IP forwarding            [OK]
Checking NAT and MASQUERADEing
Checking for 'ip' command                                       [OK]
Checking for 'iptables' command                                 [OK]
Opportunistic Encryption Support [DISABLED]


I also tried to enable or disable the forceencaps, but nothing changed.

So, it seems that the traffic from the customer host isn't send through 
the ipsec tunnel.but why?
I really appreciate if someone can provide any helps!

Thank You!






-- 

-----------------------------------------------------------
*Giovanni Messina*
Systems Operations
tel: *+39 095 388583*
tel/fax: *+39 095 382521*
internet: www.bizmate.it <http://www.bizmate.it/>
mail: giovanni.messina at bizmate.it <mailto:giovanni.messina at bizmate.it>
-----------------------------------------------------------
Bizmate S.r.l. - confidenziale - Tutti i diritti riservati

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

From michaelh at laine.co.za  Wed Dec 14 04:50:04 2016
From: michaelh at laine.co.za (Michael Hubbard)
Date: Wed, 14 Dec 2016 09:50:04 +0000
Subject: [Openswan Users] Tunnel goes down then never comes back up
Message-ID: <AM5PR0701MB2531B7D4F03466E3F6B9B2428D9A0@AM5PR0701MB2531.eurprd07.prod.outlook.com>

Hi,

I'm running OpenSwan on Ubuntu 14.04 for a site-to-site VPN. We have twice managed to get the tunnel up and working but each time it has gone down again shortly after (30-90 minutes after coming up) and then never come back up.

The 2nd time it came up after completely removing and purging Openswan from the system and reinstalling, at which point it wasn't coming up (failing at Phase 2) and after some changes in xl2tpd based on the OpenSwan wiki it suddenly came. Without further input it went down and now won't come up anymore.

It appears to be failing in Phase 2. We've triple checked the config and the remote host is a live system and are adamant their config is correct. The tunnel has come up at some point so it shouldn't be an issue with a config mismatch.

To explain the network topography remote host A sits in front of remote host B, A is connected to the internet. Our server C needs to connect to B. So our server is both establishing the connection and also the system using it, no further subnet. There is no NAT traversal required. If I restart ipsec it just show no tunnels up. If I check the logs there are no errors. If I run ipsec auto -up conn-name it just gets stuck at STATE_QUICK_I1: retransmission.

If I first run ipsec auto -down conn-name and then ipsec auto -verbose -up conn-name I can see what looks to me like Phase 1 is successful. Here is the output:

root at dev ~ # ipsec auto --verbose --up conn-name
002 "easypay-ipsec-vpn" #11: initiating Main Mode
104 "easypay-ipsec-vpn" #11: STATE_MAIN_I1: initiate
003 "easypay-ipsec-vpn" #11: received Vendor ID payload [Dead Peer Detection]
002 "easypay-ipsec-vpn" #11: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2
106 "easypay-ipsec-vpn" #11: STATE_MAIN_I2: sent MI2, expecting MR2
002 "easypay-ipsec-vpn" #11: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
108 "easypay-ipsec-vpn" #11: STATE_MAIN_I3: sent MI3, expecting MR3
002 "easypay-ipsec-vpn" #11: Main mode peer ID is ID_IPV4_ADDR: '111.111.111.85'
002 "easypay-ipsec-vpn" #11: transition from state STATE_MAIN_I3 to state STATE_MAIN_I4
004 "easypay-ipsec-vpn" #11: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha group=modp1024}
002 "easypay-ipsec-vpn" #12: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+DONTREKEY+UP+IKEv2ALLOW+SAREFTRACK {using isakmp#11 msgid:dbb4aee3 proposal=3DES(3)_192-SHA1(2)_160 pfsgroup=OAKLEY_GROUP_MODP1024}
117 "easypay-ipsec-vpn" #12: STATE_QUICK_I1: initiate
010 "easypay-ipsec-vpn" #12: STATE_QUICK_I1: retransmission; will wait 20s for response

The IPSec Conf file (removed comments and changed IPs):

version 2.0     # conforms to second version of ipsec.conf specification

# basic configuration
config setup

        plutodebug=all
        plutostderrlog=/var/log/openswan.log
        dumpdir=/var/run/pluto/
        interfaces=%defaultroute
        nat_traversal=yes
        virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:25.0.0.0/8,%v6:fd00::/8,%v6:fe80::/10
        oe=off
        protostack=netkey

conn easypay-ipsec-vpn
        authby=secret
        auto=start
        aggrmode=no
        ike=3des-sha1;modp1024
        ikelifetime=1440m
        ## phase 1 ##

        keyexchange=ike
        rekey=no
        rekeymargin=3m
        keyingtries=%forever

        ## phase 2 ##
        phase2=esp
        phase2alg=3des-sha1;modp1024
        compress=no
        # Perfect Forward Secrecy
        pfs=yes
        type=tunnel
        left=321.321.321.82
        leftsubnet=321.321.321.82/32
        right=123.123.123.85
        rightsubnet=123.123.123.28/24

Output of ipsec verify:

Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path                                 [OK]
Linux Openswan U2.6.38/K3.13.0-105-generic (netkey)
Checking for IPsec support in kernel                            [OK]
SAref kernel support                                           [N/A]
NETKEY:  Testing XFRM related proc values                      [OK]
        [OK]
        [OK]
Checking that pluto is running                                  [OK]
Pluto listening for IKE on udp 500                             [OK]
Pluto listening for NAT-T on udp 4500                          [OK]
Two or more interfaces found, checking IP forwarding        Checking NAT and MASQUERADEing                                      [OK]
Checking for 'ip' command                                       [OK]
Checking /bin/sh is not /bin/dash                               [WARNING]
Checking for 'iptables' command                                 [OK]
Opportunistic Encryption Support                                [DISABLED]


Syslog from restarting ipsec:

Dec 14 11:47:36 dev ipsec_setup: Stopping Openswan IPsec...
Dec 14 11:47:37 dev kernel: [86214.880112] NET: Unregistered protocol family 15
Dec 14 11:47:37 dev ipsec_setup: ...Openswan IPsec stopped
Dec 14 11:47:37 dev kernel: [86214.938903] NET: Registered protocol family 15
Dec 14 11:47:37 dev ipsec_setup: Starting Openswan IPsec U2.6.38/K3.13.0-105-generic...
Dec 14 11:47:37 dev ipsec_setup: Using NETKEY(XFRM) stack
Dec 14 11:47:37 dev kernel: [86215.022321] Initializing XFRM netlink socket
Dec 14 11:47:37 dev kernel: [86215.088946] AVX2 instructions are not detected.
Dec 14 11:47:37 dev kernel: [86215.114049] AVX2 or AES-NI instructions are not detected.
Dec 14 11:47:37 dev ipsec_setup: ...Openswan IPsec started
Dec 14 11:47:37 dev pluto: adjusting ipsec.d to /etc/ipsec.d
Dec 14 11:47:37 dev ipsec__plutorun: 002 added connection description "conn-name"
Dec 14 11:47:37 dev ipsec__plutorun: 104 "conn-name" #1: STATE_MAIN_I1: initiate

Pluto log is just full of retransmits. No PSK error, nothing else.
The current status is that I am unable to even get the tunnel up, let alone understand why it won't stay up. Any assistance would be greatly appreciated, if any other info is required I will be happy to supply.

Cheers,

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openswan.org/pipermail/users/attachments/20161214/15e5f47b/attachment-0001.html>

From shussain at xelerance.com  Sun Dec 18 20:48:06 2016
From: shussain at xelerance.com (Samir Hussain)
Date: Sun, 18 Dec 2016 20:48:06 -0500
Subject: [Openswan Users] Fwd: tools to monitor and get status on ipsec
	tunnels
Message-ID: <ab630f41-7084-7782-81a4-5b0a9634232d@xelerance.com>

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


-------- Forwarded Message --------
Subject: 	tools to monitor and get status on ipsec tunnels
Date: 	Sun, 18 Dec 2016 20:46:07 -0500
From: 	Kevin Oxley <koxley at ssi-corp.com>
To: 	users at lists.openswan.org




I'm looking for command lines and/or tools to get more visibility into
my ipsec tunnels established using openswan.

At a basic level, I'd like to see how long a tunnel has been up and
running, and a history of when each tunnel goes down and up so I can see
if the tunnel is bouncing.
On a longer term basis, I'd like to have a monitoring capability to get
email notifications when the tunnel changes state.

Any advice and/or pointers would be appreciated.


Thanks,


Kevin




From Bjoern.Mittelsdorf at scheer-group.com  Tue Dec 20 02:09:03 2016
From: Bjoern.Mittelsdorf at scheer-group.com (Mittelsdorf, Bjoern)
Date: Tue, 20 Dec 2016 07:09:03 +0000
Subject: [Openswan Users] tools to monitor and get status on ipsec
Message-ID: <1203390a58624864aee1bd6e2a6c3eae@sgrpexc001.scheer.systems>

Hi Kevin,

interesting question. I hope my uneducated answer will inspire more talented people to join the discussion :-)

We are using tcpdump to diagnose the tunnels. Monitoring the endpoint ips gives you hints about when the renegotiation fails while monitoring the tunneled packets shows firewall blocking and routing issues.
Of course there is no automation in this.

I was not able so far to get the pluto.log to log warnings or error messages I am able to understand but setting loglevel debug might be an option for you. In our cases it is of little help because in fact the tunnels are robust when configured correctly. Most issues we experience are as said above about routing and firewalls in the subnets.

Cheers
Björn


-------- Forwarded Message --------
Subject: 	tools to monitor and get status on ipsec tunnels
Date: 	Sun, 18 Dec 2016 20:46:07 -0500
From: 	Kevin Oxley <koxley at ssi-corp.com>
To: 	users at lists.openswan.org

I'm looking for command lines and/or tools to get more visibility into my ipsec tunnels established using openswan.

At a basic level, I'd like to see how long a tunnel has been up and running, and a history of when each tunnel goes down and up so I can see if the tunnel is bouncing.
On a longer term basis, I'd like to have a monitoring capability to get email notifications when the tunnel changes state.

Any advice and/or pointers would be appreciated.



From m4rtntns at gmail.com  Thu Dec 22 12:29:17 2016
From: m4rtntns at gmail.com (Martin T)
Date: Thu, 22 Dec 2016 19:29:17 +0200
Subject: [Openswan Users] both tunneled/encrypted traffic and decrypted
 traffic are seen in the package remote destination network interface
Message-ID: <CAJx5YvEWv9GW17JJmpXJKxf05N5G_f5rrjBM4q+9WpaLMwVqfQ@mail.gmail.com>

Hi,

I have configured site-to-site VPN connection between two servers and
when I send ICMP "echo request" messages from "srv1" to "srv2" and
tcpdump traffic on "srv2" with "tcpdump -nei eth0 not 'tcp port 22'"
command, then I see following packages:

17:20:03.235088 84:b5:9c:f9:f0:30 > 7a:16:4e:85:51:ad, ethertype IPv4
(0x0800), length 174: 187.166.74.145.4500 > 45.101.2.222.4500:
UDP-encap: ESP(spi=0xd86852ae,seq=0x1), length 132
17:20:03.235088 84:b5:9c:f9:f0:30 > 7a:16:4e:85:51:ad, ethertype IPv4
(0x0800), length 98: 187.166.74.145 > 10.10.12.1: ICMP echo request,
id 30103, seq 1, length 64

As seen above, for some reason both encrypted and decrypted packages
are seen. I would expect only the encrypted package.

However, if I do "tcpdump -nei eth0 not 'tcp port 22'" in "srv1", then
I see only the tunneled/encrypted traffic as expected.

What is the reason that tcpdump sees the decrypted traffic on eth0
interface in "srv2"? Is this an expected behavior?


thanks,
Martin

From gmkrab at gmail.com  Fri Dec 23 05:12:01 2016
From: gmkrab at gmail.com (Aleksey Kravchenko)
Date: Fri, 23 Dec 2016 13:12:01 +0300
Subject: [Openswan Users] IKEv2 + freeradius + LDAP
Message-ID: <CAF1fUBTkNoyNEF04Hm-9L0wiQXq0efQ7_njN-ECNeTsKxEUSeQ@mail.gmail.com>

Good day! Can you help?
I want configure Strongswan IKEv2 with OpenLdap authentication. Is it real?
I configure freeradius + LDAP, try radtest with ldap user adam, test OK:

*radtest adam password1234 myip 10 password1234*

Sent Access-Request Id 142 from 0.0.0.0:46701 to myip:1812 length 74
User-Name = "adam"
User-Password = "password1234"
NAS-IP-Address = 127.0.1.1
NAS-Port = 10
Message-Authenticator = 0x00
Cleartext-Password = "password1234"
Received *Access-Accept* Id 142 from myip:1812 to 0.0.0.0:0 length 20

*Log from radius server: *
radius_1  | Fri Dec 23 08:54:02 2016 : Info: rlm_ldap (ldap): Opening
additional connection (38)
Log from ldap server:
585ce62a conn=1206 op=0 BIND dn="cn=admin,dc=***,dc=***" method=128
585ce62a conn=1206 op=0 BIND dn="cn=admin,dc=***,dc=***" mech=SIMPLE ssf=0
585ce62a conn=1206 op=0 RESULT tag=97 err=0 text=

585ce62a conn=1206 op=1 MOD dn="uid=adam,dc=***,dc=***"
585ce62a conn=1206 op=1 MOD attr=description

585ce62a conn=1206 op=1 RESULT tag=103 err=0 text=



Then I connect  android strongswan client with strongswan server and
received response from ldap:

radius log: radius_1  | Fri Dec 23 09:01:46 2016 : Info: rlm_ldap (ldap):
Opening additional connection (42)
ldap log:
585ce821 conn=1211 fd=17 ACCEPT from IP=*.*.*.*:46089
<http://78.46.192.19:46089/> (IP=0.0.0.0:389)
585ce821 conn=1211 op=0 BIND dn="cn=admin,dc=***,dc=***" method=128
585ce821 conn=1211 op=0 BIND dn="cn=dn="cn=admin,dc=***,dc=***" mech=SIMPLE
ssf=0
585ce821 conn=1211 op=0 RESULT tag=97 err=0 text=


*Strongswan client log:*

Dec 23 12:04:23 12[NET] sending packet: from 192.168.88.18[37418] to
*** [4500] (3612 bytes)
Dec 23 12:04:23 13[NET] received packet: from *** [4500] to
192.168.88.18[37418] (1196 bytes)
Dec 23 12:04:23 13[ENC] parsed IKE_AUTH response 1 [ IDr CERT AUTH EAP/REQ/ID ]
Dec 23 12:04:23 13[IKE] received end entity cert "C=CA, O=Example, CN=*.*"
Dec 23 12:04:23 13[CFG]   using certificate "C=CA, O=Example, CN=*.*"
Dec 23 12:04:23 13[CFG]   using trusted ca certificate "C=CA,
O=Example, CN=ExampleCA"
Dec 23 12:04:23 13[CFG]   reached self-signed root ca with a path length of 0
Dec 23 12:04:23 13[IKE] authentication of '*.*' with RSA signature successful
Dec 23 12:04:23 13[IKE] server requested EAP_IDENTITY (id 0x00), sending 'adam'
Dec 23 12:04:23 13[ENC] generating IKE_AUTH request 2 [ EAP/RES/ID ]
Dec 23 12:04:23 13[NET] sending packet: from 192.168.88.18[37418] to
*.*.*.*[4500] (76 bytes)
Dec 23 12:04:23 14[NET] received packet: from *.*.*.*[4500] to
192.168.88.18[37418] (92 bytes)
Dec 23 12:04:23 14[ENC] parsed IKE_AUTH response 2 [ EAP/REQ/MD5 ]
Dec 23 12:04:23 14[IKE] server requested EAP_MD5 authentication (id 0x01)
Dec 23 12:04:23 14[ENC] generating IKE_AUTH request 3 [ EAP/RES/MD5 ]
Dec 23 12:04:23 14[NET] sending packet: from 192.168.88.18[37418] to
*.*.*.*[4500] (92 bytes)
Dec 23 12:04:24 15[NET] received packet: from *.*.*.* [4500] to
192.168.88.18[37418] (76 bytes)
Dec 23 12:04:24 15[ENC] parsed IKE_AUTH response 3 [ EAP/FAIL ]
Dec 23 12:04:24 15[IKE] *received EAP_FAILURE, EAP authentication failed*
Dec 23 12:04:24 15[ENC] generating INFORMATIONAL request 4 [ N(AUTH_FAILED) ]
Dec 23 12:04:24 15[NET] sending packet: from 192.168.88.18[37418] to
*.*.*.* [4500] (76 bytes)



*SYSTEM INFORMATION:*

*uname -a*
Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) x86_64
GNU/Linux

*ipsec --version*

Linux strongSwan U5.2.1/K3.16.0-4-amd64

*ipsec listplugins | grep EAP*

    EAP_SERVER:ID
    EAP_CLIENT:ID
    EAP_SERVER:AKA
    EAP_CLIENT:AKA
    EAP_SERVER:MD5
    EAP_CLIENT:MD5
    EAP_SERVER:GTC
    EAP_CLIENT:GTC
    EAP_SERVER:MSCHAPV2
    EAP_CLIENT:MSCHAPV2
    EAP_SERVER:RAD
    EAP_SERVER:TLS
    EAP_CLIENT:TLS
    EAP_SERVER:TTLS
        EAP_SERVER:ID
    EAP_CLIENT:TTLS
        EAP_CLIENT:ID
    EAP_SERVER:TNC
        EAP_SERVER:TTLS
    EAP_CLIENT:TNC
        EAP_CLIENT:TTLS
    EAP_SERVER:PT
        EAP_SERVER:TTLS
    EAP_CLIENT:PT
        EAP_CLIENT:TTLS

*ipsec statusall*

Status of IKE charon daemon (strongSwan 5.2.1, Linux 3.16.0-4-amd64,
x86_64):
  uptime: 2 days, since Dec 20 19:40:27 2016
  malloc: sbrk 2555904, mmap 0, used 421888, free 2134016
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0,
scheduled: 0
  loaded plugins: charon aes rc2 sha1 sha2 md5 random nonce x509 revocation
constraints pubkey pkcs1 pkcs
7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp agent xcbc hmac
gcm attr kernel-netlink resolve
 socket-default farp stroke updown eap-identity eap-aka eap-md5 eap-gtc
eap-mschapv2 eap-radius eap-tls e
ap-ttls eap-tnc xauth-generic xauth-eap xauth-pam tnc-tnccs dhcp lookip
error-notify certexpire led addrb
lock unity
Virtual IP pools (size/online/offline):
  10.9.0.0/24: 254/0/0
Listening IP addresses:
  *.*.*.*
  *.*.*.*
Connections:
      client:  %any...%any  IKEv2, dpddelay=30s
      client:   local:  [*.*] uses public key authentication
      client:    cert:  "C=CA, O=Example, CN=*.*"
      client:   remote: uses EAP_RADIUS authentication with EAP identity
'%any'
      client:   child:  0.0.0.0/0 === dynamic TUNNEL, dpdaction=clear
Security Associations (0 up, 0 connecting):
  none


*Thank you!*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openswan.org/pipermail/users/attachments/20161223/0d717f2b/attachment.html>

From m4rtntns at gmail.com  Fri Dec 23 13:05:30 2016
From: m4rtntns at gmail.com (Martin T)
Date: Fri, 23 Dec 2016 20:05:30 +0200
Subject: [Openswan Users] both tunneled/encrypted traffic and decrypted
 traffic are seen in the package remote destination network interface
In-Reply-To: <CAJx5YvEWv9GW17JJmpXJKxf05N5G_f5rrjBM4q+9WpaLMwVqfQ@mail.gmail.com>
References: <CAJx5YvEWv9GW17JJmpXJKxf05N5G_f5rrjBM4q+9WpaLMwVqfQ@mail.gmail.com>
Message-ID: <CAJx5YvEnyJU15NhTr-mLb3HATMGpnonwkZqLNts0hVA9R0n8=A@mail.gmail.com>

Hi,

look like this is indeed expected behavior:
https://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg


regards,
Martin

On Thu, Dec 22, 2016 at 7:29 PM, Martin T <m4rtntns at gmail.com> wrote:
> Hi,
>
> I have configured site-to-site VPN connection between two servers and
> when I send ICMP "echo request" messages from "srv1" to "srv2" and
> tcpdump traffic on "srv2" with "tcpdump -nei eth0 not 'tcp port 22'"
> command, then I see following packages:
>
> 17:20:03.235088 84:b5:9c:f9:f0:30 > 7a:16:4e:85:51:ad, ethertype IPv4
> (0x0800), length 174: 187.166.74.145.4500 > 45.101.2.222.4500:
> UDP-encap: ESP(spi=0xd86852ae,seq=0x1), length 132
> 17:20:03.235088 84:b5:9c:f9:f0:30 > 7a:16:4e:85:51:ad, ethertype IPv4
> (0x0800), length 98: 187.166.74.145 > 10.10.12.1: ICMP echo request,
> id 30103, seq 1, length 64
>
> As seen above, for some reason both encrypted and decrypted packages
> are seen. I would expect only the encrypted package.
>
> However, if I do "tcpdump -nei eth0 not 'tcp port 22'" in "srv1", then
> I see only the tunneled/encrypted traffic as expected.
>
> What is the reason that tcpdump sees the decrypted traffic on eth0
> interface in "srv2"? Is this an expected behavior?
>
>
> thanks,
> Martin

From m4rtntns at gmail.com  Sat Dec 24 05:46:01 2016
From: m4rtntns at gmail.com (Martin T)
Date: Sat, 24 Dec 2016 12:46:01 +0200
Subject: [Openswan Users] Difference between algorithms wanted and
	algorithms found?
Message-ID: <CAJx5YvHYbhmVYy5Nd2JJDgxqYnu4Cbo0m8fuRkw30NbcHD0U7Q@mail.gmail.com>

Hi,

in the output of "ipsec auto --status" I can see following algorithms
wanted and algorithms found statements:

000 "test":   IKE algorithms wanted:
AES_CBC(7)_128-SHA1(2)_000-MODP1024(2); flags=-strict
000 "test":   IKE algorithms found:  AES_CBC(7)_128-SHA1(2)_160-MODP1024(2)
000 "test":   ESP algorithms wanted: AES(12)_128-SHA1(2)_000;
pfsgroup=MODP1024(2); flags=-strict
000 "test":   ESP algorithms loaded: AES(12)_128-SHA1(2)_160

1) Am I correct that algorithms wanted are the ones stated with "ike"
and "phase2alg" configuration options and algorithms found are the
ones which are actually used?

2) Is there a way to list all possible supported algorithms?


thanks,
Martin