From doka.ua at gmx.com  Mon Dec  2 11:26:39 2019
From: doka.ua at gmx.com (Volodymyr Litovka)
Date: Mon, 2 Dec 2019 12:26:39 +0200
Subject: [strongSwan] vici/python interface errors
Message-ID: <c76d3d1a-f1a6-8ec3-f19c-45bd3083b1c0@gmx.com>

Dear friends,

I'm trying to manage connections over Vici socket using Python API and
getting an error when terminating SAS. I'm doing according to
https://www.strongswan.org/apidoc/md_src_libcharon_plugins_vici_README.html
(part terminate()) which says, that connection can be terminated by
using either (?):
1) configuration name of CHILD_SA
2) configuration name of IKE_SA
3) reqid of CHILD_SA
4) unique id of IKE_SA

The sample code try to terminate connection using unique id of IKE_SA:

v = vici.Session()

for s in v.list_sas():
     conn = s.get('ikev2-eap-mschapv2', None)    # This is connection name in swanctl.conf
     if conn:
         rem_id = conn['remote-id'].decode()
         uniq_id = int(conn['uniqueid'].decode())	# Same error regardless of byte, string or integer interpretation
         print(f"Connection {rem_id} has an ID {uniq_id}")
         if rem_id == 'doka':
             print('Terminating')
             t = v.terminate({
                 'ike-id': uniq_id,
                 'timeout': -1
             })
             for c in t:
                 pass
             exit(0)

The result of execution is:

Connection doka has an ID 379
Terminating
Exception ignored in: <generator object Session.streamed_request at 0x7fccd4d5c6d0>
Traceback (most recent call last):
   File "/home/doka/PyDev/lib/python3.6/site-packages/vici/session.py", line 128, in streamed_request
     response=Packet.CMD_RESPONSE
vici.exception.SessionException: Unexpected response type 5, expected '1' (CMD_RESPONSE)
Traceback (most recent call last):
   File "./vit.py", line 22, in <module>
     for c in t:
   File "/home/doka/PyDev/lib/python3.6/site-packages/vici/session.py", line 103, in streamed_request
     self._register_unregister(event_stream_type, True)
   File "/home/doka/PyDev/lib/python3.6/site-packages/vici/session.py", line 49, in _register_unregister
     confirm=Packet.EVENT_CONFIRM,
vici.exception.SessionException: Unexpected response type 1, expected '5' (EVENT_CONFIRM)

so, just calling generator, returned by terminate() ("for c in t"), lead
to the error. On the other hand, calling swanctl with same parameters
results in success termination of connection:

# swanctl --terminate --ike-id 379 --debug --pretty
[IKE] deleting IKE_SA ikev2-eap-mschapv2[379] between x.x.x.x[my.swan.host]...y.y.y.y[doka]
[IKE] sending DELETE for IKE_SA ikev2-eap-mschapv2[379]
[ENC] generating INFORMATIONAL request 0 [ D ]
[NET] sending packet: from x.x.x.x[4500] to y.y.y.y[4500] (80 bytes)
[NET] received packet: from y.y.y.y[4500] to x.x.x.x[4500] (80 bytes)
[ENC] parsed INFORMATIONAL response 0 [ ]
[IKE] IKE_SA deleted


So, the question is - what I'm doing wrong and how to do in order to get
the desired result?

Environment: Ubuntu 18.04, Strongswan 5.6.2 (latest available from
Ubuntu repo), vici==5.8.0 (but same error appears when using
vici=5.5.3), Python 3.6

Thank you.

--
Volodymyr Litovka
   "Vision without Execution is Hallucination." -- Thomas Edison

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20191202/aa11cbd2/attachment.html>

From tobias at strongswan.org  Tue Dec  3 12:37:04 2019
From: tobias at strongswan.org (Tobias Brunner)
Date: Tue, 3 Dec 2019 12:37:04 +0100
Subject: [strongSwan] vici/python interface errors
In-Reply-To: <c76d3d1a-f1a6-8ec3-f19c-45bd3083b1c0@gmx.com>
References: <c76d3d1a-f1a6-8ec3-f19c-45bd3083b1c0@gmx.com>
Message-ID: <2a28283c-5488-c356-2cee-f8655615e295@strongswan.org>

Hi Volodymyr,

> So, the question is - what I'm doing wrong and how to do in order to get
> the desired result?

You can't use the same session you are currently streaming on (i.e.
enumerating SAs) to send another request (i.e. terminating SAs).

So either store the IDs of the SAs you want to terminate in a list and
terminate them after you are done enumerating SAs, or open a second
session to terminate them while enumerating.

Regards,
Tobias

From tobias at strongswan.org  Tue Dec  3 12:39:21 2019
From: tobias at strongswan.org (Tobias Brunner)
Date: Tue, 3 Dec 2019 12:39:21 +0100
Subject: [strongSwan] vici/python interface errors
In-Reply-To: <65f15d8c-1ff9-ca03-e03e-41908f79f9e9@gmx.com>
References: <c76d3d1a-f1a6-8ec3-f19c-45bd3083b1c0@gmx.com>
 <c996b014-1a60-a2b9-dfdb-346311520bd4@strongswan.org>
 <65f15d8c-1ff9-ca03-e03e-41908f79f9e9@gmx.com>
Message-ID: <657eab7c-f6b1-e908-029c-2342331a65f5@strongswan.org>

Hi Volodymyr,

> thanks a lot, it works. It worth to say, that timeout must be set to
> reasonable value to allow Strongswan to finish the task. If set to -1 or
> few milliseconds, it returns failure as well :)

If you are referring to the returned error "terminating SA failed",
that's because with -1 (or a short timeout) the code doesn't wait until
the termination is fully completed (a regular termination causes DELETEs
to be sent and until the peer either replies, or there is a timeout
after several retransmits, it is not complete).  So you get that error
because VICI doesn't know if the SA was actually terminated.  The
termination is still initiated unless you receive the error "no matching
SAs to terminate found", it just happens in the background.

If you don't want to wait and send retransmits for DELETEs, use the
"force" option, optionally combined with a timeout, so the code waits
for a reply to the DELETEs for a while and then destroys the SA even if
none was received.

Regards,
Tobias

From doka.ua at gmx.com  Tue Dec  3 12:50:31 2019
From: doka.ua at gmx.com (Volodymyr Litovka)
Date: Tue, 3 Dec 2019 13:50:31 +0200
Subject: [strongSwan] vici/python interface errors
In-Reply-To: <657eab7c-f6b1-e908-029c-2342331a65f5@strongswan.org>
References: <c76d3d1a-f1a6-8ec3-f19c-45bd3083b1c0@gmx.com>
 <c996b014-1a60-a2b9-dfdb-346311520bd4@strongswan.org>
 <65f15d8c-1ff9-ca03-e03e-41908f79f9e9@gmx.com>
 <657eab7c-f6b1-e908-029c-2342331a65f5@strongswan.org>
Message-ID: <02824394-f387-7f3d-04ed-7ecb6861ee23@gmx.com>

Hi Tobias,

in fact, I see a bit different behaviour. Having the following code:

     t = v.terminate({
         'ike-id': ike_id,
         'timeout': 5000
     })
     try:
         for c in t:
             pass
     except Exception as e:
         print(e)

nothing happens to IKE_SA if I omit "for c in t" statement - Strongswan
don't report in the log "12[CFG] vici terminate IKE_SA #nnn" and don't
start processing, regardless of timeout and force parameters.

Processing starts only upon iterating of "t". This is every-time
reproduceable behaviour.

On 03.12.2019 13:39, Tobias Brunner wrote:
> Hi Volodymyr,
>
>> thanks a lot, it works. It worth to say, that timeout must be set to
>> reasonable value to allow Strongswan to finish the task. If set to -1 or
>> few milliseconds, it returns failure as well :)
> If you are referring to the returned error "terminating SA failed",
> that's because with -1 (or a short timeout) the code doesn't wait until
> the termination is fully completed (a regular termination causes DELETEs
> to be sent and until the peer either replies, or there is a timeout
> after several retransmits, it is not complete).  So you get that error
> because VICI doesn't know if the SA was actually terminated.  The
> termination is still initiated unless you receive the error "no matching
> SAs to terminate found", it just happens in the background.
>
> If you don't want to wait and send retransmits for DELETEs, use the
> "force" option, optionally combined with a timeout, so the code waits
> for a reply to the DELETEs for a while and then destroys the SA even if
> none was received.
>
> Regards,
> Tobias

--
Volodymyr Litovka
   "Vision without Execution is Hallucination." -- Thomas Edison

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20191203/36c4b789/attachment.html>

From tobias at strongswan.org  Tue Dec  3 13:10:22 2019
From: tobias at strongswan.org (Tobias Brunner)
Date: Tue, 3 Dec 2019 13:10:22 +0100
Subject: [strongSwan] vici/python interface errors
In-Reply-To: <02824394-f387-7f3d-04ed-7ecb6861ee23@gmx.com>
References: <c76d3d1a-f1a6-8ec3-f19c-45bd3083b1c0@gmx.com>
 <c996b014-1a60-a2b9-dfdb-346311520bd4@strongswan.org>
 <65f15d8c-1ff9-ca03-e03e-41908f79f9e9@gmx.com>
 <657eab7c-f6b1-e908-029c-2342331a65f5@strongswan.org>
 <02824394-f387-7f3d-04ed-7ecb6861ee23@gmx.com>
Message-ID: <0d3f0731-0773-701e-71bc-dfde6bc59c05@strongswan.org>

Hi Volodymyr,

> Processing starts only upon iterating of "t". This is every-time
> reproduceable behaviour.

That's because terminate() (and any other command wrapper that uses
streamed_request()) returns a Python generator, which is only evaluated
once you enumerate it.  If you are not interested in log messages (in
particular with timeout set to -1, in which case none will be returned
anyway) you could also send the request directly with

    v.request('terminate', {
        'ike-id': ike_id,
        'timeout': ...
    })

Regards,
Tobias

From doka.ua at gmx.com  Tue Dec  3 20:25:13 2019
From: doka.ua at gmx.com (Volodymyr Litovka)
Date: Tue, 3 Dec 2019 21:25:13 +0200
Subject: [strongSwan] vici/python interface errors
In-Reply-To: <0d3f0731-0773-701e-71bc-dfde6bc59c05@strongswan.org>
References: <c76d3d1a-f1a6-8ec3-f19c-45bd3083b1c0@gmx.com>
 <c996b014-1a60-a2b9-dfdb-346311520bd4@strongswan.org>
 <65f15d8c-1ff9-ca03-e03e-41908f79f9e9@gmx.com>
 <657eab7c-f6b1-e908-029c-2342331a65f5@strongswan.org>
 <02824394-f387-7f3d-04ed-7ecb6861ee23@gmx.com>
 <0d3f0731-0773-701e-71bc-dfde6bc59c05@strongswan.org>
Message-ID: <b3cea673-c679-c010-d385-dda1b6a19403@gmx.com>

Great, Tobias,

thanks!

On 03.12.2019 14:10, Tobias Brunner wrote:
> Hi Volodymyr,
>
>> Processing starts only upon iterating of "t". This is every-time
>> reproduceable behaviour.
> That's because terminate() (and any other command wrapper that uses
> streamed_request()) returns a Python generator, which is only evaluated
> once you enumerate it.  If you are not interested in log messages (in
> particular with timeout set to -1, in which case none will be returned
> anyway) you could also send the request directly with
>
>      v.request('terminate', {
>          'ike-id': ike_id,
>          'timeout': ...
>      })
>
> Regards,
> Tobias

--
Volodymyr Litovka
   "Vision without Execution is Hallucination." -- Thomas Edison

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20191203/d1b37a70/attachment-0001.html>

From amstaff.zg at gmail.com  Wed Dec  4 15:01:19 2019
From: amstaff.zg at gmail.com (Amstaff zg)
Date: Wed, 4 Dec 2019 15:01:19 +0100
Subject: [strongSwan] strongswan memory leak v 5.6.3
Message-ID: <CANaC7ymKNM6AV-DbuB-94G-Xnm6s==Jny5KoZvprNRaCGn+Kdg@mail.gmail.com>

Hi all,
I've noticed a memory leak on my VPN servers and everything points to
memory leak in strongswan.

My configuration is:

config setup
        charondebug="ike 1, knl 1, cfg 0"
        uniqueids=no
        strictcrlpolicy=no

conn %default
        ikelifetime=30m
        keylife=10m
        rekeymargin=3m
        keyingtries=1
        keyexchange=ikev2
        ike=aes256-sha256-modp1024,aes128-sha256-ecp256,aes256-sha384-ecp384,aes128-sha256-modp2048,aes128-sha1-modp2048,aes256-sha384-modp4096,aes256-sha256-modp4096,aes256-sha1-modp4096,aes128-sha256-modp1536,aes128-sha1-modp1536,aes256-sha384-modp2048,aes256-sha256-modp2048,aes256-sha1-modp2048,aes128-sha256-modp1024,aes128-sha1-modp1024,aes256-sha384-modp1536,aes256-sha256-modp1536,aes256-sha1-modp1536,aes256-sha384-modp1024,aes256-sha256-modp1024,aes256-sha1-modp1024!
    esp=aes256gcm16-modp1024-modp2048,aes128gcm16-ecp256,aes256gcm16-ecp384,aes128-sha256-ecp256,aes256-sha384-ecp384,aes128-sha256-modp2048,aes128-sha1-modp2048,aes256-sha384-modp4096,aes256-sha256-modp4096,aes256-sha1-modp4096,aes128-sha256-modp1536,aes128-sha1-modp1536,aes256-sha384-modp2048,aes256-sha256-modp2048,aes256-sha1-modp2048,aes128-sha256-modp1024,aes128-sha1-modp1024,aes256-sha384-modp1536,aes256-sha256-modp1536,aes256-sha1-modp1536,aes256-sha384-modp1024,aes256-sha256-modp1024,aes256-sha1-modp1024,aes128gcm16,aes256gcm16,aes128-sha256,aes128-sha1,aes256-sha384,aes256-sha256,aes256-sha1!

conn android
        left=%any
        leftsubnet=0.0.0.0/0
        leftcert=server.cert.pem
        leftauth=pubkey
    rekey=no
        rightauth=eap-radius
        rightsendcert=never
        right=%any
        rightsourceip=10.200.0.0/16
    eap_identity=%identity
    dpdaction=clear
    dpddelay=30s
    dpdtimeout=200s
        auto=add

conn ios
    left=%any
    leftid=xxxxxxxxxxxxxxxxxx
    leftsubnet=0.0.0.0/0
    leftcert=server.cert.pem
    leftsendcert=always
    right=%any
    rightauth=eap-radius
    rightsourceip=10.200.0.0/16
    eap_identity=%identity
    auto=add

Anyone had similar issues?

Thanks.

BR,
Kreso

From Anthony.Modster at Teledyne.com  Wed Dec 11 00:59:55 2019
From: Anthony.Modster at Teledyne.com (Modster, Anthony)
Date: Tue, 10 Dec 2019 23:59:55 +0000
Subject: [strongSwan] dynamic user cert updates
Message-ID: <BN7PR14MB2195A766F9F9DD104F70F7A6885B0@BN7PR14MB2195.namprd14.prod.outlook.com>

Hello

We cant seem to update our user cert dynamically ( without stopping charon ).

Our procedure is

  *   Load User Cert 1 into /etc/swanctl/x509/my-cert.crt
  *   vici_do_load()->load_conn()
  *   vici_do_connect()->init_conn()
  *   VPN tunnel comes up
  *   swanctl --list-certs, User Cert serial number is 0e
  *   vici_do_disconnect()->terminate_conn()
  *   vici_do_unload()->unload_conn()
  *   copy User Cert 2 into /etc/swanctl/x509/my-cert.crt
  *   vici_do_load()->load_conn()
  *   vici_do_connect()->init_conn()
  *   swanctl --list-certs, User Cert serial number is 0e (but it should be 0e)

Thanks

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20191210/cd8983bd/attachment.html>

From matt at mpirik.com  Wed Dec 11 19:16:48 2019
From: matt at mpirik.com (Matt Frederick)
Date: Wed, 11 Dec 2019 12:16:48 -0600
Subject: [strongSwan] source NAT
Message-ID: <CAFGgMvAaJMC_bUgdAk3zZJxCqPwSGtQ=8pWk7LDs64Nd3U=LHA@mail.gmail.com>

Hi - I'd like to hide all of network A behind a NAT as it enters the tunnel
bound for network B. Is there an option in ipsec.conf that I don't see
which would allow me to do that? Or should I stick with iptables rules?
thanks! -matt

-- 










*Confidentiality and Privacy Notice: *Information transmitted by 
this email is proprietary to [m]pirik and is intended for use only by the 
individual or entity to which it is addressed, and may contain information 
that is private, privileged, confidential or exempt from disclosure under 
applicable law. All personal messages express views solely of the sender, 
are not to be attributed to [m]pirik, and may not be copied or distributed 
without this disclaimer. If you are not the intended recipient or it 
appears that this mail has been forwarded to you without proper authority, 
you are notified that any use or dissemination of this information in any 
manner is strictly prohibited. In such cases, please delete this mail from 
your records.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20191211/0e636c14/attachment.html>

From harri at afaics.de  Wed Dec 11 22:39:14 2019
From: harri at afaics.de (Harald Dunkel)
Date: Wed, 11 Dec 2019 22:39:14 +0100
Subject: [strongSwan] road warrior MTU issues (IPv4)
Message-ID: <1650ecdc-551b-c5bf-6a66-b14127668a47@afaics.de>

Hi folks,

apparently the MacOS road warriors have to manually adjust the MTU on
ipsec0 to 1280 in some networks, e.g. if the IP provider is Unitymedia,
or if they travel in an ICE of Deutsche Bahn and use the free Wifi.
Without *sudo ifconfig ipsec0 mtu 1280* their IPsec connection appears
to be broken.

Problem is, setting the MTU on MacOS is not persistent. On the next
IPsec connection MacOS has lost the adjusted MTU and goes with the
default 1400 again.

Since the peer runs Strongswan on Linux, I wonder if there is something
that can be done on this side? Is this purely MacOS' fault for not
fragmenting payload accordingly?


Every helpful comment is highly appreciated.

Harri

From Anthony.Modster at Teledyne.com  Wed Dec 11 22:42:34 2019
From: Anthony.Modster at Teledyne.com (Modster, Anthony)
Date: Wed, 11 Dec 2019 21:42:34 +0000
Subject: [strongSwan] road warrior MTU issues (IPv4)
In-Reply-To: <1650ecdc-551b-c5bf-6a66-b14127668a47@afaics.de>
References: <1650ecdc-551b-c5bf-6a66-b14127668a47@afaics.de>
Message-ID: <BN7PR14MB2195EA8BDF7B8E1CC758634F885A0@BN7PR14MB2195.namprd14.prod.outlook.com>

Let use know the answer to this

We also have the same problem on some networks (were are using an embedded system).

-----Original Message-----
From: Users <users-bounces at lists.strongswan.org> On Behalf Of Harald Dunkel
Sent: Wednesday, December 11, 2019 1:39 PM
To: users at lists.strongswan.org
Subject: [strongSwan] road warrior MTU issues (IPv4)

---External Email---

Hi folks,

apparently the MacOS road warriors have to manually adjust the MTU on
ipsec0 to 1280 in some networks, e.g. if the IP provider is Unitymedia, or if they travel in an ICE of Deutsche Bahn and use the free Wifi.
Without *sudo ifconfig ipsec0 mtu 1280* their IPsec connection appears to be broken.

Problem is, setting the MTU on MacOS is not persistent. On the next IPsec connection MacOS has lost the adjusted MTU and goes with the default 1400 again.

Since the peer runs Strongswan on Linux, I wonder if there is something that can be done on this side? Is this purely MacOS' fault for not fragmenting payload accordingly?


Every helpful comment is highly appreciated.

Harri

From felipeapolanco at gmail.com  Wed Dec 11 22:56:09 2019
From: felipeapolanco at gmail.com (Felipe Arturo Polanco)
Date: Wed, 11 Dec 2019 17:56:09 -0400
Subject: [strongSwan] source NAT
In-Reply-To: <CAFGgMvAaJMC_bUgdAk3zZJxCqPwSGtQ=8pWk7LDs64Nd3U=LHA@mail.gmail.com>
References: <CAFGgMvAaJMC_bUgdAk3zZJxCqPwSGtQ=8pWk7LDs64Nd3U=LHA@mail.gmail.com>
Message-ID: <CADcj3=71icrNi+rvHAgkxd2SM4L=xqtXmE9xGMVvqXofkY+=JA@mail.gmail.com>

I believe there isn't an option for that since IPSec does not do NAT.

You can use iptables, ip rule nat and IPVS NAT for that.

On Wed, Dec 11, 2019 at 2:17 PM Matt Frederick <matt at mpirik.com> wrote:
>
> Hi - I'd like to hide all of network A behind a NAT as it enters the tunnel bound for network B. Is there an option in ipsec.conf that I don't see which would allow me to do that? Or should I stick with iptables rules? thanks! -matt
>
>
> Confidentiality and Privacy Notice: Information transmitted by this email is proprietary to [m]pirik and is intended for use only by the individual or entity to which it is addressed, and may contain information that is private, privileged, confidential or exempt from disclosure under applicable law. All personal messages express views solely of the sender, are not to be attributed to [m]pirik, and may not be copied or distributed without this disclaimer. If you are not the intended recipient or it appears that this mail has been forwarded to you without proper authority, you are notified that any use or dissemination of this information in any manner is strictly prohibited. In such cases, please delete this mail from your records.

From harri at afaics.de  Wed Dec 11 23:08:45 2019
From: harri at afaics.de (Harald Dunkel)
Date: Wed, 11 Dec 2019 23:08:45 +0100
Subject: [strongSwan] road warrior MTU issues (IPv4)
In-Reply-To: <1650ecdc-551b-c5bf-6a66-b14127668a47@afaics.de>
References: <1650ecdc-551b-c5bf-6a66-b14127668a47@afaics.de>
Message-ID: <29db17ad-1193-2372-8295-68bfd91d829c@afaics.de>

On 12/11/19 10:39 PM, Harald Dunkel wrote:
> Hi folks,
> 
> apparently the MacOS road warriors have to manually adjust the MTU on
> ipsec0 to 1280 in some networks, e.g. if the IP provider is Unitymedia,
> or if they travel in an ICE of Deutsche Bahn and use the free Wifi.
> Without *sudo ifconfig ipsec0 mtu 1280* their IPsec connection appears
> to be broken.
> 
> Problem is, setting the MTU on MacOS is not persistent. On the next
> IPsec connection MacOS has lost the adjusted MTU and goes with the
> default 1400 again.
> 
> Since the peer runs Strongswan on Linux, I wonder if there is something
> that can be done on this side? Is this purely MacOS' fault for not
> fragmenting payload accordingly?
> 

PS: I found

https://wiki.strongswan.org/projects/strongswan/wiki/ForwardingAndSplitTunneling#MTUMSS-issues

after sending this, but AFAIU reducing the mss affects outgoing TCP traffic
only.


Regards
Harri

From Anthony.Modster at Teledyne.com  Wed Dec 11 23:21:47 2019
From: Anthony.Modster at Teledyne.com (Modster, Anthony)
Date: Wed, 11 Dec 2019 22:21:47 +0000
Subject: [strongSwan] dynamic user cert updates
In-Reply-To: <BN7PR14MB2195A766F9F9DD104F70F7A6885B0@BN7PR14MB2195.namprd14.prod.outlook.com>
References: <BN7PR14MB2195A766F9F9DD104F70F7A6885B0@BN7PR14MB2195.namprd14.prod.outlook.com>
Message-ID: <BN7PR14MB2195F96243AA6422D284FEE5885A0@BN7PR14MB2195.namprd14.prod.outlook.com>

? any thoughts on this item

From: Modster, Anthony
Sent: Tuesday, December 10, 2019 4:00 PM
To: users at lists.strongswan.org
Subject: dynamic user cert updates

Hello

We cant seem to update our user cert dynamically ( without stopping charon ).

Our procedure is

  *   Load User Cert 1 into /etc/swanctl/x509/my-cert.crt
  *   vici_do_load()->load_conn()
  *   vici_do_connect()->init_conn()
  *   VPN tunnel comes up
  *   swanctl --list-certs, User Cert serial number is 0e
  *   vici_do_disconnect()->terminate_conn()
  *   vici_do_unload()->unload_conn()
  *   copy User Cert 2 into /etc/swanctl/x509/my-cert.crt
  *   vici_do_load()->load_conn()
  *   vici_do_connect()->init_conn()
  *   swanctl --list-certs, User Cert serial number is 0e (but it should be 0e)

Thanks

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20191211/a2150df2/attachment-0001.html>

From Anthony.Modster at Teledyne.com  Wed Dec 11 23:29:51 2019
From: Anthony.Modster at Teledyne.com (Modster, Anthony)
Date: Wed, 11 Dec 2019 22:29:51 +0000
Subject: [strongSwan] road warrior MTU issues (IPv4)
In-Reply-To: <29db17ad-1193-2372-8295-68bfd91d829c@afaics.de>
References: <1650ecdc-551b-c5bf-6a66-b14127668a47@afaics.de>
 <29db17ad-1193-2372-8295-68bfd91d829c@afaics.de>
Message-ID: <BN7PR14MB2195EDD0D52AEB8E7BE4C42A885A0@BN7PR14MB2195.namprd14.prod.outlook.com>

These are the providers that have MTU issues for us.

- Panasonic 
- BoardConnect/Inmarsat 
- Verizon
- Vodafone

-----Original Message-----
From: Users <users-bounces at lists.strongswan.org> On Behalf Of Harald Dunkel
Sent: Wednesday, December 11, 2019 2:09 PM
To: users at lists.strongswan.org
Subject: Re: [strongSwan] road warrior MTU issues (IPv4)

---External Email---

On 12/11/19 10:39 PM, Harald Dunkel wrote:
> Hi folks,
> 
> apparently the MacOS road warriors have to manually adjust the MTU on
> ipsec0 to 1280 in some networks, e.g. if the IP provider is 
> Unitymedia, or if they travel in an ICE of Deutsche Bahn and use the free Wifi.
> Without *sudo ifconfig ipsec0 mtu 1280* their IPsec connection appears 
> to be broken.
> 
> Problem is, setting the MTU on MacOS is not persistent. On the next 
> IPsec connection MacOS has lost the adjusted MTU and goes with the 
> default 1400 again.
> 
> Since the peer runs Strongswan on Linux, I wonder if there is 
> something that can be done on this side? Is this purely MacOS' fault 
> for not fragmenting payload accordingly?
> 

PS: I found

https://wiki.strongswan.org/projects/strongswan/wiki/ForwardingAndSplitTunneling#MTUMSS-issues

after sending this, but AFAIU reducing the mss affects outgoing TCP traffic only.


Regards
Harri

From MakarandPradhan at is5com.com  Thu Dec 12 20:31:02 2019
From: MakarandPradhan at is5com.com (Makarand Pradhan)
Date: Thu, 12 Dec 2019 19:31:02 +0000
Subject: [strongSwan] Wrong DH group and hash in IKE phase 1 proposal
Message-ID: <YQBPR0101MB0788F03EE086EEDC0D14FCCC84550@YQBPR0101MB0788.CANPRD01.PROD.OUTLOOK.COM>

Hello Everyone,

I'm trying to set up a tunnel between Strongswan and Cisco 2811. I'm following instructions per:

https://www.cisco.com/c/en/us/support/docs/ip/internet-key-exchange-ike/117258-config-l2l.html

Phase 1 parameters are configured in ipsec.conf as:
	keyexchange=ikev1                                            
	ike=aes128-md5-modp1536                                      

When I try starting up the tunnel, the IKE proposal sent out contains:

Per log on Cisco router:
*Dec 12 21:32:39.438: ISAKMP:      encryption AES-CBC
*Dec 12 21:32:39.438: ISAKMP:      keylength of 128
*Dec 12 21:32:39.438: ISAKMP:      hash SHA256
*Dec 12 21:32:39.438: ISAKMP:      unknown DH group 31
*Dec 12 21:32:39.438: ISAKMP:      auth pre-share
*Dec 12 21:32:39.438: ISAKMP:      life type in seconds
*Dec 12 21:32:39.438: ISAKMP:      life duration (basic) of 1520

I've captured the packet in wireshark and the packet indicates the wrong DH group and wrong hash. I've attached the captured pcap file.

My ipsec.conf file is as follows:

config setup                     
        charondebug=ike 4        
                                                                     
#####IS5#####                                                        
conn m1                                                              
        type=tunnel                                                  
        authby=secret                                                
        auto=add                                                     
        keyexchange=ikev1                                            
        ike=aes128-md5-modp1536                                      
        esp=aes128-sha1                                              
        ikelifetime=1520                                             
        right=80.0.0.3                                               
        rightid=80.0.0.3                                             
        rightsubnet=10.10.3.0/24                                     
        left=80.0.0.2                                                
        leftid=80.0.0.2                                              
        leftsubnet=192.168.0.0/16                               

 I've tried changing to 3DES and SHA512 and different DH groups in ipsec.conf. All the same, I always see AES-SHA256-DHGRP31 going out.

Any opinions or suggestions to correct my ipsec.conf would be highly appreciated.

With rgds,
Makarand.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ipsec.pcap
Type: application/octet-stream
Size: 566 bytes
Desc: ipsec.pcap
URL: <http://lists.strongswan.org/pipermail/users/attachments/20191212/6b645524/attachment.obj>

From Anthony.Modster at Teledyne.com  Thu Dec 12 21:38:10 2019
From: Anthony.Modster at Teledyne.com (Modster, Anthony)
Date: Thu, 12 Dec 2019 20:38:10 +0000
Subject: [strongSwan] purge user cert
Message-ID: <BN7PR14MB219596E6D8AF4436049E3ECA88550@BN7PR14MB2195.namprd14.prod.outlook.com>

Hello

? is there a way to purge a selected User Cert

If 2 VPN tunnels are up, and each VPN tunnel uses its own User Cert (for its organization).

Is there a way to purge and reload the first VPN tunnel User Cert.

Note:

  *   We are using VICI
  *   We have tried the following:

  *   terminate_conn()
  *   unload_conn()
  *   copy new User Cert into /etc/swanctl/x509/my-cert.crt
  *   load_conn()
  *   init_conn()
  *   swanctl --list-certs, User Cert serial number did not change

Thanks

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20191212/786b2a0c/attachment.html>

From MakarandPradhan at is5com.com  Fri Dec 13 15:45:16 2019
From: MakarandPradhan at is5com.com (Makarand Pradhan)
Date: Fri, 13 Dec 2019 14:45:16 +0000
Subject: [strongSwan] Wrong DH group and hash in IKE phase 1 proposal
In-Reply-To: <YQBPR0101MB0788F03EE086EEDC0D14FCCC84550@YQBPR0101MB0788.CANPRD01.PROD.OUTLOOK.COM>
References: <YQBPR0101MB0788F03EE086EEDC0D14FCCC84550@YQBPR0101MB0788.CANPRD01.PROD.OUTLOOK.COM>
Message-ID: <YQBPR0101MB0788F28EEC0E203346AD982B84540@YQBPR0101MB0788.CANPRD01.PROD.OUTLOOK.COM>

Hi All,

A quick update to my last query.

Make clean and a reboot seems to have fixed the issue. I haven’t modified any strongswan code so it should not have mattered. Anyways. Now I can see the IKE PH1 complete.

*Dec 13 17:14:29.259: ISAKMP:(1008):Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE
*Dec 13 17:14:29.259: ISAKMP:(1008):Old State = IKE_P1_COMPLETE  New State = IKE_P1_COMPLETE

Thanks.

Makarand Pradhan
Senior Software Engineer.
iS5 Communications Inc.
#1-1815 Meyerside Drive
Mississauga, Ontario
L5T 1G3
Main Line: +1-844-520-0588 Ext. 129
Direct Line: +1-289-724-2296
Cell: +1-226-501-5666
Fax:+1-289-401-5206
Email: makarandpradhan at is5com.com
Website: www.iS5Com.com

 
Confidentiality Notice: 
This message is intended only for the named recipients. This message may contain information that is confidential and/or exempt from disclosure under applicable law. Any dissemination or copying of this message by anyone other than a named recipient is strictly prohibited. If you are not a named recipient or an employee or agent responsible for delivering this message to a named recipient, please notify us immediately, and permanently destroy this message and any copies you may have. Warning: Email may not be secure unless properly encrypted.

-----Original Message-----
From: Users <users-bounces at lists.strongswan.org> On Behalf Of Makarand Pradhan
Sent: December 12, 2019 2:31 PM
To: users at lists.strongswan.org
Subject: [strongSwan] Wrong DH group and hash in IKE phase 1 proposal

Hello Everyone,

I'm trying to set up a tunnel between Strongswan and Cisco 2811. I'm following instructions per:

https://www.cisco.com/c/en/us/support/docs/ip/internet-key-exchange-ike/117258-config-l2l.html

Phase 1 parameters are configured in ipsec.conf as:
	keyexchange=ikev1                                            
	ike=aes128-md5-modp1536                                      

When I try starting up the tunnel, the IKE proposal sent out contains:

Per log on Cisco router:
*Dec 12 21:32:39.438: ISAKMP:      encryption AES-CBC
*Dec 12 21:32:39.438: ISAKMP:      keylength of 128
*Dec 12 21:32:39.438: ISAKMP:      hash SHA256
*Dec 12 21:32:39.438: ISAKMP:      unknown DH group 31
*Dec 12 21:32:39.438: ISAKMP:      auth pre-share
*Dec 12 21:32:39.438: ISAKMP:      life type in seconds
*Dec 12 21:32:39.438: ISAKMP:      life duration (basic) of 1520

I've captured the packet in wireshark and the packet indicates the wrong DH group and wrong hash. I've attached the captured pcap file.

My ipsec.conf file is as follows:

config setup                     
        charondebug=ike 4        
                                                                     
#####IS5#####                                                        
conn m1                                                              
        type=tunnel                                                  
        authby=secret                                                
        auto=add                                                     
        keyexchange=ikev1                                            
        ike=aes128-md5-modp1536                                      
        esp=aes128-sha1                                              
        ikelifetime=1520                                             
        right=80.0.0.3                                               
        rightid=80.0.0.3                                             
        rightsubnet=10.10.3.0/24                                     
        left=80.0.0.2                                                
        leftid=80.0.0.2                                              
        leftsubnet=192.168.0.0/16                               

 I've tried changing to 3DES and SHA512 and different DH groups in ipsec.conf. All the same, I always see AES-SHA256-DHGRP31 going out.

Any opinions or suggestions to correct my ipsec.conf would be highly appreciated.

With rgds,
Makarand.

From houmie at gmail.com  Wed Dec 18 10:03:52 2019
From: houmie at gmail.com (Houman)
Date: Wed, 18 Dec 2019 09:03:52 +0000
Subject: [strongSwan] Where are the logs on StrongSwan Ubuntu 19.10?
Message-ID: <CABBZOsmf2y4zBS5jCkj85YTPatuQRKE+9ZhVi1xuqV3x1pCevw@mail.gmail.com>

Hello,

I have tested the latest StrongSwan on Ubuntu 19.10. I don't seem to be
able to connect, but neither can I see any entries in /var/log/syslog.
Could it be that the default log output has moved to somewhere else?

In my deployment script, I have set this:

mkdir /etc/systemd/system/strongswan.service.d
echo "[Service]
StandardOutput=null
" > /etc/systemd/system/strongswan.service.d/override.conf

Many Thanks,
Houman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20191218/9ef7e437/attachment.html>

From Anthony.Modster at Teledyne.com  Wed Dec 18 22:58:00 2019
From: Anthony.Modster at Teledyne.com (Modster, Anthony)
Date: Wed, 18 Dec 2019 21:58:00 +0000
Subject: [strongSwan] OCSP and CDP
Message-ID: <BYAPR14MB2200B9D78CB927BF9588677B88530@BYAPR14MB2200.namprd14.prod.outlook.com>

Hello

? can strongswan be a OCSP or CDP server

We are using strongswan version:5.5.1

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20191218/bb10c2d0/attachment.html>

From tobias at strongswan.org  Thu Dec 19 17:52:42 2019
From: tobias at strongswan.org (Tobias Brunner)
Date: Thu, 19 Dec 2019 17:52:42 +0100
Subject: [strongSwan] OCSP and CDP
In-Reply-To: <BYAPR14MB2200B9D78CB927BF9588677B88530@BYAPR14MB2200.namprd14.prod.outlook.com>
References: <BYAPR14MB2200B9D78CB927BF9588677B88530@BYAPR14MB2200.namprd14.prod.outlook.com>
Message-ID: <afb77d5a-11ae-2fbe-70e1-63f7e79b2bd3@strongswan.org>

Hi Anthony,

> ? can strongswan be a OCSP or CDP server

Theoretically yes, but you'd have to program a plugin that does that
yourself.

It would theoretically also be possible to transmit CRLs (RFC 7296) and
OCSP (RFC 4806) via IKEv2 certificate payloads, but strongSwan currently
doesn't support this.

Regards,
Tobias

From Anthony.Modster at Teledyne.com  Thu Dec 19 17:56:25 2019
From: Anthony.Modster at Teledyne.com (Modster, Anthony)
Date: Thu, 19 Dec 2019 16:56:25 +0000
Subject: [strongSwan] OCSP and CDP
In-Reply-To: <afb77d5a-11ae-2fbe-70e1-63f7e79b2bd3@strongswan.org>
References: <BYAPR14MB2200B9D78CB927BF9588677B88530@BYAPR14MB2200.namprd14.prod.outlook.com>
 <afb77d5a-11ae-2fbe-70e1-63f7e79b2bd3@strongswan.org>
Message-ID: <BN7PR14MB21953055C6A548FA9A6E9DB688520@BN7PR14MB2195.namprd14.prod.outlook.com>

OK, now I am curious

? is there a developers guide for writing plugins

? what would the plugin do

? does (RFC 6960) apply

Thanks

-----Original Message-----
From: Tobias Brunner <tobias at strongswan.org> 
Sent: Thursday, December 19, 2019 8:53 AM
To: Modster, Anthony <Anthony.Modster at Teledyne.com>; users at lists.strongswan.org
Subject: Re: [strongSwan] OCSP and CDP

---External Email---

Hi Anthony,

> ? can strongswan be a OCSP or CDP server

Theoretically yes, but you'd have to program a plugin that does that yourself.

It would theoretically also be possible to transmit CRLs (RFC 7296) and OCSP (RFC 4806) via IKEv2 certificate payloads, but strongSwan currently doesn't support this.

Regards,
Tobias

From tobias at strongswan.org  Thu Dec 19 18:24:53 2019
From: tobias at strongswan.org (Tobias Brunner)
Date: Thu, 19 Dec 2019 18:24:53 +0100
Subject: [strongSwan] OCSP and CDP
In-Reply-To: <BN7PR14MB21953055C6A548FA9A6E9DB688520@BN7PR14MB2195.namprd14.prod.outlook.com>
References: <BYAPR14MB2200B9D78CB927BF9588677B88530@BYAPR14MB2200.namprd14.prod.outlook.com>
 <afb77d5a-11ae-2fbe-70e1-63f7e79b2bd3@strongswan.org>
 <BN7PR14MB21953055C6A548FA9A6E9DB688520@BN7PR14MB2195.namprd14.prod.outlook.com>
Message-ID: <03794751-800a-51b0-955e-1cc8a142c6b3@strongswan.org>

Hi Anthony,

> ? is there a developers guide for writing plugins

[1] has some general information and there are a lot of plugins you
could have a look at.

> ? what would the plugin do

Process OCSP requests and return responses (probably via HTTP) and/or do
the same for CRLs.

> ? does (RFC 6960) apply

If you implement an OCSP server, sure.

Also, the x509 plugin does not actually support parsing OCSP requests or
generating OCSP responses because strongSwan currently only needs the
reverse.

Regards,
Tobias

[1]
https://wiki.strongswan.org/projects/strongswan/wiki/DeveloperDocumentation

From Anthony.Modster at Teledyne.com  Thu Dec 19 18:30:07 2019
From: Anthony.Modster at Teledyne.com (Modster, Anthony)
Date: Thu, 19 Dec 2019 17:30:07 +0000
Subject: [strongSwan] OCSP and CDP
In-Reply-To: <03794751-800a-51b0-955e-1cc8a142c6b3@strongswan.org>
References: <BYAPR14MB2200B9D78CB927BF9588677B88530@BYAPR14MB2200.namprd14.prod.outlook.com>
 <afb77d5a-11ae-2fbe-70e1-63f7e79b2bd3@strongswan.org>
 <BN7PR14MB21953055C6A548FA9A6E9DB688520@BN7PR14MB2195.namprd14.prod.outlook.com>
 <03794751-800a-51b0-955e-1cc8a142c6b3@strongswan.org>
Message-ID: <BN7PR14MB21954D1FE4EB62DEC7771F3188520@BN7PR14MB2195.namprd14.prod.outlook.com>

Thanks

I will take a look, I may write a custom plugin or try python w/openssl

-----Original Message-----
From: Tobias Brunner <tobias at strongswan.org> 
Sent: Thursday, December 19, 2019 9:25 AM
To: Modster, Anthony <Anthony.Modster at Teledyne.com>; users at lists.strongswan.org
Subject: Re: [strongSwan] OCSP and CDP

---External Email---

Hi Anthony,

> ? is there a developers guide for writing plugins

[1] has some general information and there are a lot of plugins you could have a look at.

> ? what would the plugin do

Process OCSP requests and return responses (probably via HTTP) and/or do the same for CRLs.

> ? does (RFC 6960) apply

If you implement an OCSP server, sure.

Also, the x509 plugin does not actually support parsing OCSP requests or generating OCSP responses because strongSwan currently only needs the reverse.

Regards,
Tobias

[1]
https://wiki.strongswan.org/projects/strongswan/wiki/DeveloperDocumentation

From Anthony.Modster at Teledyne.com  Thu Dec 19 18:31:39 2019
From: Anthony.Modster at Teledyne.com (Modster, Anthony)
Date: Thu, 19 Dec 2019 17:31:39 +0000
Subject: [strongSwan] OCSP nonce parameter
In-Reply-To: <a01e2205-de02-2db2-b7d0-079ec21faab1@strongswan.org>
References: <BN7PR14MB2195CE0142F1D267689AEEF388780@BN7PR14MB2195.namprd14.prod.outlook.com>
 <46949c4b-1021-ab62-a0aa-80e9eeb07bac@strongswan.org>
 <BN7PR14MB21959F0515A3FDDE2049230D887B0@BN7PR14MB2195.namprd14.prod.outlook.com>
 <BN7PR14MB21954C82E83A6993ED4CD462884E0@BN7PR14MB2195.namprd14.prod.outlook.com>
 <a01e2205-de02-2db2-b7d0-079ec21faab1@strongswan.org>
Message-ID: <BN7PR14MB21951EA9851E8E5828ED3B0C88520@BN7PR14MB2195.namprd14.prod.outlook.com>

Hello

? was the nonce parameter fixed in 5.5.8

-----Original Message-----
From: Users <users-bounces at lists.strongswan.org> On Behalf Of Tobias Brunner
Sent: Monday, November 25, 2019 4:36 AM
To: Modster, Anthony <Anthony.Modster at Teledyne.com>; users at lists.strongswan.org; Andreas Steffen <andreas.steffen at strongswan.org>
Cc: Amare, Mesfin <Mesfin.Amare at Teledyne.com>
Subject: Re: [strongSwan] OCSP nonce parameter

---External Email---

Hi Anthony,

> Our security department is insisting that strongswan validate the nonce parameter when received.
> 
> Is there a way strongswan can accommodate this request.

I pushed some changes to that effect to the ocsp-nonce branch [1].

> If not we need a way to disable OCSP.

You can do so via charon.plugins.revocation.enable_ocsp.

Regards,
Tobias

[1]
https://git.strongswan.org/?p=strongswan.git;a=shortlog;h=refs/heads/ocsp-nonce

From tobias at strongswan.org  Thu Dec 19 19:42:20 2019
From: tobias at strongswan.org (Tobias Brunner)
Date: Thu, 19 Dec 2019 19:42:20 +0100
Subject: [strongSwan] OCSP nonce parameter
In-Reply-To: <BN7PR14MB21951EA9851E8E5828ED3B0C88520@BN7PR14MB2195.namprd14.prod.outlook.com>
References: <BN7PR14MB2195CE0142F1D267689AEEF388780@BN7PR14MB2195.namprd14.prod.outlook.com>
 <46949c4b-1021-ab62-a0aa-80e9eeb07bac@strongswan.org>
 <BN7PR14MB21959F0515A3FDDE2049230D887B0@BN7PR14MB2195.namprd14.prod.outlook.com>
 <BN7PR14MB21954C82E83A6993ED4CD462884E0@BN7PR14MB2195.namprd14.prod.outlook.com>
 <a01e2205-de02-2db2-b7d0-079ec21faab1@strongswan.org>
 <BN7PR14MB21951EA9851E8E5828ED3B0C88520@BN7PR14MB2195.namprd14.prod.outlook.com>
Message-ID: <2fd0a55e-93a9-d17b-fddd-57a86551ca9d@strongswan.org>

Hi Anthony,

> ? was the nonce parameter fixed in 5.5.8

If you mean 5.8.2 [1], then yes.

Regards,
Tobias

[1] https://wiki.strongswan.org/versions/75

From Anthony.Modster at Teledyne.com  Thu Dec 19 19:48:43 2019
From: Anthony.Modster at Teledyne.com (Modster, Anthony)
Date: Thu, 19 Dec 2019 18:48:43 +0000
Subject: [strongSwan] OCSP nonce parameter
In-Reply-To: <2fd0a55e-93a9-d17b-fddd-57a86551ca9d@strongswan.org>
References: <BN7PR14MB2195CE0142F1D267689AEEF388780@BN7PR14MB2195.namprd14.prod.outlook.com>
 <46949c4b-1021-ab62-a0aa-80e9eeb07bac@strongswan.org>
 <BN7PR14MB21959F0515A3FDDE2049230D887B0@BN7PR14MB2195.namprd14.prod.outlook.com>
 <BN7PR14MB21954C82E83A6993ED4CD462884E0@BN7PR14MB2195.namprd14.prod.outlook.com>
 <a01e2205-de02-2db2-b7d0-079ec21faab1@strongswan.org>
 <BN7PR14MB21951EA9851E8E5828ED3B0C88520@BN7PR14MB2195.namprd14.prod.outlook.com>
 <2fd0a55e-93a9-d17b-fddd-57a86551ca9d@strongswan.org>
Message-ID: <BN7PR14MB219514893FE96116040CE73A88520@BN7PR14MB2195.namprd14.prod.outlook.com>

? is 5.8.2 stable enough for production

-----Original Message-----
From: Tobias Brunner <tobias at strongswan.org> 
Sent: Thursday, December 19, 2019 10:42 AM
To: Modster, Anthony <Anthony.Modster at Teledyne.com>; users at lists.strongswan.org; Andreas Steffen <andreas.steffen at strongswan.org>
Cc: Amare, Mesfin <Mesfin.Amare at Teledyne.com>
Subject: Re: [strongSwan] OCSP nonce parameter

---External Email---

Hi Anthony,

> ? was the nonce parameter fixed in 5.5.8

If you mean 5.8.2 [1], then yes.

Regards,
Tobias

[1] https://wiki.strongswan.org/versions/75

From harald.dunkel at aixigo.com  Fri Dec 20 10:43:48 2019
From: harald.dunkel at aixigo.com (Harald Dunkel)
Date: Fri, 20 Dec 2019 10:43:48 +0100
Subject: [strongSwan] network manager app: dead peer detection?
Message-ID: <00778b40-696f-a199-dcad-aa2358b951a9@aixigo.com>

Hi folks,

I've seen it several times that the dead peer detection on my
IPsec gateway recognized a lost connection to a road warrior
laptop, but the laptop itself didn't know.

Would it be possible to enable dead peer detection and dpdaction
restart in the network manager app?


Regards
Harri

From pupilla at hotmail.com  Fri Dec 20 17:42:50 2019
From: pupilla at hotmail.com (Marco Berizzi)
Date: Fri, 20 Dec 2019 16:42:50 +0000
Subject: [strongSwan] Route-based VPNs (XFRM Interfaces) vs policies based
	VPNs
Message-ID: <AM0PR10MB3234132058F4186F7F9F2B74B22D0@AM0PR10MB3234.EURPRD10.PROD.OUTLOOK.COM>

Hello everyone,

I need to setup a 0.0.0.0/0 to 0.0.0.0/0 ipsec tunnel.
I was thinking to setup it with the new xfrm interfaces:
I don't need route all the 0.0.0.0/0 throught this vpn.

My question is how 'route based' and 'policies based'
VPNs will coexist on the same linux box.

For example, if I'm going to implement a 0.0.0.0/0 to
0.0.0.0/0 vpn with the xfrm interfaces and then I will
route the traffic only for the 155.192.168.0/24 network
throught the ipsec0 device (for example), and then I
implement a classic policy based vpn (without the xfrm
interface) with the following traffic selectors
166.172.16.0/24 and 177.16.172.0/24, what will happen?
Will the linux kernel process the packets for the
166.172.16.0/24 and 177.16.172.0/24 into the right ipsec
policy?

Thanks

Marco

From ms at sys4.de  Fri Dec 20 17:56:51 2019
From: ms at sys4.de (Michael Schwartzkopff)
Date: Fri, 20 Dec 2019 17:56:51 +0100
Subject: [strongSwan] Route-based VPNs (XFRM Interfaces) vs policies
 based VPNs
In-Reply-To: <AM0PR10MB3234132058F4186F7F9F2B74B22D0@AM0PR10MB3234.EURPRD10.PROD.OUTLOOK.COM>
References: <AM0PR10MB3234132058F4186F7F9F2B74B22D0@AM0PR10MB3234.EURPRD10.PROD.OUTLOOK.COM>
Message-ID: <8f29bbcd-8755-dea7-e481-a311d276924d@sys4.de>

On 20.12.19 17:42, Marco Berizzi wrote:
> Hello everyone,
>
> I need to setup a 0.0.0.0/0 to 0.0.0.0/0 ipsec tunnel.
> I was thinking to setup it with the new xfrm interfaces:
> I don't need route all the 0.0.0.0/0 throught this vpn.
>
> My question is how 'route based' and 'policies based'
> VPNs will coexist on the same linux box.
>
> For example, if I'm going to implement a 0.0.0.0/0 to
> 0.0.0.0/0 vpn with the xfrm interfaces and then I will
> route the traffic only for the 155.192.168.0/24 network
> throught the ipsec0 device (for example), and then I
> implement a classic policy based vpn (without the xfrm
> interface) with the following traffic selectors
> 166.172.16.0/24 and 177.16.172.0/24, what will happen?
> Will the linux kernel process the packets for the
> 166.172.16.0/24 and 177.16.172.0/24 into the right ipsec
> policy?
>
> Thanks
>
> Marco

I think mixing policy and route based VPNs on the same machine with
overlapping network ranges will cause trouble. I'd change to only
route-based VPNs in that case.


Mit freundlichen Grüßen,

-- 

[*] sys4 AG
 
https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG,80333 München
 
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief
Aufsichtsratsvorsitzender: Florian Kirstein


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20191220/e6c3e2b8/attachment.sig>

From felipeapolanco at gmail.com  Fri Dec 20 18:09:41 2019
From: felipeapolanco at gmail.com (Felipe Arturo Polanco)
Date: Fri, 20 Dec 2019 13:09:41 -0400
Subject: [strongSwan] Route-based VPNs (XFRM Interfaces) vs policies
	based VPNs
In-Reply-To: <8f29bbcd-8755-dea7-e481-a311d276924d@sys4.de>
References: <AM0PR10MB3234132058F4186F7F9F2B74B22D0@AM0PR10MB3234.EURPRD10.PROD.OUTLOOK.COM>
 <8f29bbcd-8755-dea7-e481-a311d276924d@sys4.de>
Message-ID: <CADcj3=6kzWPmemxVuo3_Lp4q=AOJih7kssvhKsJHfF3xTvdGxw@mail.gmail.com>

Hi,

I have done this before, it works fine.

Just make sure you add a corresponding mark to both the definition of the
ipsec0 interface and the Strongswan config for 0.0.0.0/0

XFRM looks for the most specific traffic selector when finding a match, it
will check against route-based selector first and then will check 0.0.0.0/0
at last.

On Fri, Dec 20, 2019 at 12:57 PM Michael Schwartzkopff <ms at sys4.de> wrote:

> On 20.12.19 17:42, Marco Berizzi wrote:
> > Hello everyone,
> >
> > I need to setup a 0.0.0.0/0 to 0.0.0.0/0 ipsec tunnel.
> > I was thinking to setup it with the new xfrm interfaces:
> > I don't need route all the 0.0.0.0/0 throught this vpn.
> >
> > My question is how 'route based' and 'policies based'
> > VPNs will coexist on the same linux box.
> >
> > For example, if I'm going to implement a 0.0.0.0/0 to
> > 0.0.0.0/0 vpn with the xfrm interfaces and then I will
> > route the traffic only for the 155.192.168.0/24 network
> > throught the ipsec0 device (for example), and then I
> > implement a classic policy based vpn (without the xfrm
> > interface) with the following traffic selectors
> > 166.172.16.0/24 and 177.16.172.0/24, what will happen?
> > Will the linux kernel process the packets for the
> > 166.172.16.0/24 and 177.16.172.0/24 into the right ipsec
> > policy?
> >
> > Thanks
> >
> > Marco
>
> I think mixing policy and route based VPNs on the same machine with
> overlapping network ranges will cause trouble. I'd change to only
> route-based VPNs in that case.
>
>
> Mit freundlichen Grüßen,
>
> --
>
> [*] sys4 AG
>
> https://sys4.de, +49 (89) 30 90 46 64
> Schleißheimer Straße 26/MG,80333 München
>
> Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
> Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief
> Aufsichtsratsvorsitzender: Florian Kirstein
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20191220/0ced35a8/attachment.html>

From noel.kuntze+strongswan-users-ml at thermi.consulting  Fri Dec 20 18:00:46 2019
From: noel.kuntze+strongswan-users-ml at thermi.consulting (noel.kuntze+strongswan-users-ml at thermi.consulting)
Date: Fri, 20 Dec 2019 17:00:46 +0000
Subject: [strongSwan] Route-based VPNs (XFRM Interfaces) vs policies
	based VPNs
In-Reply-To: <8f29bbcd-8755-dea7-e481-a311d276924d@sys4.de>
References: <AM0PR10MB3234132058F4186F7F9F2B74B22D0@AM0PR10MB3234.EURPRD10.PROD.OUTLOOK.COM>
 <8f29bbcd-8755-dea7-e481-a311d276924d@sys4.de>
Message-ID: <84B60E40-6450-49F9-A85D-8AEB9F724D90@thermi.consulting>

*immediate from-mobile contradiction*

Policies will be applied before any route based VPN are in play. So in your examples the policy will be applied. Take care that strongSwan is configured to insert the routes. Otherwise source IP selection can be a problem.

Kind regards

Noel

Sent from mobile

Am December 20, 2019 4:56:51 PM UTC schrieb Michael Schwartzkopff <ms at sys4.de>:
>On 20.12.19 17:42, Marco Berizzi wrote:
>> Hello everyone,
>>
>> I need to setup a 0.0.0.0/0 to 0.0.0.0/0 ipsec tunnel.
>> I was thinking to setup it with the new xfrm interfaces:
>> I don't need route all the 0.0.0.0/0 throught this vpn.
>>
>> My question is how 'route based' and 'policies based'
>> VPNs will coexist on the same linux box.
>>
>> For example, if I'm going to implement a 0.0.0.0/0 to
>> 0.0.0.0/0 vpn with the xfrm interfaces and then I will
>> route the traffic only for the 155.192.168.0/24 network
>> throught the ipsec0 device (for example), and then I
>> implement a classic policy based vpn (without the xfrm
>> interface) with the following traffic selectors
>> 166.172.16.0/24 and 177.16.172.0/24, what will happen?
>> Will the linux kernel process the packets for the
>> 166.172.16.0/24 and 177.16.172.0/24 into the right ipsec
>> policy?
>>
>> Thanks
>>
>> Marco
>
>I think mixing policy and route based VPNs on the same machine with
>overlapping network ranges will cause trouble. I'd change to only
>route-based VPNs in that case.
>
>
>Mit freundlichen Grüßen,
>
>-- 
>
>[*] sys4 AG
> 
>https://sys4.de, +49 (89) 30 90 46 64
>Schleißheimer Straße 26/MG,80333 München
> 
>Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
>Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief
>Aufsichtsratsvorsitzender: Florian Kirstein
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20191220/f6bc49f8/attachment.html>

From noel.kuntze+strongswan-users-ml at thermi.consulting  Fri Dec 20 18:18:08 2019
From: noel.kuntze+strongswan-users-ml at thermi.consulting (noel.kuntze+strongswan-users-ml at thermi.consulting)
Date: Fri, 20 Dec 2019 17:18:08 +0000
Subject: [strongSwan] Route-based VPNs (XFRM Interfaces) vs
	policies	based VPNs
In-Reply-To: <CADcj3=6kzWPmemxVuo3_Lp4q=AOJih7kssvhKsJHfF3xTvdGxw@mail.gmail.com>
References: <AM0PR10MB3234132058F4186F7F9F2B74B22D0@AM0PR10MB3234.EURPRD10.PROD.OUTLOOK.COM>
 <8f29bbcd-8755-dea7-e481-a311d276924d@sys4.de>
 <CADcj3=6kzWPmemxVuo3_Lp4q=AOJih7kssvhKsJHfF3xTvdGxw@mail.gmail.com>
Message-ID: <7B5D68B3-D847-46B3-AFDA-B5A43113656F@thermi.consulting>

Mark is only needed with VTIs. XFRM interfaces work with if_ids.

Am December 20, 2019 5:09:41 PM UTC schrieb Felipe Arturo Polanco <felipeapolanco at gmail.com>:
>Hi,
>
>I have done this before, it works fine.
>
>Just make sure you add a corresponding mark to both the definition of
>the
>ipsec0 interface and the Strongswan config for 0.0.0.0/0
>
>XFRM looks for the most specific traffic selector when finding a match,
>it
>will check against route-based selector first and then will check
>0.0.0.0/0
>at last.
>
>On Fri, Dec 20, 2019 at 12:57 PM Michael Schwartzkopff <ms at sys4.de>
>wrote:
>
>> On 20.12.19 17:42, Marco Berizzi wrote:
>> > Hello everyone,
>> >
>> > I need to setup a 0.0.0.0/0 to 0.0.0.0/0 ipsec tunnel.
>> > I was thinking to setup it with the new xfrm interfaces:
>> > I don't need route all the 0.0.0.0/0 throught this vpn.
>> >
>> > My question is how 'route based' and 'policies based'
>> > VPNs will coexist on the same linux box.
>> >
>> > For example, if I'm going to implement a 0.0.0.0/0 to
>> > 0.0.0.0/0 vpn with the xfrm interfaces and then I will
>> > route the traffic only for the 155.192.168.0/24 network
>> > throught the ipsec0 device (for example), and then I
>> > implement a classic policy based vpn (without the xfrm
>> > interface) with the following traffic selectors
>> > 166.172.16.0/24 and 177.16.172.0/24, what will happen?
>> > Will the linux kernel process the packets for the
>> > 166.172.16.0/24 and 177.16.172.0/24 into the right ipsec
>> > policy?
>> >
>> > Thanks
>> >
>> > Marco
>>
>> I think mixing policy and route based VPNs on the same machine with
>> overlapping network ranges will cause trouble. I'd change to only
>> route-based VPNs in that case.
>>
>>
>> Mit freundlichen Grüßen,
>>
>> --
>>
>> [*] sys4 AG
>>
>> https://sys4.de, +49 (89) 30 90 46 64
>> Schleißheimer Straße 26/MG,80333 München
>>
>> Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
>> Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief
>> Aufsichtsratsvorsitzender: Florian Kirstein
>>
>>
>>

Sent from mobile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20191220/ea223339/attachment-0001.html>

From noel.kuntze+strongswan-users-ml at thermi.consulting  Fri Dec 20 18:18:08 2019
From: noel.kuntze+strongswan-users-ml at thermi.consulting (noel.kuntze+strongswan-users-ml at thermi.consulting)
Date: Fri, 20 Dec 2019 17:18:08 +0000
Subject: [strongSwan] Route-based VPNs (XFRM Interfaces) vs
	policies	based VPNs
In-Reply-To: <CADcj3=6kzWPmemxVuo3_Lp4q=AOJih7kssvhKsJHfF3xTvdGxw@mail.gmail.com>
References: <AM0PR10MB3234132058F4186F7F9F2B74B22D0@AM0PR10MB3234.EURPRD10.PROD.OUTLOOK.COM>
 <8f29bbcd-8755-dea7-e481-a311d276924d@sys4.de>
 <CADcj3=6kzWPmemxVuo3_Lp4q=AOJih7kssvhKsJHfF3xTvdGxw@mail.gmail.com>
Message-ID: <349D79FF-E393-4BDF-87F5-5BDA5FD74FEC@thermi.consulting>

Mark is only needed with VTIs. XFRM interfaces work with if_ids.

Am December 20, 2019 5:09:41 PM UTC schrieb Felipe Arturo Polanco <felipeapolanco at gmail.com>:
>Hi,
>
>I have done this before, it works fine.
>
>Just make sure you add a corresponding mark to both the definition of
>the
>ipsec0 interface and the Strongswan config for 0.0.0.0/0
>
>XFRM looks for the most specific traffic selector when finding a match,
>it
>will check against route-based selector first and then will check
>0.0.0.0/0
>at last.
>
>On Fri, Dec 20, 2019 at 12:57 PM Michael Schwartzkopff <ms at sys4.de>
>wrote:
>
>> On 20.12.19 17:42, Marco Berizzi wrote:
>> > Hello everyone,
>> >
>> > I need to setup a 0.0.0.0/0 to 0.0.0.0/0 ipsec tunnel.
>> > I was thinking to setup it with the new xfrm interfaces:
>> > I don't need route all the 0.0.0.0/0 throught this vpn.
>> >
>> > My question is how 'route based' and 'policies based'
>> > VPNs will coexist on the same linux box.
>> >
>> > For example, if I'm going to implement a 0.0.0.0/0 to
>> > 0.0.0.0/0 vpn with the xfrm interfaces and then I will
>> > route the traffic only for the 155.192.168.0/24 network
>> > throught the ipsec0 device (for example), and then I
>> > implement a classic policy based vpn (without the xfrm
>> > interface) with the following traffic selectors
>> > 166.172.16.0/24 and 177.16.172.0/24, what will happen?
>> > Will the linux kernel process the packets for the
>> > 166.172.16.0/24 and 177.16.172.0/24 into the right ipsec
>> > policy?
>> >
>> > Thanks
>> >
>> > Marco
>>
>> I think mixing policy and route based VPNs on the same machine with
>> overlapping network ranges will cause trouble. I'd change to only
>> route-based VPNs in that case.
>>
>>
>> Mit freundlichen Grüßen,
>>
>> --
>>
>> [*] sys4 AG
>>
>> https://sys4.de, +49 (89) 30 90 46 64
>> Schleißheimer Straße 26/MG,80333 München
>>
>> Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
>> Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief
>> Aufsichtsratsvorsitzender: Florian Kirstein
>>
>>
>>

Sent from mobile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20191220/f7f2e408/attachment.html>

From dusan at comhem.se  Sat Dec 21 05:36:45 2019
From: dusan at comhem.se (=?UTF-8?B?RHXFoWFuIElsacSH?=)
Date: Sat, 21 Dec 2019 05:36:45 +0100
Subject: [strongSwan] Roadwarrior VPN same subnet
In-Reply-To: <ojcqq28kp58n1auf610v5i8i.1576902460781@email.android.com>
References: <ojcqq28kp58n1auf610v5i8i.1576902460781@email.android.com>
Message-ID: <ggsg9eeici5ni8rokp9qdr13.1576902963285@email.android.com>



---- Dušan Ilić wrote ----

>Hi,
>
>I have configured a roadwarrior ikev2 strongswan setup with DHCP.
>Everything works when I assign the dhcp scope a separate subnet, but when I assign IPs from the same subnet   it doesn't work. The strange thing is that the client can still connect and the gateway and other local clients can reach the VPN client with ping, but not the other way around. So the client responds to pings, but cannot itself ping or reach anything.
>
>I have checked iptables rules, routing tables and nat. Everything looks just fine. Also farp plugin is enabled. 
>
>Do anyone recognize this behavior, if not, how should I go about troubleshooting this?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20191221/e967df75/attachment.html>

From felipeapolanco at gmail.com  Sun Dec 22 17:12:36 2019
From: felipeapolanco at gmail.com (Felipe Arturo Polanco)
Date: Sun, 22 Dec 2019 12:12:36 -0400
Subject: [strongSwan] Roadwarrior VPN same subnet
In-Reply-To: <ggsg9eeici5ni8rokp9qdr13.1576902963285@email.android.com>
References: <ojcqq28kp58n1auf610v5i8i.1576902460781@email.android.com>
 <ggsg9eeici5ni8rokp9qdr13.1576902963285@email.android.com>
Message-ID: <CADcj3=7q6-XsTgQ_CpLavoJPt966GwbRizF-3G9Z=QA2QJscgg@mail.gmail.com>

Hi,

Please share with us your Strongswan configuration, $ iptables-save
output and $ ip xfrm policy output

Also, a brief description of which network/host needs to ping which
network/host. eg: 172.16.20.14 needs to ping 10.0.10.50 over the VPN
server at 172.16.20.1


On Sat, Dec 21, 2019 at 12:37 AM Dušan Ilić <dusan at comhem.se> wrote:
>
>
>
> ---- Dušan Ilić wrote ----
>
> Hi,
>
>
> I have configured a roadwarrior ikev2 strongswan setup with DHCP.
>
> Everything works when I assign the dhcp scope a separate subnet, but when I assign IPs from the same subnet   it doesn't work. The strange thing is that the client can still connect and the gateway and other local clients can reach the VPN client with ping, but not the other way around. So the client responds to pings, but cannot itself ping or reach anything.
>
>
> I have checked iptables rules, routing tables and nat. Everything looks just fine. Also farp plugin is enabled.
>
>
> Do anyone recognize this behavior, if not, how should I go about troubleshooting this?

From Anthony.Modster at Teledyne.com  Tue Dec 24 00:11:17 2019
From: Anthony.Modster at Teledyne.com (Modster, Anthony)
Date: Mon, 23 Dec 2019 23:11:17 +0000
Subject: [strongSwan] forecast
Message-ID: <BN7PR14MB219527ACCE389C8C3FE88507882E0@BN7PR14MB2195.namprd14.prod.outlook.com>

Hello

? does strongswan generate any traffic using multicast or broadcast ports

https://wiki.strongswan.org/projects/strongswan/repository/revisions/094a4d15cff37b786b9afec2c1cfe834dcd13147

Thanks

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20191223/31ac2e33/attachment.html>

From Anthony.Modster at Teledyne.com  Tue Dec 24 00:27:06 2019
From: Anthony.Modster at Teledyne.com (Modster, Anthony)
Date: Mon, 23 Dec 2019 23:27:06 +0000
Subject: [strongSwan] SPI
Message-ID: <BN7PR14MB2195073478CAF156DA614748882E0@BN7PR14MB2195.namprd14.prod.outlook.com>

Hello

The range from which SPIs for IPsec SAs are allocated by the kernel is now configurable.
(AM), ? is this only for IPSec servers that are using IKEv1

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20191223/bd768a87/attachment.html>

From liguoying16 at 126.com  Wed Dec 25 03:06:19 2019
From: liguoying16 at 126.com (=?GBK?B?wO65+tOq?=)
Date: Wed, 25 Dec 2019 10:06:19 +0800 (CST)
Subject: [strongSwan] "no private key found for" ERROR
Message-ID: <68cc3246.3384.16f3ace0a29.Coremail.liguoying16@126.com>

“no private key found for 'C=CN, ST=Some-State, O=SD, CN=server'”


I found this error.


My cert is like this:
.
./cacerts
./cacerts/cacert.pem
./ocspcerts
./certs
./certs/servercert.pem
./acerts
./aacerts
./crls
./reqs
./private
./private/serverkey.pem


My ipsec.conf is like this:
conn host-host
left=172.16.10.126
leftsubnet=10.1.0.0/16
leftid="C = CN, ST = Some-State, O = SD, CN = server"
leftcert=servercert.pem
leftfirewall=yes
right=172.16.10.127
rightsubnet=10.2.0.0/16
rightid="C = CN, ST = Some-State, O = SD, CN = client"


My ipsec.secrets is like this:
: SM2 serverkey.pem


help ~~~





--
------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20191225/0631bf38/attachment.html>

From Anthony.Modster at Teledyne.com  Thu Dec 26 23:27:19 2019
From: Anthony.Modster at Teledyne.com (Modster, Anthony)
Date: Thu, 26 Dec 2019 22:27:19 +0000
Subject: [strongSwan] MOBIKE
Message-ID: <BN7PR14MB2195A13B87E9610C5F0C9FF3882B0@BN7PR14MB2195.namprd14.prod.outlook.com>

Hello

? where can I find information on MOBIKE routing path selection (descripted in this reference)

https://wiki.strongswan.org/projects/strongswan/repository/revisions/597e8c9e009946c994fcba525bacc647f46bae60

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20191226/547c8339/attachment.html>

From lenovomi at gmail.com  Sun Dec 29 01:34:07 2019
From: lenovomi at gmail.com (lenovomi)
Date: Sun, 29 Dec 2019 01:34:07 +0100
Subject: [strongSwan] Ubuntu strongswan server and tplink vr400 client
Message-ID: <CAAcrkYJiw_g5j57SicWWUCBvnuDT8qE8XeKvzB76rz_=FfqSuQ@mail.gmail.com>

Hello,

I installed ipsec/strongswan server on my ubuntu vm box 10.0.1.156 (which
is behind 2 routers, so 2x nat, last router has public ip) and want to
connect to it from my router (acting as a client, tplink). Client router
has public ip (wan) and lan 192.168.1.0/24.

I am not sure how to setup ipsec.conf left,leftid,leftsubnet and
right,rightid, and right subnet. Left is vm box, right is tplink router.

Is it correct if i set left=%any4, leftid=10.0.1.156, leftsubnet=
10.0.1.156/32, leftfirewall=yes
and right(router) right=%any4, rightid=%any, rightsubnet=192.168.1.0/24

At tplink router i set Tunnel access from local IP addresses: subnet
192.168.1.0/24 and Tunnel access from remote IP addresses: single address
10.0.1.156/32


Basically what I want is that all clients behind tplink router nat ie
192.168.1.x will be able to ping / access vm box 10.0.1.156.

Thank you!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20191229/d28ead08/attachment.html>

From lenovomi at gmail.com  Tue Dec 31 00:57:06 2019
From: lenovomi at gmail.com (lenovomi)
Date: Tue, 31 Dec 2019 00:57:06 +0100
Subject: [strongSwan] strange issues with strongswan ipsec tunnel
Message-ID: <CAAcrkYJrZibggfxosOS7jyj55=gqqf-f6PZYheL7bd79F7AjSw@mail.gmail.com>

Hi,
I am so desperate seeking for some advice/help/hint. I set up an ipsec
tunel between router (right side) with public wan IP, and local nat
network 192.168.0.x. Left side is VM box behind nat with ip
10.0.1.156. It looks like tunnel is active... but the issue which is
happening is that sometimes hosts from 192.168.1.x cant ping
10.0.1.156... sometimes it works ... but have no idea why.

I observed strange behavior, ping from 10.0.1.156 to any host inside
192.168.1.x works all the time. In case ping from 192.168.1x to
10.0.1.156 doesnt work once ping from 10.0.1.156 to any host instide
192.168.1.0/24 is executed then immediately ping from any host inside
192.168.1.0/24 to 10.0.1.156 works immediately.

Do you have any idea whats going on? :(

thanks!



ipsec statusall
Security Associations (1 up, 0 connecting):
         vpn[11]: ESTABLISHED 29 minutes ago,
10.0.1.156[10.0.1.156]...78.99.148.x[78.99.148.x]
         vpn[11]: IKEv1 SPIs: 5c7f4916bdf05b17_i 4a01d1b8845538c7_r*,
pre-shared key reauthentication in 2 hours
         vpn[11]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
         vpn{18}:  REKEYED, TUNNEL, reqid 1, expires in 25 minutes
         vpn{18}:   10.0.1.156/32 === 192.168.1.0/24
         vpn{19}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: ca827fb5_i 0ef6380d_o
         vpn{19}:  AES_CBC_256/HMAC_SHA1_96/MODP_2048, 0 bytes_i, 0
bytes_o, rekeying in 18 minutes
         vpn{19}:   10.0.1.156/32 === 192.168.1.0/24

ipsec.conf
config setup
    charondebug="ike 1, knl 1, cfg 0"
    uniqueids=no

conn vpn
    keyexchange=ike
    auto=add
   # compress=no
    type=tunnel
   # fragmentation=yes
   # forceencaps=yes
    dpdaction=none
    dpddelay=300s
    rekey=yes
    keyingtries=3
    authby=secret
    left=%any4
    leftid=10.0.1.156
    leftsubnet=10.0.1.156/32
    leftfirewall=yes
    right=%any4
    rightid=%any
   # rightsourceip=192.168.1.0/24
    rightsubnet=192.168.1.0/24
   # rightdns=8.8.8.8,208.67.222.222
    ike=aes256-sha1-modp2048
    esp=aes256-sha1-modp2048


root at roonserver:/home/heap# iptables-save
# Generated by iptables-save v1.6.1 on Tue Dec 31 00:50:54 2019
*mangle
:PREROUTING ACCEPT [1768439:2024183480]
:INPUT ACCEPT [1598091:1809064255]
:FORWARD ACCEPT [169545:215034758]
:OUTPUT ACCEPT [1436042:1265656905]
:POSTROUTING ACCEPT [1640750:1483916434]
-A FORWARD -s 192.168.1.0/24 -o eth0 -p tcp -m policy --dir in --pol
ipsec -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1361:1536 -j
TCPMSS --set-mss 1360
-A FORWARD -d 192.168.1.0/24 -o eth0 -p tcp -m policy --dir out --pol
ipsec -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1361:1536 -j
TCPMSS --set-mss 1360
COMMIT
# Completed on Tue Dec 31 00:50:54 2019
# Generated by iptables-save v1.6.1 on Tue Dec 31 00:50:54 2019
*filter
:INPUT ACCEPT [1486611:1794766486]
:FORWARD ACCEPT [169489:215030706]
:OUTPUT ACCEPT [1421101:1263544042]
-A INPUT -p udp -m udp --dport 500 -j ACCEPT
-A INPUT -p udp -m udp --dport 4500 -j ACCEPT
-A INPUT -p esp -j ACCEPT
COMMIT
# Completed on Tue Dec 31 00:50:54 2019
# Generated by iptables-save v1.6.1 on Tue Dec 31 00:50:54 2019
*nat
:PREROUTING ACCEPT [25960:13260051]
:INPUT ACCEPT [24844:13152349]
:OUTPUT ACCEPT [35486:11861269]
:POSTROUTING ACCEPT [35100:11735433]
-A POSTROUTING -s 192.168.1.0/24 -o eth0 -m policy --dir out --pol
ipsec -j ACCEPT
-A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADE
-A POSTROUTING -s 10.8.0.0/16 -o eth0 -j MASQUERADE
COMMIT
# Completed on Tue Dec 31 00:50:54 2019



router> ipsec status
x     192.168.1.0     10.0.1.156   Up


original post> https://lists.strongswan.org/pipermail/users/2019-December/014119.html