Re: [strongSwan] Connect to StrongSwan Server via HTTP_PROXY

[Rafael Herrera]

Thank you very much guys and sorry for this basic question.

Best Regards.

2018-03-08 7:31 GMT-03:00 Noel Kuntze <
noel.kuntze+strongswan-users-ml@thermi.consulting>:

> Hi,
>
> You can't do that, because IPsec is based on UDP and ESP, not on TCP or
> HTTP. So of course this doesn't work.
>
> Kind regards
>
> Noel
>
> On 05.03.2018 22:20, Info wrote:
> >
> > Nah.  IPSec can carry tcp, udp, icmp, etc, but an http proxy can only
> carry http/tcp.
> >
> > Idk about a SOCKS proxy though.
> >
> >
> > On 03/05/2018 01:16 PM, Rafael Herrera wrote:
> >> Hi,
> >>
> >>
> >> Is it possible to connect a client to StrongSwan/IPSec VPN server
> through an HTTP Proxy in between the both hosts (client and server)?
> >>
> >>
> >> Please notice that I found that it is possible using OpenVPN <
> https://openvpn.net/index.php/open-source/documentation/
> manuals/65-openvpn-20x-manpage.html>:
> >>
> >> --http-proxy server port [authfile] [auth-method]Connect to remote host
> through an HTTP proxy at address server and port port. If HTTP
> Proxy-Authenticate is required, authfile is a file containing a username
> and password on 2 lines, or "stdin" to prompt from console.
> >>
> >> auth-method should be one of "none", "basic", or "ntlm".
> >>
> >>
> >> Is there any similar approach that I can use with StrongSwan/IPSec?
> >>
> >>
> >> Thanks,
> >> Best Regards.
> >> --
> >> Rafael de Paula Herrera
> >
>
>


-- 
Rafael de Paula Herrera

[strongSwan] Garbage for login/password on eap-radius from Win7

[Pete Ashdown]

Trying to do eap-radius with a stored mschapv2 hash in LDAP.  This works, 
sometimes, via MacOS.  However, Win7 and Win10 is just passing garbage to the 
freeradius server:

freeradius[23803]: Login Incorrect: [\\300\\250\\001\\002/] from client vpn01 
(mac=, cli=24.7.43.186[4500], port=IPSec-IKEv2)
radius3 freeradius[23803]: Login Incorrect: [\\300\\250z+/] from client vpn01 
(mac=, cli=199.104.120.17[4500], port=IPSec-IKEv2)

Here is what macOS looks like with a bad password:

freeradius[23803]: Login Incorrect: [pashdown/badpassword] from client sine 
(mac=, cli=, port=)

Here is my ipsec.conf:

# ipsec.conf - strongSwan IPsec configuration file

config setup
    charondebug="ike 4, knl 2, cfg 2, net 2, esp 2, dmn 2,  mgr 2"

# Add connections here.
conn %default
    keyexchange=ikev2
    dpdaction=clear
    dpddelay=300s
    authby=pubkey

conn IPSec-IKEv2
    left=166.70.8.21
    leftid=vpn.xmission.com
    leftsubnet=0.0.0.0/0,::/0
    leftcert=vpn_xmission_com.crt
    leftsendcert=always
    leftfirewall=yes
    right=%any
    rightid=%any
    rightauth=eap-radius
    rightdns=198.60.22.22,198.60.22.2,2607:fa18::2,2607:fa18::1
    rightsourceip=10.15.0.2-10.15.0.254,2607:fa18:0:beef:f00d::10-2607:fa18:0:be
ef:f00d::1:10
    keyexchange=ikev2
    auto=add
    eap_identity=%any

Any help would be appreciated.

Re: [strongSwan] Tunnel stability issues after upgrade from 4.5.2 to 5.5.1

[Martijn Grendelman]

Hi,

Thank you all for responding. In my case, I don't think it was related
to having mulitple child SAs per connection. Most of my connections do,
but I found at least one case with only one child SA, where the problem
was present. In any case, I followed Tom's and Noel's advice and set

    auto = route
    dpdaction = clear

and that seems to have solved the issue. Thanks again.

Best regards,
Martijn Grendelman





Op 8-3-2018 om 11:46 schreef Noel Kuntze:
> Hi,
>
> That's because charon doesn't reestablish tunnels in any case, like pluto 
> did. Use auto=route, instead of auto=start.
> An example of such a case is if the other peer deletes the iKE SA or CHILD SA 
> without establishing a new one at the same time.
> You can have different IKE SAs for CHILD_SAs by setting the strongswan.conf 
> option charon.reuse_ikesa to 0.
>
>>    charon.reuse_ikesa [yes]
>>   Initiate  CHILD_SA  within  existing IKE_SAs (always enabled 
>> for
>>   IKEv1).
> Kind regards
>
> Noel
>
> On 07.03.2018 22:20, Justin Pryzby wrote:
>> On Wed, Mar 07, 2018 at 10:52:54AM +0100, Martijn Grendelman wrote:
>>> I have been running StrongSwan on Debian Wheezy (with StrongSwan 4.5.2)
>>> for a long time.
>> [...]
>>
>>> Last week, I upgraded the system to Debian Stretch (with StrongSwan
>>> 5.5.1), and since then, a number of tunnels (but not all of them) have
>>> stability issues. The issue appears to be that CHILD_SA's are not
>>> established when needed,
>> Maybe you know that in 5.0, IKEv1 was integrated into charon and separate 
>> pluto
>> daemon was retired:
>> https://www.strongswan.org/blog/2012/07/02/strongswan-5.0.0-released.html
>> https://wiki.strongswan.org/projects/strongswan/wiki/CharonPlutoIKEv1
>> https://www.strongswan.org/blog/2012/06/20/bye-bye-pluto.html
>> https://wiki.strongswan.org/projects/strongswan/wiki/500
>>
>> Just wondering: are all the tunnels with issues have multiple child SAs (or,
>> the tunnels without issues all have only one child SA).
>>
>> I recently reported an issue here, also related to a migration/update from 
>> 4.5,
>> and started to suspect that multiple child SAs may be involved..
>> https://wiki.strongswan.org/issues/2535
>>
>> Note, I believe swanctl.conf allows configuring child SAs to use separate 
>> IKEs
>> - avoiding the non-configurable behavior in starter+ipsec.conf: "added child 
>> to
>>   existing configuration".  However that doesn't work for everyone(us) due to
>> unique policy on remote peers.
>>
>> Justin

-- 
Met vriendelijke groet,
Kind regards,
Martijn 
Martijn Grendelman  Infrastructure Architect  
T: +31 (0)40 264 94 44   

ISAAC 
Marconilaan 16   5621 AA Eindhoven   The Netherlands
T: +31 (0)40 290 89 79   www.isaac.nl 

Dit e-mail bericht is alleen bestemd voor de geadresseerde(n). Indien
dit bericht niet voor u is bedoeld wordt u verzocht de afzender hiervan
op de hoogte te stellen door het bericht te retourneren en de inhoud
niet te gebruiken. Aan dit bericht kunnen geen rechten worden ontleend.

Re: [strongSwan] Tunnel stability issues after upgrade from 4.5.2 to 5.5.1

[Noel Kuntze]

Hi,

That's because charon doesn't reestablish tunnels in any case, like pluto did. 
Use auto=route, instead of auto=start.
An example of such a case is if the other peer deletes the iKE SA or CHILD SA 
without establishing a new one at the same time.
You can have different IKE SAs for CHILD_SAs by setting the strongswan.conf 
option charon.reuse_ikesa to 0.

>   charon.reuse_ikesa [yes]
>  Initiate  CHILD_SA  within  existing IKE_SAs (always enabled for
>  IKEv1).

Kind regards

Noel

On 07.03.2018 22:20, Justin Pryzby wrote:
> On Wed, Mar 07, 2018 at 10:52:54AM +0100, Martijn Grendelman wrote:
>> I have been running StrongSwan on Debian Wheezy (with StrongSwan 4.5.2)
>> for a long time.
> [...]
>
>> Last week, I upgraded the system to Debian Stretch (with StrongSwan
>> 5.5.1), and since then, a number of tunnels (but not all of them) have
>> stability issues. The issue appears to be that CHILD_SA's are not
>> established when needed,
> Maybe you know that in 5.0, IKEv1 was integrated into charon and separate 
> pluto
> daemon was retired:
> https://www.strongswan.org/blog/2012/07/02/strongswan-5.0.0-released.html
> https://wiki.strongswan.org/projects/strongswan/wiki/CharonPlutoIKEv1
> https://www.strongswan.org/blog/2012/06/20/bye-bye-pluto.html
> https://wiki.strongswan.org/projects/strongswan/wiki/500
>
> Just wondering: are all the tunnels with issues have multiple child SAs (or,
> the tunnels without issues all have only one child SA).
>
> I recently reported an issue here, also related to a migration/update from 
> 4.5,
> and started to suspect that multiple child SAs may be involved..
> https://wiki.strongswan.org/issues/2535
>
> Note, I believe swanctl.conf allows configuring child SAs to use separate IKEs
> - avoiding the non-configurable behavior in starter+ipsec.conf: "added child 
> to
>   existing configuration".  However that doesn't work for everyone(us) due to
> unique policy on remote peers.
>
> Justin



signature.asc
Description: OpenPGP digital signature

Re: [strongSwan] best practice for IKEv2 lifetimes

[Noel Kuntze]

Hi,

Set the correct life time locally and a sizeable margintime.
That works around the issue of bad administration on the other end. If they set 
it up right, the lifetime is exactly the same as on your side, the margintime 
makes a collision unlikely.
If the lifetime on your side is less than on their side, you rekey earlier than 
them, so no problem.
If the lifetime on their side is less than on your side, they rekey earlier 
than you, so no problem.
For the rekeying itself, use a rekeyfuzz value that results in a time span of 
several minutes.

You can try using make then break (search the man page for strongswan.conf) for 
IKEv2. If it works with CISCO, then it's fine.
Otherwise, you'll have to make do with that. There were some commits merged 
into master a couple of versions ago that make auto=route work better with 
IKEv2 during rekeyings and reauthentication,
so this might be the proper solution for you.

There are different settings for IKE SA and IPsec SA rekeyings. They're a 
little bit obscurely described on the man page for ipsec.conf, but that should 
not be an issue. The bottom of the man page should help you tell the difference.

Kind regards

Noel

On 07.03.2018 15:56, Waldemar Brodkorb wrote:
> Hi,
>
> We are using Strongswan 5.5.1 on Debian 9 with IKEv2.
> The other sides are Cisco ISR 2900 routers. The connection works
> fine, but sometimes we have a disconnect and the tunnels on the
> Cisco side marked as down. After /etc/init.d/ipsec restart
> everything works again.
>
> In the early days when I started using IPsec this always meant to
> be a difference in the lifetime configured for IKE SA or IPsec SA.
>
> I am new to IKEv2 and started investigating the problem, the RFC7296
> clearly states: "A difference between IKEv1 and IKEv2 is that in
> IKEv1 SA lifetimes were negotiated.  In IKEv2, each end of the SA is
> responsible for enforcing its own lifetime policy on the SA and
> rekeying the SA when necessary.  If the two ends have different
> lifetime policies, the end with the shorter lifetime will end up
> always being the one to request the rekeying."
>
> What is best practice to define a lifetime? 
> Should it be defined on the Cisco side or on the Strongswan side?
> Or on both sides different to avoid simultaneous rekeying?
> Strongswan has some options for jittering the lifetime, but I think
> Cisco side does not have it.
> What if I want IKE SA rekeying after 24 hours and IPsec SA rekeying
> after 1 hours?
>
> We use ipsec.conf, our template looks like this for now:
> config setup
>   # Enable debug logs:
> #charondebug="ike 2, cfg 2"
> charonstart=yes
> conn %default
> ikelifetime=1440m
> keylife=60m
> ike=aes256-sha512-modp4096
> esp=aes256-sha512
> rekeymargin=3m
> keyingtries=1
> mobike=no
> keyexchange=ikev2
> authby=rsasig
>
> conn host-vpn1
> leftcert=<%= @fqdn %>.pem
> left=%any
> right=<%= @router1 %>
> rightid=%any
> type=transport
> auto=add
>
> conn host-vpn2
> leftcert=<%= @fqdn %>.pem
> left=%any
> right=<%= @router2 %>
> rightid=%any
> type=transport
> auto=add
>
> Should I better add "reauth = no" to avoid short connection outage and
> just explicitely enable "rekey = yes" and "rekeyfuzz = 100%" to avoid
> rekeying of both tunnels in the same timeframe?
>
> best regards
>  Waldemar



signature.asc
Description: OpenPGP digital signature

Re: [strongSwan] StrongSwan - can't route traffic over it

[Noel Kuntze]

Hi,

Your iptables rules in the *nat table probably cause your issue.

Take a look at the article about forwarding and split tunneling[1]. And stop 
using `iptables -L`, it doesn't show you everything. Always use `iptables-save` 
or `iptables-save -c` instead.

Kind regards

Noel

[1] 
https://wiki.strongswan.org/projects/strongswan/wiki/ForwardingAndSplitTunneling#General-NAT-problems

On 07.03.2018 05:37, Brenden wrote:
> Hi All,
>
> I'm attempting to run StrongSwan on Ubuntu 16.04.3 LTS.
>
> IPs chanaged for privacy:
>
> My server IP 110.0.0.110
> My subnet is 110.0.0.0/25
> Internal IP: 192.168.50.214
> Remote Peers: 1.2.3.111 (pri) / 1.2.3.112 (sec)
>
> The primary connection is currently not configured (its still running on
> our hardware FW) but the secondary one has been re-configured with the
> other peer and connection successfully establishes.
>
> They can see our successful connection is up but can't see any traffic
> being sent from our side.
>
> I am running HAPROXY on my strongswans server which forwards traffic from
> 192.168.50.214: to 10.4.34.70: (via IPSEC tunnel). I can't ping,
> telnet, curl or do anything against this host.
>
> I have this working in a legacy (undocumented environment on a Fortigate
> FW), but that's being replaced.
>
> # ipsec statusall
> Status of IKE charon daemon (strongSwan 5.3.5, Linux 4.4.0-109-generic,
> x86_64):
>   uptime: 51 minutes, since Mar 07 13:21:13 2018
>   malloc: sbrk 2588672, mmap 0, used 588944, free 1999728
>   worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0,
> scheduled: 7
>   loaded plugins: charon test-vectors aes rc2 sha1 sha2 md4 md5 random
> nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp
> dnskey sshkey pem openssl fips-prf gmp agent xcbc hmac gcm attr
> kernel-netlink resolve socket-default connmark farp stroke updown
> eap-identity eap-sim eap-sim-pcsc eap-aka eap-aka-3gpp2
> eap-simaka-pseudonym eap-simaka-reauth eap-md5 eap-gtc eap-mschapv2
> eap-dynamic eap-radius eap-tls eap-ttls eap-peap eap-tnc xauth-generic
> xauth-eap xauth-pam xauth-noauth tnc-tnccs tnccs-20 tnccs-11
> tnccs-dynamic dhcp lookip error-notify certexpire led addrblock unity
> Listening IP addresses:
>   110.0.0.110
>   192.168.50.214
> Connections:
>  ipsec-pri:  110.0.0.110...1.2.3.111  IKEv1, dpddelay=30s
>  ipsec-pri:   local:  uses pre-shared key authentication
>  ipsec-pri:   remote: uses pre-shared key authentication
>  ipsec-pri:   child:  110.0.0.0/25 === 10.5.35.0/24 TUNNEL,
> dpdaction=restart
>  ipsec-sec:  110.0.0.110...1.2.3.112  IKEv1, dpddelay=30s
>  ipsec-sec:   local:  [110.0.0.110] uses pre-shared key authentication
>  ipsec-sec:   remote: uses pre-shared key authentication
>  ipsec-sec:   child:  110.0.0.0/25 === 10.4.34.70/32 10.4.34.71/32
> TUNNEL, dpdaction=restart
> Security Associations (1 up, 0 connecting):
>  ipsec-sec[2]: ESTABLISHED 51 minutes ago,
> 110.0.0.110[110.0.0.110]...1.2.3.112[1.2.3.112]
>  ipsec-sec[2]: IKEv1 SPIs: ea2ac47190a16341_i* 6f0f64f9d22fd5c2_r,
> pre-shared key reauthentication in 22 hours
>  ipsec-sec[2]: IKE proposal:
> 3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
>  ipsec-sec{2}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: cc381424_i
> 15dd64ce_o
>  ipsec-sec{2}:  3DES_CBC/HMAC_SHA1_96, 0 bytes_i, 10140 bytes_o (169
> pkts, 1s ago), rekeying in 46 minutes
>  ipsec-sec{2}:   110.0.0.0/25 === 10.4.34.70/32
>
>
> /etc/ipsec.conf file:
> ##
> conn ipsec-pri
> ikelifetime=86400s
> authby=secret
> auto=start
> keyexchange=ikev1
> type=tunnel
> left=110.0.0.110
> leftid=%any
> leftsubnet=110.0.0.0/25
> right=1.2.3.111
> rightid=%any
> rightsubnet=10.5.35.0/24
> ike=3des-sha1-modp1024
> esp=3des-sha1-modp1024
> dpdaction=restart
>
>
> conn ipsec-sec
> ikelifetime=86400s
> authby=secret
> auto=start
> keyexchange=ikev1
> type=tunnel
> left=110.0.0.110
> leftid=%any
> leftsubnet=110.0.0.0/25
> right==1.2.3.112
> rightid=%any
> rightsubnet=10.4.34.70/32,10.4.34.71/32
> ike=3des-sha1-modp1024
> esp=3des-sha1-modp1024
> dpdaction=restart
> ##
>
> ~# iptables -L
> Chain INPUT (policy ACCEPT)
> target prot opt source   destination
>
> Chain FORWARD (policy ACCEPT)
> target prot opt source   destination
>
> Chain OUTPUT (policy ACCEPT)
> target prot opt source   destination
>
> I've enabled forwarding in /etc/sysctl.conf
> net.ipv4.ip_forward=1
>
>
> I've been back and forth on this for a few months but just really stuck.
>
> Any ideas on where i'm going wrong? I hope I've included enough info to
> get pointed in the right direction.
>



signature.asc
Description: OpenPGP digital signature

Re: [strongSwan] strongSwan 5.6.2 charon terminating on critical signal

[Noel Kuntze]

Hi,

See #2579[1].

Kind regards

Noel

[1] https://wiki.strongswan.org/issues/2579

On 06.03.2018 13:18, Francois ten Krooden wrote:
>
> Hi
>
>  
>
> After updating the FreeBSD port of strongswan to 5.6.2 we are getting quite a 
> few cases in the strongswan test suite with the following issue.
>
>  
>
> Mar  5 20:21:37 carol charon: 13[IKE] authentication of 
> 'ca...@strongswan.org' (myself) with RSA_EMSA_PKCS1_SHA2_256 successful
>
> Mar  5 20:21:37 carol charon: 13[DMN] thread 13 received 11
>
> Mar  5 20:21:37 carol charon: 13[LIB]  dumping 2 stack frame addresses:
>
> Mar  5 20:21:37 carol charon: 13[LIB]   /lib/libthr.so.3 @ 0x000800f51000 
> (pthread_sigmask+0x536) [0x000800f5f926]
>
> Mar  5 20:21:37 carol charon: 13[LIB] -> ??:0
>
> Mar  5 20:21:37 carol charon: 13[LIB]   /lib/libthr.so.3 @ 0x000800f51000 
> (pthread_getspecific+0xe5f) [0x000800f5eecf]
>
> Mar  5 20:21:37 carol charon: 13[LIB] -> ??:0
>
> Mar  5 20:21:37 carol charon: 13[DMN] killing ourself, received critical 
> signal
>
>  
>
> This was specifically on the ikev2/alg-sha256 test.
>
>  
>
> Any ideas as to where the problem is.
>
>  
>
> *Francois ten Krooden*
>
> *Senior Software **Developer*
>
>  
>
> Description: NTQ Logo.jpg**
>
> *    **T*el: +27 12 672 7000**
>
> *    F*ax: +27 12 665 1343
>
> *    P*ostal: P.O. Box 7991, Centurion, 0046
>
> *    P*hysical: Unit C01, Corporate Park 66, 269 Von Willich Avenue, 
> Centurion
>
>  
>
>
> Important Notice:
>
> This e-mail and its contents are subject to the Nanoteq (Pty) Ltd e-mail 
> legal notice available at:
> http://www.nanoteq.com/AboutUs/EmailDisclaimer.aspx



signature.asc
Description: OpenPGP digital signature

Re: [strongSwan] Connect to StrongSwan Server via HTTP_PROXY

[Noel Kuntze]

Hi,

You can't do that, because IPsec is based on UDP and ESP, not on TCP or HTTP. 
So of course this doesn't work.

Kind regards

Noel

On 05.03.2018 22:20, Info wrote:
>
> Nah.  IPSec can carry tcp, udp, icmp, etc, but an http proxy can only carry 
> http/tcp.
>
> Idk about a SOCKS proxy though.
>
>
> On 03/05/2018 01:16 PM, Rafael Herrera wrote:
>> Hi,
>>
>>
>> Is it possible to connect a client to StrongSwan/IPSec VPN server through an 
>> HTTP Proxy in between the both hosts (client and server)?
>>
>>
>> Please notice that I found that it is possible using OpenVPN 
>> :
>>
>> --http-proxy server port [authfile] [auth-method]Connect to remote host 
>> through an HTTP proxy at address server and port port. If HTTP 
>> Proxy-Authenticate is required, authfile is a file containing a username and 
>> password on 2 lines, or "stdin" to prompt from console.
>>
>> auth-method should be one of "none", "basic", or "ntlm".
>>
>>
>> Is there any similar approach that I can use with StrongSwan/IPSec?
>>
>>
>> Thanks,
>> Best Regards.
>> -- 
>> Rafael de Paula Herrera
>



signature.asc
Description: OpenPGP digital signature