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>