Re: [strongSwan] ipsec.conf working vs swanctl.conf not working

Hi Tobias, > > [NET] sending packet: from 205.223.229.254[500] to 31.169.105.210[500] (68 > > bytes) > > [NET] received packet: from 31.169.105.210[500] to 205.223.229.254[500] (40 > > bytes) > > [ENC] parsed INFORMATIONAL_V1 request 2534754901 [ N(PLD_MAL) ] > Could indicate a wrong password. 

Re: [strongSwan] multiple traffic selectors per child_sa

Hi Tobias, Thanks for the nice explanation. > This is not a negotiated feature. You might just see a peer narrowing > the traffic selectors to only one the client proposed. But it could > also do that for other reasons (e.g. a mismatching configuration). > Support for multiple traffic

[strongSwan] starting strongswan without starter

Hello everyone, I have compiled strongswan on slackware linux with: --disable-stroke and the starter is not builded anymore. Slackware is one the the few distro which is not (yet) systemd based. Which is the correct way to start strongswan without 'ipsec start' ?

[strongSwan] multiple id for same ipsec peer

Hello everyone, I'm running strongswan 5.6.3dr1 on Slackware linux. On this strongswan box it is configured an ikev2 tunnel to a customer checkpoint R77.30 gateway. Sometimes, for an unknown reason, the checkpoint will try to initiate the IKE_SA, but instead of using its public ip address as the

[strongSwan] multiple traffic selectors per child_sa

Hello everyone, Kindly I would like to ask, if there is a way to know if a remote IKEv2 peer supports multiple traffic selectors per CHILD_SA. For example strongswan is going to log this kind of message when tfc is not supported by the other IKEv2 peer: received ESP_TFC_PADDING_NOT_SUPPORTED,

Re: [strongSwan] starting strongswan without starter

Hi Andreas, Hi everyone, thanks but there is no 'start-stop-daemon' on Slackware. I will keep building strongswan without the 'disable-stroke' as suggested by Tobias. As a suggestion, it would be beautiful to get starter working also without the presence of the /etc/ipsec.conf :-)

Re: [strongSwan] multiple id for same ipsec peer

Hi Tobias, > There is currently no exact equivalent for > the `also` keyword in swanctl.conf a nice feature to add in a future relase :-)

Re: [strongSwan] ipsec.conf working vs swanctl.conf not working

Hi Tobias, > The other end sends that notify back because it couldn't authenticate > the initiator, so check the log there. Unfortunately I have no access to the other ipsec peer. I have also tried with another customer and I'm getting the same behavior. Here are the two outputs: (non working)

Re: [strongSwan] ipsec.conf working vs swanctl.conf not working

> mobike = no > By the way I don't understand why strongswan is > sending packets to 4500/udp. Ok I found that "mobike = no" change the swap to the 4500/udp However, I don't understand why the psk authentication is failing.

Re: [strongSwan] ipsec.conf working vs swanctl.conf not working

Hi Tobias, > So you're using IKEv1 now?  (Was IKEv2 in your original mail, and you > should definitely prefer that if you can.) yes this is another customer. I should have opened another thread. > Different IKE proposals.  With ipsec.conf the default proposal(s) are > added to whatever you

Re: [strongSwan] ipsec statusall: missing number of packets output

Hi Tobias, > The number of packets is printed if a last use time can be determined > via the respective policy. thanks for the explanation. Indeed that policy was problematic: packets were going out, but not viceversa. After an "ipsec down child_sa" and "ipsec up child_sa" traffic was full

[strongSwan] ipsec statusall: missing number of packets output

Hello everyone, Kindly I would like to ask if there is any know reason why ipsec statusall sometimes doesn't print the number of packets for the child_sa. Here is an example for the bytes_i: ts-net{453}: AES_CBC_256/HMAC_SHA2_256_128/ECP_384, 1467110312 bytes_i, 3075678241 bytes_o (2443951

Re: [strongSwan] UNSUPPORTED_CRITICAL_PAYLOAD

Hi Tobias, > As strongSwan is the initiator of the exchange and the peer is a > Windows 10 host I'd guess that this is a rekeying. So it could also > be because it doesn't like being responder of a rekeying (Windows > has/had the same problem with IKEv2 CHILD_SA rekeyings, see [1]). You are

[strongSwan] UNSUPPORTED_CRITICAL_PAYLOAD

Hello everyone, I'm getting a lot of this kind of UNSUPPORTED_CRITICAL_PAYLOAD from many windows 10 laptops. Anyone has an idea of what could the problem be? generating QUICK_MODE request 3970887770 [ HASH SA No KE ID ID ] sending packet: from 10.81.110.254[500] to 10.81.126.89[500] (396 bytes)

[strongSwan] ipsec.conf working vs swanctl.conf not working

Hello everyone, I'm running strongswan 5.6.3dr1 on Slackware linux. I would like to migrate the configuration files from the old ipsec.conf style to the new swanctl.conf I'm experimenting a crazy behavior between an old working configuration and the new non working one. Here is the old working

[strongSwan] checkpoint interoperability problem

Hello everyone, I have a very nasty problem with an ipsec tunnel between strongswan 5.6.1 and a customer ipsec gateway (checkpoint). This is my ipsec.conf tunnel configuration: config setup # strictcrlpolicy=yes # uniqueids = no conn %default keyingtries=%forever

Re: [strongSwan] roadwarrior ike/esp SA are not dropped after lifetime expiration

Giuseppe De Marco

[strongSwan] roadwarrior ike/esp SA are not dropped after lifetime expiration

Hello everyone, I'm running strongswan 5.6.1 on slackware linux 64 bit I have found a little problem with my setup. Sometimes mobile users main mode and quick mode are not dropped after ike/esp lifetime. Here is my config setup: conn rw-mobile right=%any compress=yes

Re: [strongSwan] roadwarrior ike/esp SA are not dropped after lifetime expiration

> Yes indeed dpd should do the trick. unfortunately windows 7 and windows 10 doesn't support dpd. Charon is logging these messages: DPD not supported by peer, disabled So dpd was not an option. inactivity= is going to kill only the child sa. As pointed by Noel setting

Re: [strongSwan] checkpoint interoperability problem

Hello everyone. Just for record: in agreement with the customer switching to IKEv2 and enabling forceencaps=yes have resolved the interoperability problem. The forceencaps=yes has been setup because the checkpoint was replying with udp datagrams instead of ESP packets for an unknown reason.

[strongSwan] child_sa not dropped the ike_sa are deleted

Hello everyone, I'm running strongswan 5.6.1 on slackware linux 64 bit I have found a problem with my setup. The down_client:) in the updown script is not executed when the IKE_SA is dropped. Here is my config setup: conn rw-generali right=%any compress=yes

[strongSwan] multiple remote_ts with ikev1 file format

Hello everyone, I would like to finally drop the ipsec.conf and ipsec.secrets configuration files from my strongswan ipsec gateway. I have a couple of questions to ask. I'm running strongswan 5.6.2 on Slackware linux (still systemd free). On my test bed, ipsec.conf and ipsec.secrets are those

Re: [strongSwan] multiple remote_ts with ikev1 file format

Rich Lafferty wrote: > > Is there a way to not write in every section the parameters > > common to all the children sections (rekey_time, esp_proposals…)? > I wasn’t able to find a way to set defaults, but I’ve put my common > parameters in /etc/swanctl/swanctl-ipsec.conf and

[strongSwan] Security Comparison

Hi Tobias, I think this is an underestimated point. Deserves more attention. > The cryptographic strength of all ciphers in a cipher suite should be > consistent. For instance, using AES-256 for ESP is basically wasted > when using MODP-2048 because that has only an estimated strength of 112 >

Re: [strongSwan] Security Comparison

Hi Andreas, > actually X25519 DH group 31 has a security strength of 128 bits, similar > to ECP-256, although the Curve25519 characteristics are much better > than those of the ECP-256 NIST curve. thanks for the correction.

[strongSwan] fortiOS multiple pair of selectors per CHILD_SA

I have successfully established an ipsec IKEv2 tunnel with a fortigate 1200D/FortiOS v5.2.4 It is the first device where I'm able to get multiple pair of selectors per CHILD_SA. The tricky thing to pay attention, is the comma separated list sequence, in the remote_ts parameter. For example, this

Re: [strongSwan] ipsec statusall: missing number of packets output

Hi Tobias, > Hi Marco, > > > Kindly I would like to ask if there is any know reason > > why ipsec statusall sometimes doesn't print the number > > of packets for the child_sa. > > The number of packets is printed if a last use time can be determined > via the respective policy. Check the log

[strongSwan] ipsec tunnel throughput measurement

Hello everyone, I have completed some speed test between two slackware linux 4.14 system running strongswan. The purpose is to estimate the network throughput inside an ipsec tunnel. Strongswan will not affect results, but I hope this message will be still informative for users subscribed to this

Re: [strongSwan] infinite loop for ipsec up/down command

Marco Berizzi wrote:   Tobias Brunner wrote:   > Hi Marco, > > > I'm running strongswan 5.6.2 on Slackware linux 64 bit > > Check the current master.  It includes fixes for issues like these (see > [1]). Just for record: when I issue for the 2nd time the ipsec up command str

Re: [strongSwan] infinite loop for ipsec up/down command

Tobias Brunner wrote:   > Hi Marco, > > > I'm running strongswan 5.6.2 on Slackware linux 64 bit > > Check the current master.  It includes fixes for issues like these (see > [1]). Hi Tobias, thanks a lot for the quick response. git cloned master, compiled and installed: problem is fixed.

[strongSwan] infinite loop for ipsec up/down command

Hello everyone, I'm running strongswan 5.6.2 on Slackware linux 64 bit I'm experimenting a pretty strange behavior with an ipsec tunnel. When I issue for the first time the 'ipsec up' command I get: ipsec up customer-10.14.143.0 initiating IKE_SA customer-10.14.143.0[21570] to 193.104.231.4

[strongSwan] Route-based VPNs (XFRM Interfaces) vs policies based VPNs

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

Re: [strongSwan] strongswan 5.8.3 core dump

Brunner Sent: Wednesday, March 25, 2020 3:07 PM To: Marco Berizzi ; users@lists.strongswan.org Subject: Re: [strongSwan] strongswan 5.8.3 core dump   Hi Marco, > What should I do to debug it? First, not stripping symbols/debug information from binaries probably would help.  Then y

Re: [strongSwan] strongswan 5.8.3 core dump

Hello Tobias, > I pushed a fix to master [1].  I guess we'll be releasing 5.8.4 soon. I have applied your fix and after 5 hours, everything is in good shape. Thanks a lot Tobias for the quick response and fix. Cheers, Marco PS: Here is the log: [CFG] found matching child config

Re: [strongSwan] strongswan 5.8.3 core dump

Thanks Tobias, I have run again 'make install', without stripping anymore the symbols. I'm waiting the crash. Thanks again. From: Tobias Brunner Sent: Wednesday, March 25, 2020 3:07 PM To: Marco Berizzi ; users@lists.strongswan.org Subject: Re: [strongSwan] strongswan 5.8.3 core dump

[strongSwan] strongswan 5.8.3 core dump

Hello everyone, I have just upgraded to 5.8.3 running on Slackware linux 64 bit. I'm getting this message on charon.log thread 4 received 11 dumping 11 stack frame addresses: /lib64/libpthread.so.0 @ 0x7f7ea89a4000 [0x7f7ea89b53b0] -> ??:? /usr/local/lib/ipsec/libcharon.so.0 @

[strongSwan] disregarded diffie hellmann group

Hello everyone, I'm experimenting a problem with an IKEv2 tunnel to a customer. I'm running strongswan 5.8.4, compiled from sources. This is my configuration file: children { networks1 { local_ts = 10.101.32.0/30 remote_ts = 10.101.10.0/25

Re: [strongSwan] disregarded diffie hellmann group

Hi Tobias, > You don't have to change the config as long as both peers agree to use a > DH group when rekeying or creating the SA with a CREATE_CHILD_SA > exchange. I tried to remove the dh group, but if my ipsec peer running strongswan is the initiator the proposal will be refused. > You only

Re: [strongSwan] disregarded diffie hellmann group

> [1] https://wiki.strongswan.org/projects/strongswan/wiki/ExpiryRekey#IKEv2 Thanks for the hints, Tobias. I have patched the configuration like this: from esp_proposals = aes256-sha512-ecp521 to esp_proposals = aes256-sha512-ecp521,aes256-sha512 Marco

Re: [strongSwan] disregarded diffie hellmann group

Hi Tobias, apologies for the late response. > You didn't clarify if that happens during a CHILD_SA initiation with > IKE_AUTH or with CREATE_CHILD_SA. According to the swanctl output it is happening with CHILD_SA initiation with IKE_AUTH: [IKE] initiating IKE_SA [146788] [ENC] generating

[strongSwan] negative rekeying time from swanctl -l

Hello everyone, I have encountered that the output of 'swanctl -l' sometimes returns a negative value on the rekeying time. Does it have any sort of special meaning? installed 890s ago, rekeying in -684s, expires in 10s Marco

[strongSwan] disable sending vendor id

Hello everyone, kindly, I would like to know if there is a way to make strongswan not send the 'vendor id'. Unfortunately the windows 10 update kb5009543 introduced this regression: "After installing this update, IP Security (IPSEC) connections that contain a Vendor ID might fail. VPN

Re: [strongSwan] disable sending vendor id

Hello, yes indeed, you are right. I noticed, unfortunately the regression introduced by microsoft is not fixable from strongswan's point of view. Marco From: Rajiv Kulkarni Sent: Monday, January 17, 2022 1:10 PM To: Marco Berizzi Cc: users@lists.strongswan.org Subject: Re: [strongSwan

Re: [strongSwan] disable sending vendor id

Hello Tobias, thank you for your kind reply. Undoubtedly the message reported by microsoft about the introduction of regression is rather unclear. Marco From: Tobias Brunner Sent: Monday, January 17, 2022 2:49 PM To: Marco Berizzi ; users@lists.strongswan.org Subject: Re: [strongSwan