[strongSwan] ikelifetime maximum?

[Tom Rymes]

While perusing the documentation, specifically 
http://wiki.strongswan.org/projects/strongswan/wiki/ConnSection , I 
noticed that a 24h maximum is specified for 'lifetime', but there is no 
maximum specified for 'ikelifetime'.

I don't personally want to use a large 'ikelifetime', but for the sake 
of completeness, I thought it ought to be specified.

Also, I would like to confirm that 'lifetime' is generally set to be 
smaller than 'ikelifetime' (although it doesn't need to be).

Tom

___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] reduce size

[Tom Rymes]

On Sep 12, 2013, at 8:35 PM, Naveen Neelakanta nbnopens...@gmail.com wrote:

 Is there a way to reduce the size of charon and strongswan , i just need the 
 basic vpn client 
 with out extra pluggins and use openssl for cryptography.

The last time this came up, the recommendation was to build everything as a 
module, then only load those modules you need.

Tom

___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] Recommended command order.

[Tom Rymes]

We currently use a firewall distro that has a GUI to 
add/modfiy/delete/restart StrongSwan tunnels. The update to v5 of 
StrongSwan caused some issues, which were eventually traced back to the 
GUI issuing ipsec reload, but not ipsec rereadsecrets when creating 
a PSK tunnel.

My hunch here is that this worked with StrongSwan v4 and earlier because 
pluto restarted whenever 'ipsec reload' was issued, such that the entire 
configuration, including ipsec.secrets was reloaded, even if you did not 
explicitly issue ipsec rereadsecrets or ipsec rereadall. However, 
beginning with v5, charon does not do this, and as such, issuing 'ipsec 
reload' without 'rereadsecrets' causes charon to see the new tunnel, but 
not the new PSK, and as such, fail to bring the tunnel up. This hunch is 
based on the fact that the docs say 'ipsec update' and 'ipsec reload' 
only determine changes in ipsec.conf, not in any other files, such as 
ipsec.secrets 
(http://wiki.strongswan.org/projects/strongswan/wiki/IpsecCommand).

In any case, that issue has been corrected in the GUI by adding 'ipsec 
rereadall' prior to issuing 'ipsec reload'. However, I am now wondering, 
what is the proper order of commands to issue once you have 
added/deleted/stopped a tunnel, such that similar situations can be 
avoided?

For example: Does it also make sense to issue a rereadall command when 
deleting a tunnel, such that charon forgets the PSK and IDs?

When would you issue a reload and not reread secrets/all/etc?

Hopefully this isn't an overly obvious question, any thoughts appreciated.

Tom

___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] ipsec update and SIGHUP

[Tom Rymes]

On 03/18/2015 9:37 AM, Tobias Brunner wrote:

But still ipsec update does reread contents of ipsec.conf, am I right?


Yes, this will cause starter to reread ipsec.conf.


And does sending HUP to charon forces it to reread ipsec.conf or just
the strongswan.conf?


The charon daemon only reads strongswan.conf, and ipsec.conf is only
read by starter.  So if you changed both files you might want to send
SIGHUP to both charon and starter (the latter can be done via `ipsec
update`).


I would add that the update command does not force charon to reread PSKs 
or certificates, if memory serves, so you may need to use rereadall or 
one of the other reread commands if you need that done, too.


Tom

___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] Usage questions: DPD and auto=

[Tom Rymes]

All,

I have two questions:

1.) Since IKEv2 does not use DPD, should one omit the dpdaction 
directives from ipsec.conf for a connection using IKEv2? Is there any 
harm/unintended consequences if they are left in, and are there 
alternate directives that one should use instead?


2.) Is it appropriate to use auto-route on both ends of a tunnel, or 
should only one end be set up that way to avoid issues when both ends 
try to bring the tunnel up at the same time?


Thank you,

Tom
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Loss of tunnel service while reauthenticating IKE_SA?

[Tom Rymes]

On 03/12/2015 11:16 AM, Noel Kuntze wrote:


Hello Ken,

It is dependent on the IKE version.
Quote from the man page:

reauth = yes | no
   whether rekeying of an IKE_SA  should  also  reauthenticate  the
   peer.  In  IKEv1,  reauthentication  is always done. In IKEv2, a
   value of no rekeys without uninstalling the IPsec SAs,  a  value
   of yes (the default) creates a new IKE_SA from scratch and tries
   to recreate all IPsec SAs.

Obviously, setting reauth=no will keep the tunnel up during rekeying of the IKE 
SAs.
You have to use reauth=no on both sides to make it work.


Noel,

Is there a reason that, when using two Strongswan endpoints, one would 
not choose reauth=no? It seems to me that using reauth=no would result 
in fewer traffic interruptions, unless I have missed something.


Tom
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Query reg UDP encapsulation for IPv6

[Tom Rymes]

On 04/15/2015 10:15 AM, Ruel, Ryan wrote:

Mukesh,

I believe the idea is that for IPv6, NAT will not be needed (that's the
beauty of having so much address space!).

Technically, sure, you could NAT IPv6.  But why?

/Ryan


Ryan,

Perhaps the best reason to address this is that the exact same thing 
would have been said about IPv4 back in the day, so addressing this 
issue now might make sense as a way of future-proofing things.


Tom

___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Recommendations for dpdaction= and auto=

[Tom Rymes]

Thank you, Noel. I will move forward with those recommendations and work to get 
the IPFire (the distribution we use) WUI updated to allow the auto= changes.

Tom

 On Jul 31, 2015, at 9:57 AM, Noel Kuntze n...@familie-kuntze.de wrote:
 
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 Hello Tom,
 
 Use auto=route and dpdaction=clear between sites with static IPs.
 For connection between sites with mixed static and dynamic IPs,
 use auto=add and dpdaction=clear on the side with the static IP
 and auto=route and dpdaction=restart, or auto=route and dpdaction=clear
 on the side with the dynamic IP.
 
 Mit freundlichen Grüßen/Kind Regards,
 Noel Kuntze
 
 GPG Key ID: 0x63EC6658
 Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658
 
 Am 30.07.2015 um 18:18 schrieb Tom Rymes:
 We have a number of sites connected via StrongSwan IKEv2 tunnels, and I was 
 hoping that someone might provide me with the recommended settings for 
 dpdaction and auto, given our setup. I think have a reasonable handle on 
 this, but I wanted to ask in case I was doing anything that might result in 
 reduced reliability or fault tolerance.
 
 1.) Two main offices with static IPs, Phone, file, print, and database 
 servers.
 2.) Multiple branch office, most with static IPs, a few with Dynamic IPs, 
 client PCs and SIP phones. Each branch has two tunnels, one to each main 
 office.
 
 I am fairly certain that I was previously told to set dpdaction=restart in 
 the main offices and dpdaction=clear in the branches, but I am not certain 
 what I should be doing with the auto= directive.
 
 The main goal is reliability of the tunnels and a reduced need to restart 
 tunnels manually when one side or the other loses connectivity.
 
 Many thanks,
 
 Tom
 ___
 Users mailing list
 Users@lists.strongswan.org
 https://lists.strongswan.org/mailman/listinfo/users
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2
 
 iQIcBAEBCAAGBQJVu37JAAoJEDg5KY9j7GZYSxYP/jEbVSVtJLUZP8KZ6858Ha8j
 dBEJ1i/u7d/DrGQGRYR65CZR40mm9+FOuxZk+sIo9mzusfWfx4DEjVG1zgyZ6He9
 X8NcHotRuFgFN11UQ0AigdIVK0KB0NomMxX74nPHGXcmQht3jUuk4JANsDV6R0La
 MqF06vnVkYRz+mtR8jqmOZSU+CYWf7VZLUbQgvRPUGArearfhNVzUhmedayoM0xj
 jfFcW2Zb2Ay++IgGQce8z3zssEtU1l1ja6FxuMJAkc/IsDlLUHFuFRw2j8k65V5d
 zLZ9ND8UNIuwX0p8MNvakMa2tu3BcgYSwhypEDyyLI8LvFsZOEm8vVlCdAxQo0TE
 pkGdaPbksKmj7KnDgd5W+DvT6Up051t4LI669nmQugHdKVJfaw4Flkt9WKT4xcrX
 58kF80e93XYH8IgQsZHaNpMwaJdeJnwBtWzQVJ0HuQ6Q0KMLniwfQSbxA4/7cvYj
 xainZ7Dkt4K5P5Rlj2YPm8WmJxDyanhzSRuSaJHSdjdfQBqSLM7gQNCDoYO9aHMC
 Omdx1tHdTTkFzzxbeE2z/g2DFvR/Ks2b8uNA9up9i2JWR/r+mthjumqiCIVU8IKq
 BWnvKDSJy1xaUjIiUhp1Sl64WoSgibM5v81OlA1qlorZAbvV5+HCpAQHnRzGtbUH
 AMtGdS32ViR3ZODVMcz2
 =8wS0
 -END PGP SIGNATURE-
 
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] Recommendations for dpdaction= and auto=

[Tom Rymes]

We have a number of sites connected via StrongSwan IKEv2 tunnels, and I 
was hoping that someone might provide me with the recommended settings 
for dpdaction and auto, given our setup. I think have a reasonable 
handle on this, but I wanted to ask in case I was doing anything that 
might result in reduced reliability or fault tolerance.


1.) Two main offices with static IPs, Phone, file, print, and database 
servers.
2.) Multiple branch office, most with static IPs, a few with Dynamic 
IPs, client PCs and SIP phones. Each branch has two tunnels, one to each 
main office.


I am fairly certain that I was previously told to set dpdaction=restart 
in the main offices and dpdaction=clear in the branches, but I am not 
certain what I should be doing with the auto= directive.


The main goal is reliability of the tunnels and a reduced need to 
restart tunnels manually when one side or the other loses connectivity.


Many thanks,

Tom
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] unable to install policy for clients some minutes after the first client has connected

[Tom Rymes]

On 07/21/2015 2:43 PM, Larsen wrote:

Hello Noel,

problem didn´t occur again when I tested over more than two hours.
Should be fixed.

The problematic vhost:%no,%priv seems to stem from IPcop that IPFire
was forked from. I could remove this by unchecking Roadwarrior virtual
IP (inner-IP).
I will also update the IPFire wiki as the current example is incorrect
in some ways.

Thanks for your help!


Lars


Lars,

Please also file a bug at the IPFire bug tracker, plus a forum topic so 
the developers (who are very responsive) can fix any old, inaccurate code.


Tom

___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] Best practices for connection tracking and IPSec

[Tom Rymes]

I am sure that this is a dumb question that will reveal my lack of 
sophisticated networking skills, but here goes anyway:

We have used a number of Linux Firewall distributions that have issues with 
connection tracking (NAT) and StrongSwan IPSec tunnels. 

Specifically, issues arise with SIP (over UDP) registrations when a tunnel 
drops and a bad connection tracking entry prevents traffic from passing across 
the tunnel. Telnet, ping, etc to the same device works just fine. When it 
happens, deleting the offending connection tracking entry immediately resolves 
the issue, as does moving the device to another IP or unplugging it until the 
tracking entry expires.

I have also seen issues with TFTP and FTP, where they fail to work across IPSec 
tunnels unless you unload the associated conntrack helper kernel modules.

>From where I sit, it seems to me that connection tracking over tunnels should 
>be disabled, as there is no NAT involved. Is this correct? What is the 
>recommended practice here, as It seems that a number of distributions are 
>struggling with this, and it is causing me no end of troubles!

Many thanks,

Tom
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Best practices for connection tracking and IPSec

[Tom Rymes]

And I already put my foot in my mouth. I meant to specify that I was referring 
to the conntrack NAT helpers for specific protocols, not connection tracking in 
general.

> On Sep 28, 2015, at 7:22 PM, Tom Rymes <try...@rymes.com> wrote:
> 
> I am sure that this is a dumb question that will reveal my lack of 
> sophisticated networking skills, but here goes anyway:
> 
> We have used a number of Linux Firewall distributions that have issues with 
> connection tracking (NAT) and StrongSwan IPSec tunnels. 
> 
> Specifically, issues arise with SIP (over UDP) registrations when a tunnel 
> drops and a bad connection tracking entry prevents traffic from passing 
> across the tunnel. Telnet, ping, etc to the same device works just fine. When 
> it happens, deleting the offending connection tracking entry immediately 
> resolves the issue, as does moving the device to another IP or unplugging it 
> until the tracking entry expires.
> 
> I have also seen issues with TFTP and FTP, where they fail to work across 
> IPSec tunnels unless you unload the associated conntrack helper kernel 
> modules.
> 
> From where I sit, it seems to me that connection tracking over tunnels should 
> be disabled, as there is no NAT involved. Is this correct? What is the 
> recommended practice here, as It seems that a number of distributions are 
> struggling with this, and it is causing me no end of troubles!
> 
> Many thanks,
> 
> Tom
> ___
> Users mailing list
> Users@lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Problem when forwarding all traffic to tunnel (site-to-site VPN)

[Tom Rymes]

If nothing else, you can use the updown script to add these entries, I presume?

> On Sep 21, 2015, at 3:41 AM, Rajiv Kulkarni  wrote:
> 
> Hi
> Thats great. Yes ofcourse...addition and deletion/updation of new networks of 
> lan in to this strongawan routing table 220 has to be done dynamically ...i 
> dont know how at this time
> 
> -rajiv
> 
> 
>> On Mon, Sep 21, 2015 at 9:18 AM, Rayson Zhu  wrote:
>> Hi Rajiv,
>> Thanks.for your reply. I tried your method and now my LAN is able to access 
>> to the Internet. But dealing with routes by manual is troublesome when a 
>> gateway already had complex routing tables. I will use this workaround 
>> temporarily and continue to find other solutions. 
>> 
>>> On Sun, Sep 20, 2015 at 11:39 PM, Rajiv Kulkarni 
>>>  wrote:
>>> Hi
>>> 
>>> One workaround method i have been using in this scenario is to put the 
>>> route you have added into table 220 - the routing table referenced by 
>>> strongswan.
>>> e,g:
>>> 
>>> ip route add 10.10.0.0/16 dev lan table 220
>>> 
>>> - i guess it should start working with the above route in table 220
>>> - the route you have added (without table 220) is included in the main 
>>> routing table, which is correct, but is not referenced by strongswan
>>> - this is a issue on a GW/peer, especially and only, when you have the 
>>> policy "leftsubnet=your-lan" and "rightsubnet=0.0.0.0/0"
>>> 
>>> But then again, iam no expert in strongswan...so you would please ask for 
>>> advice and correct solution from the strongswan team itself
>>> 
>>> thanks
>>> rajiv
>>>  
>>> 
>>> 
 On Sun, Sep 20, 2015 at 8:08 PM, Rayson Zhu  wrote:
 Hello all,
 The gateway of my local site has a site-to-site VPN to my remote site.  I 
 want to forward all traffic (including internet traffic) from my local 
 site to  remote site.
 
 The ipsec.conf in local gateway:
 
 conn %default
 
 left=%any
 
 leftcert=<>
 
 leftid=<>
 
 leftauth=pubkey
 
 keyexchange=ikev2
 
 conn site-to-site
 
 right=
 
 rightid=<>
 
 rightauth=pubkey
 
 leftsubnet=10.10.0.0/23
 
 rightsubnet=0.0.0.0/0
 
 auto=add
 
 
 
 After establishing the IPSec connection, the gateway can access to the 
 internet through the tunnel, but at the same time the all hosts behind the 
 gateway will lose connectivity to the gateway. 
 
 That makes sense, because the config rule 'rightsubnet=0.0.0.0/0' tells 
 IPSec to forward all traffic into tunnel, including the traffic to LAN. I 
 added a passthrough policy like this:
 
 conn bypasslan
 
leftsubnet=10.10.0.0/23
 
 rightsubnet=10.10.0.0/23
 
 type=passthrough
 
auto=route
 
 But this policy does not work. Hosts in lan still cannot ping gateway.
 
 I decided to use traceroute to see what is going on. The result shows that 
 the traffic to LAN goes to the WAN interface without IPSec protection. I 
 checked the route table and every thing looks normal. I tried adding a 
 route rule 'ip route add 10.10.0.0/16 dev lan' but this didn't work.
 
 I stop the IPSec tunnel, the connection between LAN hosts with the gateway 
 comes back.
 
 I will be very appreciate it if you can help me solve this problem.
 
 
 
 Thanks & Regards,
 
 Rayson
 
 
 ___
 Users mailing list
 Users@lists.strongswan.org
 https://lists.strongswan.org/mailman/listinfo/users
> 
> ___
> Users mailing list
> Users@lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] Recommended Practice: Encryption options for net-to-net tunnels

[Tom Rymes]

I was hoping that someone might aid me in providing a best practice when 
setting up a tunnel between two devices connecting two lans.

Is it best to specify one and only one combination of encryption schemes for 
this tunnel (i.e.: ike=aes256-sha2_256-ecp512bp) or multiple options? This is 
presuming that you know what options each side supports.

In other words, which aids in reliability and avoiding problems: limiting the 
options down to one combination, or providing multiple choices?

Thank you,

Tom
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Recommended Practice: Encryption options for net-to-net tunnels

[Tom Rymes]

On 12/10/2015 11:34 AM, Andreas Steffen wrote:

By the way

ike=aes256-sha2_256-ecp512bp

does not give you constant 256 bit security. The correct choice is

ike=aes256-sha512-ecp512bp!

Make sure to add the '!' strict flag at the end of your proposal
list. Otherwise a big list of default strongSwan proposals will be
appended.


While we are on this topic, is there any sort of consensus on proposals 
to use when connecting Strongswan boxen?


I am generally connecting two types of tunnels, both of which carry SIP 
voice traffic:


1.) Device supporting AES-NI to Device not supporting AES-NI
2.) Two devices that both support AES-NI

Given the gains in encryption/decryption speed, I presume that the 
combination that combines the best tradeoff between security, 
throughput, and latency will be different depending on which of those 
two types is being set up, and as evidenced above, I clearly don't know 
enough to wisely choose a good combination.


At one point I had chosen these settings, but they are likely far from 
optimal.


ike=aes128gcm128-aesxcbc-ecp512bp
esp=aes128gcm128-ecp512bp

My apologies if this is a question with an obvious answer that I have 
simply missed.


Thank you,

Tom
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] Issue Upon Rekey Collision.

[Tom Rymes]

I encountered an issue today with a rekey collision. When it happened, 
the tunnel appeared to be up, but traffic could not traverse the tunnel. 
After digging around, I found this discussion, which seems to be the 
same issue, and the original poster also seems to be using IPFire, as I 
am: 
https://lists.strongswan.org/pipermail/users/2015-January/007365.html . 
I also found a thread on the IPFire forum with a similar problem that 
has lots of details (though sadly no replies) here: 
http://forum.ipfire.org/viewtopic.php?f=27=12628


This is a snippet from my logs of when the collision occurred, followed 
by a snippet when I issued "ipsec down TunnelName", where I see errors 
about IPTables rules not existing. My question is whether this is an 
issue with StrongSwan (I'm guessing no), or with IPFire and the contents 
of the updown script that they have supplied (I'm guessing that's it). I 
just want to make sure that I am barking up the right tree while looking 
for a solution, so please let me know.


Log snippet of collision:
|Dec 14 13:17:28 ipfire charon: 11[KNL] creating rekey job for CHILD_SA 
ESP/0xc68f239f/xxx.xxx.xxx.xxx

Dec 14 13:17:28 ipfire charon: 11[IKE] establishing CHILD_SA HudsonNew{38}
Dec 14 13:17:28 ipfire charon: 11[IKE] establishing CHILD_SA HudsonNew{38}
Dec 14 13:17:28 ipfire charon: 11[ENC] generating CREATE_CHILD_SA 
request 14 [ N(REKEY_SA) N(IPCOMP_SUP) SA No KE TSi TSr ]
Dec 14 13:17:28 ipfire charon: 11[NET] sending packet: from 
xxx.xxx.xxx.xxx[4500] to yyy.yyy.yyy.yyy[4500] (344 bytes)
Dec 14 13:17:28 ipfire charon: 05[NET] received packet: from 
yyy.yyy.yyy.yyy[4500] to xxx.xxx.xxx.xxx[4500] (444 bytes)
Dec 14 13:17:28 ipfire charon: 05[ENC] parsed CREATE_CHILD_SA request 10 
[ N(REKEY_SA) N(IPCOMP_SUP) SA No KE TSi TSr ]
Dec 14 13:17:28 ipfire charon: 05[IKE] CHILD_SA HudsonNew{10483} 
established with SPIs cc94730d_i c654401c_o and TS 10.100.0.0/23 === 
192.168.0.0/24
Dec 14 13:17:28 ipfire charon: 05[IKE] CHILD_SA HudsonNew{10483} 
established with SPIs cc94730d_i c654401c_o and TS 10.100.0.0/23 === 
192.168.0.0/24
Dec 14 13:17:28 ipfire charon: 05[IKE] detected CHILD_REKEY collision 
with CHILD_REKEY
Dec 14 13:17:28 ipfire charon: 05[ENC] generating CREATE_CHILD_SA 
response 10 [ N(IPCOMP_SUP) SA No KE TSi TSr ]
Dec 14 13:17:28 ipfire charon: 05[NET] sending packet: from 
xxx.xxx.xxx.xxx[4500] to yyy.yyy.yyy.yyy[4500] (332 bytes)
Dec 14 13:17:28 ipfire charon: 12[NET] received packet: from 
yyy.yyy.yyy.yyy[4500] to xxx.xxx.xxx.xxx[4500] (332 bytes)
Dec 14 13:17:28 ipfire charon: 12[ENC] parsed CREATE_CHILD_SA response 
14 [ N(IPCOMP_SUP) SA No KE TSi TSr ]
Dec 14 13:17:28 ipfire charon: 12[IKE] CHILD_SA HudsonNew{10482} 
established with SPIs cc4f7fb7_i ccc34f5a_o and TS 10.100.0.0/23 === 
192.168.0.0/24
Dec 14 13:17:28 ipfire charon: 12[IKE] CHILD_SA HudsonNew{10482} 
established with SPIs cc4f7fb7_i ccc34f5a_o and TS 10.100.0.0/23 === 
192.168.0.0/24
Dec 14 13:17:28 ipfire charon: 12[IKE] CHILD_SA rekey collision lost, 
deleting rekeyed child
Dec 14 13:17:29 ipfire charon: 12[IKE] closing CHILD_SA HudsonNew{10482} 
with SPIs cc4f7fb7_i (120 bytes) ccc34f5a_o (145 bytes) and TS 
10.100.0.0/23 === 192.168.0.0/24
Dec 14 13:17:29 ipfire charon: 12[IKE] closing CHILD_SA HudsonNew{10482} 
with SPIs cc4f7fb7_i (120 bytes) ccc34f5a_o (145 bytes) and TS 
10.100.0.0/23 === 192.168.0.0/24
Dec 14 13:17:29 ipfire charon: 12[IKE] sending DELETE for ESP CHILD_SA 
with SPI cc4f7fb7
Dec 14 13:17:29 ipfire charon: 12[ENC] generating INFORMATIONAL request 
15 [ D ]
Dec 14 13:17:29 ipfire charon: 12[NET] sending packet: from 
xxx.xxx.xxx.xxx[4500] to yyy.yyy.yyy.yyy[4500] (69 bytes)
Dec 14 13:17:29 ipfire charon: 06[NET] received packet: from 
yyy.yyy.yyy.yyy[4500] to xxx.xxx.xxx.xxx[4500] (69 bytes)

Dec 14 13:17:29 ipfire charon: 06[ENC] parsed INFORMATIONAL request 11 [ D ]
Dec 14 13:17:29 ipfire charon: 06[IKE] received DELETE for ESP CHILD_SA 
with SPI c46ba5ea
Dec 14 13:17:29 ipfire charon: 06[IKE] closing CHILD_SA HudsonNew{10381} 
with SPIs c68f239f_i (83067013 bytes) c46ba5ea_o (68814191 bytes) and TS 
10.100.0.0/23 === 192.168.0.0/24
Dec 14 13:17:29 ipfire charon: 06[IKE] closing CHILD_SA HudsonNew{10381} 
with SPIs c68f239f_i (83067013 bytes) c46ba5ea_o (68814191 bytes) and TS 
10.100.0.0/23 === 192.168.0.0/24
Dec 14 13:17:29 ipfire charon: 06[IKE] sending DELETE for ESP CHILD_SA 
with SPI c68f239f

Dec 14 13:17:29 ipfire charon: 06[IKE] CHILD_SA closed
Dec 14 13:17:29 ipfire charon: 06[IKE] detected CHILD_REKEY collision 
with CHILD_DELETE
Dec 14 13:17:29 ipfire charon: 06[ENC] generating INFORMATIONAL response 
11 [ D ]
Dec 14 13:17:29 ipfire charon: 06[NET] sending packet: from 
xxx.xxx.xxx.xxx[4500] to yyy.yyy.yyy.yyy[4500] (69 bytes)
Dec 14 13:17:29 ipfire charon: 15[NET] received packet: from 
yyy.yyy.yyy.yyy[4500] to xxx.xxx.xxx.xxx[4500] (69 bytes)
Dec 14 13:17:29 ipfire charon: 15[ENC] parsed INFORMATIONAL response 15 
[ D ]
Dec 14 13:17:29 ipfire charon: 15[IKE] 

Re: [strongSwan] Recommended Practice: Encryption options for net-to-net tunnels

[Tom Rymes]

On 12/10/2015 11:34 AM, Andreas Steffen wrote:

if you know the options on both sides then one set of options
is sufficient. If the connection setup works the first time
around then it will always work. If you are not sure what
the other side supports then you have to define several
options with the preferred option up front and the most common
option e.g. (aes128-sha1-modp2048) at the very end.


Thanks for confirming that, Andreas. My suspicion was that would be the 
case, but I wanted to confirm.

By the way

ike=aes256-sha2_256-ecp512bp

does not give you constant 256 bit security. The correct choice is

ike=aes256-sha512-ecp512bp!


Excellent, this is great information!

Thank you,

tom
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] Site-to-Site with Cisco devices

[Tom Rymes]

Before I start digging through the logs (more than I have already), I thought I 
would ask if there are some obvious recommended settings for connecting 
Strongswan to Cisco routers.

I am running Strongswan 5.3.2 as part of the IPfire distribution. This box 
hosts a dozen or so tunnels to other IPFire/Strongswan boxen, but each and 
every time I have attempted to create a tunnel to a Cisco Device (ATA or 
router), all of the existing tunnels drop and will not come back up. Sometimes 
restarting Strongswan will bring it all back up, but only for a short while, 
when all of the non-Cisco tunnels drop again.

I'm more than happy to start pulling configurations and logs, but before I do, 
I thought I would ask if anyone has already invented this wheel and/or gotten 
past this stumbling block, as I have yet to encounter anything in the archives 
or out there on the web.

Many thanks,

Tom


___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] Site-to-Site with Cisco devices

[Tom Rymes]

On Nov 28, 2015, at 1:58 PM, Noel Kuntze  wrote:
> Hello Tom,
> 
> Provide logs and configuration details, so we can aid you in debuggin it.
> We can't help you without detailed information.
> It's probably a configuration problem.

Thanks, Neil. For the record, I am using Cisco Configuration Professional 
Express 3.2, which is a web interface. I’m not certain that I will end up using 
that interface, but it’s what I am testing now. I did experience this issue 
before when trying to connect with a  Software vendor’s Cisco ASA.

OK, I have set up another test connection. One thing I noticed right away is 
that I can get the tunnel up, but I cannot get traffic to flow (that might be a 
firewall issue on the cisco end). However, “ipsec status” shows this. I have no 
idea why there are three child SAs after only two minutes:

   ciscotest[218]: ESTABLISHED 2 minutes ago, 
75.144.180.161[75.144.180.161]...70.90.104.189[70.90.104.189]
   ciscotest{972}:  INSTALLED, TUNNEL, reqid 57, ESP SPIs: cd9d4ba9_i 927d8324_o
   ciscotest{972}:   10.2.0.0/16 === 10.10.10.0/24 
   ciscotest{973}:  INSTALLED, TUNNEL, reqid 57, ESP SPIs: c54b639d_i ca4c6022_o
   ciscotest{973}:   10.2.0.0/16 === 10.10.10.0/24 
   ciscotest{974}:  INSTALLED, TUNNEL, reqid 57, ESP SPIs: c81b266c_i b563d7f6_o
   ciscotest{974}:   10.2.0.0/16 === 10.10.10.0/24 

The Strongswan config looks like this:

version 2

conn %default
keyingtries=%forever

include /etc/ipsec.user.conf

conn Data
left=ip.add.res.s1
leftsubnet=10.2.0.0/16
leftfirewall=yes
lefthostaccess=yes
right=ip.add.res.s2
rightsubnet=10.100.0.0/23
leftcert=/var/ipfire/certs/hostcert.pem
rightcert=/var/ipfire/certs/Datacert.pem
leftid="@lefthost"
rightid="@righthost"

ike=aes256-sha2_256-ecp512bp,aes256-sha2_256-ecp384bp,aes256-sha2_256-ecp256bp,aes256-sha2_256-ecp224bp,aes192-sha2_256-ecp512bp,aes192-sha2_256-ecp384bp,aes192-sha2_256-ecp256bp,aes192-sha2_256-ecp224bp,aes128-sha2_256-ecp512bp,aes128-sha2_256-ecp384bp,aes128-sha2_256-ecp256bp,aes128-sha2_256-ecp224bp

esp=aes256-sha2_256-ecp512bp,aes256-sha2_256-ecp384bp,aes256-sha2_256-ecp256bp,aes256-sha2_256-ecp224bp,aes192-sha2_256-ecp512bp,aes192-sha2_256-ecp384bp,aes192-sha2_256-ecp256bp,aes192-sha2_256-ecp224bp,aes128-sha2_256-ecp512bp,aes128-sha2_256-ecp384bp,aes128-sha2_256-ecp256bp,aes128-sha2_256-ecp224bp
keyexchange=ikev2
ikelifetime=8h
keylife=1h
compress=yes
dpdaction=restart
dpddelay=30
dpdtimeout=120
authby=rsasig
leftrsasigkey=%cert
rightrsasigkey=%cert
auto=start
fragmentation=yes

conn ciscotest
left=ip.add.res.s1
leftsubnet=10.2.0.0/16
leftfirewall=yes
lefthostaccess=yes
right=ip.add.res.s3
rightsubnet=10.10.10.0/24

ike=aes256-sha2_512-modp1536,aes256-sha2_512-modp1024,aes256-sha2_384-modp1536,aes256-sha2_384-modp1024,aes256-sha2_256-modp1536,aes256-sha2_256-modp1024,aes256-sha-modp1536,aes256-sha-modp1024,aes256-md5-modp1536,aes256-md5-modp1024,aes192-sha2_512-modp1536,aes192-sha2_512-modp1024,aes192-sha2_384-modp1536,aes192-sha2_384-modp1024,aes192-sha2_256-modp1536,aes192-sha2_256-modp1024,aes192-sha-modp1536,aes192-sha-modp1024,aes192-md5-modp1536,aes192-md5-modp1024,aes128-sha2_512-modp1536,aes128-sha2_512-modp1024,aes128-sha2_384-modp1536,aes128-sha2_384-modp1024,aes128-sha2_256-modp1536,aes128-sha2_256-modp1024,aes128-sha-modp1536,aes128-sha-modp1024,aes128-md5-modp1536,aes128-md5-modp1024

esp=aes256-sha2_512-modp1536,aes256-sha2_512-modp1024,aes256-sha2_384-modp1536,aes256-sha2_384-modp1024,aes256-sha2_256-modp1536,aes256-sha2_256-modp1024,aes256-sha1-modp1536,aes256-sha1-modp1024,aes256-md5-modp1536,aes256-md5-modp1024,aes192-sha2_512-modp1536,aes192-sha2_512-modp1024,aes192-sha2_384-modp1536,aes192-sha2_384-modp1024,aes192-sha2_256-modp1536,aes192-sha2_256-modp1024,aes192-sha1-modp1536,aes192-sha1-modp1024,aes192-md5-modp1536,aes192-md5-modp1024,aes128-sha2_512-modp1536,aes128-sha2_512-modp1024,aes128-sha2_384-modp1536,aes128-sha2_384-modp1024,aes128-sha2_256-modp1536,aes128-sha2_256-modp1024,aes128-sha1-modp1536,aes128-sha1-modp1024,aes128-md5-modp1536,aes128-md5-modp1024
keyexchange=ikev2
ikelifetime=3h
keylife=1h
compress=yes
dpdaction=restart
dpddelay=30
dpdtimeout=120
authby=secret
auto=start
fragmentation=yes

conn NumberThree
left=ip.add.res.s1
leftsubnet=10.2.0.0/16
leftfirewall=yes
lefthostaccess=yes
right=ip.add.res.s4
rightsubnet=192.168.0.0/21
leftcert=/var/ipfire/certs/hostcert.pem
rightcert=/var/ipfire/certs/NumberThreecert.pem
leftid="@lefthost"
rightid="@righthost2"

Re: [strongSwan] Site-to-Site with Cisco devices

[Tom Rymes]

On 11/28/2015 1:58 PM, Noel Kuntze wrote:

Hello Tom,

Provide logs and configuration details, so we can aid you in debuggin it.
We can't help you without detailed information.
It's probably a configuration problem.


More Details. As of now, after being up for a day or more, I see this on 
the Strongswan side when I run "ipsec status". I have no idea why this 
is happening:


   ciscotest[358]: ESTABLISHED 38 minutes ago, 
ip.add.res.s1[ip.add.res.s1]...ip.add.res.s3[ip.add.res.s3]
   ciscotest{3932}:  INSTALLED, TUNNEL, reqid 407, ESP SPIs: c267129c_i 
1bc4fd9a_o

   ciscotest{3932}:   10.2.0.0/16 === 10.10.10.0/24
   ciscotest{3933}:  INSTALLED, TUNNEL, reqid 407, ESP SPIs: c4fc1168_i 
9400905e_o

   ciscotest{3933}:   10.2.0.0/16 === 10.10.10.0/24
   ciscotest{3934}:  INSTALLED, TUNNEL, reqid 407, ESP SPIs: c2ee9da0_i 
7edc07df_o

   ciscotest{3934}:   10.2.0.0/16 === 10.10.10.0/24
   ciscotest{3935}:  INSTALLED, TUNNEL, reqid 407, ESP SPIs: c775189b_i 
64831fb4_o

   ciscotest{3935}:   10.2.0.0/16 === 10.10.10.0/24
   ciscotest{3936}:  INSTALLED, TUNNEL, reqid 407, ESP SPIs: c2eb6509_i 
de48e110_o

   ciscotest{3936}:   10.2.0.0/16 === 10.10.10.0/24
   ciscotest{3937}:  INSTALLED, TUNNEL, reqid 407, ESP SPIs: cc787253_i 
4f1657f7_o

   ciscotest{3937}:   10.2.0.0/16 === 10.10.10.0/24
   ciscotest{3938}:  INSTALLED, TUNNEL, reqid 407, ESP SPIs: cd8a5c29_i 
2f338750_o

   ciscotest{3938}:   10.2.0.0/16 === 10.10.10.0/24
   ciscotest{3939}:  INSTALLED, TUNNEL, reqid 407, ESP SPIs: c4e37b96_i 
3caf53fe_o

   ciscotest{3939}:   10.2.0.0/16 === 10.10.10.0/24
   ciscotest{3940}:  INSTALLED, TUNNEL, reqid 407, ESP SPIs: c3934011_i 
ce2d9312_o

   ciscotest{3940}:   10.2.0.0/16 === 10.10.10.0/24
   ciscotest{3941}:  INSTALLED, TUNNEL, reqid 407, ESP SPIs: c35d9bb7_i 
90d87dfb_o

   ciscotest{3941}:   10.2.0.0/16 === 10.10.10.0/24
   ciscotest{3942}:  INSTALLED, TUNNEL, reqid 407, ESP SPIs: c4d7fe2e_i 
0b7cdc00_o

   ciscotest{3942}:   10.2.0.0/16 === 10.10.10.0/24
   ciscotest{3943}:  INSTALLED, TUNNEL, reqid 407, ESP SPIs: c7237061_i 
58b215c4_o

   ciscotest{3943}:   10.2.0.0/16 === 10.10.10.0/24
   ciscotest{3944}:  INSTALLED, TUNNEL, reqid 407, ESP SPIs: c9be2814_i 
ab2f5baf_o

   ciscotest{3944}:   10.2.0.0/16 === 10.10.10.0/24
   ciscotest{3947}:  INSTALLED, TUNNEL, reqid 407, ESP SPIs: c7b4c6e2_i 
1513dc4c_o

   ciscotest{3947}:   10.2.0.0/16 === 10.10.10.0/24
   ciscotest{3948}:  INSTALLED, TUNNEL, reqid 407, ESP SPIs: c1c2dfe8_i 
2b09582d_o

   ciscotest{3948}:   10.2.0.0/16 === 10.10.10.0/24
   ciscotest{3949}:  INSTALLED, TUNNEL, reqid 407, ESP SPIs: c869b682_i 
3e2cf25d_o

   ciscotest{3949}:   10.2.0.0/16 === 10.10.10.0/24
   ciscotest{3950}:  INSTALLED, TUNNEL, reqid 407, ESP SPIs: cb694aed_i 
7db264a3_o

   ciscotest{3950}:   10.2.0.0/16 === 10.10.10.0/24
   ciscotest{3951}:  INSTALLED, TUNNEL, reqid 407, ESP SPIs: c0f6cef1_i 
eb1e174a_o

   ciscotest{3951}:   10.2.0.0/16 === 10.10.10.0/24
   ciscotest{3952}:  INSTALLED, TUNNEL, reqid 407, ESP SPIs: c923dbfd_i 
bc74fd0f_o

   ciscotest{3952}:   10.2.0.0/16 === 10.10.10.0/24
   ciscotest{3954}:  INSTALLED, TUNNEL, reqid 407, ESP SPIs: caa01d66_i 
281e628e_o

   ciscotest{3954}:   10.2.0.0/16 === 10.10.10.0/24
   ciscotest{3955}:  INSTALLED, TUNNEL, reqid 407, ESP SPIs: cb77f635_i 
3ec07814_o

   ciscotest{3955}:   10.2.0.0/16 === 10.10.10.0/24
   ciscotest{3956}:  INSTALLED, TUNNEL, reqid 407, ESP SPIs: ca8b1531_i 
d9e69808_o

   ciscotest{3956}:   10.2.0.0/16 === 10.10.10.0/24
   ciscotest{3957}:  INSTALLED, TUNNEL, reqid 407, ESP SPIs: c9140f78_i 
ded60b4a_o

   ciscotest{3957}:   10.2.0.0/16 === 10.10.10.0/24
   ciscotest{3958}:  INSTALLED, TUNNEL, reqid 407, ESP SPIs: c37f9503_i 
31523607_o

   ciscotest{3958}:   10.2.0.0/16 === 10.10.10.0/24
   ciscotest{3959}:  INSTALLED, TUNNEL, reqid 407, ESP SPIs: c19b89fd_i 
dccfc1e7_o

   ciscotest{3959}:   10.2.0.0/16 === 10.10.10.0/24
   ciscotest{3961}:  INSTALLED, TUNNEL, reqid 407, ESP SPIs: c8a07fb5_i 
0d5d6921_o

   ciscotest{3961}:   10.2.0.0/16 === 10.10.10.0/24
   ciscotest{3962}:  INSTALLED, TUNNEL, reqid 407, ESP SPIs: c0521841_i 
abbcaa1e_o

   ciscotest{3962}:   10.2.0.0/16 === 10.10.10.0/24
   ciscotest{3963}:  INSTALLED, TUNNEL, reqid 407, ESP SPIs: c3be5bec_i 
e475177f_o

   ciscotest{3963}:   10.2.0.0/16 === 10.10.10.0/24
   ciscotest{3964}:  INSTALLED, TUNNEL, reqid 407, ESP SPIs: cb25acdc_i 
f6140b10_o

   ciscotest{3964}:   10.2.0.0/16 === 10.10.10.0/24
   ciscotest{3965}:  INSTALLED, TUNNEL, reqid 407, ESP SPIs: cc72069a_i 
895cd152_o

   ciscotest{3965}:   10.2.0.0/16 === 10.10.10.0/24
   ciscotest{3966}:  INSTALLED, TUNNEL, reqid 407, ESP SPIs: c0fd40f2_i 
bd2e6d36_o

   ciscotest{3966}:   10.2.0.0/16 === 10.10.10.0/24
   ciscotest{3967}:  INSTALLED, TUNNEL, reqid 407, ESP SPIs: cdb408e0_i 
1df265b1_o

   ciscotest{3967}:   10.2.0.0/16 === 10.10.10.0/24
   ciscotest{3968}:  INSTALLED, TUNNEL, reqid 407, ESP SPIs: ccb13b81_i 
6338448c_o

   ciscotest{3968}:   10.2.0.0/16 === 

Re: [strongSwan] fail open mode for strongswan

[Tom Rymes]

You could try setting up IPSec for only a portion of the subnet, using the 
subnet mask to limit which hosts use IPSec. Change the hosts within that 
portion of the subnet, then change the mask to include more hosts, set them to 
use IPSec, and keep going until the entire subnet is swapped over. 

> On Feb 9, 2016, at 4:25 PM, Matthew Boedicker  wrote:
> 
> We want a policy which says try to use IPsec to all hosts in a subnet but 
> fall back to clear communication if the other host doesn't support IPsec.
> 
> This policy would be used to do a rolling deploy of strongSwan to an entire 
> subnet with zero downtime. The hosts that get strongSwan still need to be 
> able to talk to the hosts that have not been updated with strongSwan yet. 
> When all hosts have strongSwan, then the insecure "mixed" mode would be 
> turned off and IPsec would be required.
> 
> It sounds like this setting may not exist because this is an atypical use 
> case for strongSwan.
> 
> 
>> On Tue, Feb 9, 2016 at 11:52 AM, Andreas Steffen 
>>  wrote:
>> Hi Matthew,
>> 
>> actually the default policy settings of the Linux kernel will
>> transmit all communications not matched by an IPsec policy in the
>> clear.
>> 
>> Regards
>> 
>> Andreas
>> 
>> On 02/09/2016 07:23 PM, Matthew Boedicker wrote:
>> > Are there any configuration settings that can make strongswan "fail
>> > open" when in host-to-host transport mode? It would try to negotiate an
>> > encrypted connection but fall back to communicating in the clear if the
>> > encryption failed for some reason.
>> >
>> > Thanks.
>> >
>> 
>> ==
>> Andreas Steffen andreas.stef...@strongswan.org
>> strongSwan - the Open Source VPN Solution!  www.strongswan.org
>> Institute for Internet Technologies and Applications
>> University of Applied Sciences Rapperswil
>> CH-8640 Rapperswil (Switzerland)
>> ===[ITA-HSR]==
> 
> ___
> Users mailing list
> Users@lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] Multiple SAs immediately after connection

[Tom Rymes]

I have occasionally seen this over the years, and I am not certain if it’s 
anything I should be concerned about. If I start a tunnel named mytunnel, this 
is what it looks like on the CLI:

[root@mainoffice ~]# ipsec up mytunnel
received packet: from XXX.XXX.XXX.XXX[4500] to YYY.YYY.YYY.YYY[4500] (532 bytes)
parsed IKE_AUTH response 1 [ EF(1/4) ]
received fragment #1 of 4, waiting for complete IKE message
received packet: from XXX.XXX.XXX.XXX[4500] to YYY.YYY.YYY.YYY[4500] (532 bytes)
parsed IKE_AUTH response 1 [ EF(2/4) ]
received fragment #2 of 4, waiting for complete IKE message
received packet: from XXX.XXX.XXX.XXX[4500] to YYY.YYY.YYY.YYY[4500] (532 bytes)
parsed IKE_AUTH response 1 [ EF(3/4) ]
received fragment #3 of 4, waiting for complete IKE message
received packet: from XXX.XXX.XXX.XXX[4500] to YYY.YYY.YYY.YYY[4500] (212 bytes)
parsed IKE_AUTH response 1 [ EF(4/4) ]
received fragment #4 of 4, reassembling fragmented IKE message
parsed IKE_AUTH response 1 [ IDr CERT AUTH N(IPCOMP_SUP) SA TSi TSr N(AUTH_LFT) 
N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) ]
received end entity cert "C=US, ST=NH, O=MyCompany, OU=Engineering Dept, 
CN=remoteoffice.mycompany.com"
  using trusted ca certificate "C=US, ST=NH, L=mytunnel, O=MyCompany, 
OU=Engineering Dept, CN=MyCompany CA, E=t...@mycompany.com"
checking certificate status of "C=US, ST=NH, O=MyCompany, OU=Engineering Dept, 
CN=remoteoffice.mycompany.com"
certificate status is not available
  reached self-signed root ca with a path length of 0
  using trusted certificate "C=US, ST=NH, O=MyCompany, OU=Engineering Dept, 
CN=remoteoffice.mycompany.com"
authentication of 'C=US, ST=NH, O=MyCompany, OU=Engineering Dept, 
CN=remoteoffice.mycompany.com' with RSA_EMSA_PKCS1_SHA256 successful
IKE_SA mytunnel[248] established between YYY.YYY.YYY.YYY[C=US, ST=NH, 
O=MyCompany, OU=Engineering Dept., 
CN=mainoffice.mycompany.com]...XXX.XXX.XXX.XXX[C=US, ST=NH, O=MyCompany, 
OU=Engineering Dept, CN=remoteoffice.mycompany.com]
scheduling reauthentication in 27760s
maximum IKE_SA lifetime 28300s
CHILD_SA mytunnel{6530} established with SPIs c810ef9a_i cbe44831_o and TS 
10.100.0.0/23 === 10.8.0.0/23
connection 'mytunnel' established successfully

Then, if I look at the status output for that tunnel, I see two “INSTALLED” 
entries, even though the tunnel has only been established for 5 seconds. My 
understanding was that I should only have a new entry show up as “INSTALLED” 
every time the phase 2 settings are re-keyed, which is every one hour.
 
[root@mainoffice ~]# ipsec status mytunnel
Routed Connections:
 mytunnel{6454}:  ROUTED, TUNNEL, reqid 181
 mytunnel{6454}:   10.100.0.0/23 === 10.8.0.0/23
Security Associations (25 up, 0 connecting):
 mytunnel[248]: ESTABLISHED 5 seconds ago, YYY.YYY.YYY.YYY[C=US, ST=NH, 
O=MyCompany, OU=Engineering Dept., 
CN=mainoffice.mycompany.com]...XXX.XXX.XXX.XXX[C=US, ST=NH, O=MyCompany, 
OU=Engineering Dept, CN=remoteoffice.mycompany.com]
 mytunnel{6530}:  INSTALLED, TUNNEL, reqid 181, ESP SPIs: c810ef9a_i 
cbe44831_o, IPCOMP CPIs: 0ff7_i 4f82_o
 mytunnel{6530}:   10.100.0.0/23 === 10.8.0.0/23
 mytunnel{6531}:  INSTALLED, TUNNEL, reqid 181, ESP SPIs: c9c5f628_i 
c768a908_o, IPCOMP CPIs: d873_i 177f_o
 mytunnel{6531}:   10.100.0.0/23 === 10.8.0.0/23

This is the entry for this tunnel in ipsec.conf:

conn mytunnel
left=YYY.YYY.YYY.YYY
leftsubnet=10.100.0.0/23
leftfirewall=yes
lefthostaccess=yes
right=XXX.XXX.XXX.XXX
rightsubnet=10.8.0.0/23
leftcert=/var/ipfire/certs/hostcert.pem
rightcert=/var/ipfire/certs/remoteofficecert.pem
leftid="@mainoffice.mycompany.com"
rightid="@remoteoffice.mycompany.com"
ike=aes256-sha2_512-ecp512bp!
esp=aes256-sha2_512-ecp512bp!
keyexchange=ikev2
ikelifetime=8h
keylife=1h
compress=yes
dpdaction=clear
dpddelay=30
dpdtimeout=120
authby=rsasig
leftrsasigkey=%cert
rightrsasigkey=%cert
auto=route
fragmentation=yes

I don’t know if this is something I should be concerned about, or if it’s 
nothing to worry about , but I wanted to reach out and ask.

Tom
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

Re: [strongSwan] strongswan not reloading/updating configs

[Tom Rymes]

Henry,



Have you tried "ipsec rereadall"?



Tom



From: Users [mailto:users-boun...@lists.strongswan.org] On Behalf Of Henry 
Griffiths
Sent: Friday, January 13, 2017 2:58 AM
To: users@lists.strongswan.org
Subject: [strongSwan] strongswan not reloading/updating configs



Hello!

I have issue with strongswan, when I try to reload configurations, it does not 
update the configurations. When I add a new config, it does not add that 
config. I do not want to restart all connections, because I have connections 
running 24/7. What can I do to fix this?



Best regards, Henry Griffiths



___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] L2TP/IPSec Passthrough - Interfaces?

[Tom Rymes]

We are running StrongSWAN as part of an IPFire router distribution. 
Strongswan handles multiple tunnels via the WAN interface, and that 
interface has multiple public IPs associated with it.


We are also trying to pass L2TP/IPSec through the router to a Windows 
RRAS server for the purpose of establishing roadwarrior-type VPN 
connections to one of the other IP Addresses.


Currently, this is not working, and it seems that it is because 
StrongSwan is trying to handle the IPSec traffic, instead of passing it 
through to the windows server.


After digging through the docs a little, it looks to me that we need to 
specify the "charon.interfaces_use" directive in the configuration to 
limit StrongSwan to only one of the configured IP Addresses.


Does that make sense?

Tom

Re: [strongSwan] High latency (satellite) link : what can we improve ?

[Tom Rymes]

On Oct 24, 2017, at 11:53 AM, Hoggins!  wrote:
> 
> Hello,
> 
> We sometimes use a satellite link for one of our site2sites tunnels, and
> there are times when the tunnel simply stops working. Maybe we don't
> wait enough for it to respawn by itself, but then we just restart the
> StrongSwan daemon manually and we're good to go for another couple of hours.

Are you using auto=route or auto=start?

Tom

Re: [strongSwan] High latency (satellite) link : what can we improve ?

[Tom Rymes]

I would recommend that you try auto=route. My experience suggests that it 
significantly improves the re-establishment of tunnels if they drop due to bad 
links. I think that the documentation also recommends this, but I can't seem to 
find that right now.

Tom

> On Oct 25, 2017, at 4:41 AM, Hoggins! <hogg...@radiom.fr> wrote:
> 
>> Le 24/10/2017 à 18:52, Tom Rymes a écrit :
>>> On Oct 24, 2017, at 11:53 AM, Hoggins! <hogg...@radiom.fr> wrote:
>>> Hello,
>>> 
>>> We sometimes use a satellite link for one of our site2sites tunnels, and
>>> there are times when the tunnel simply stops working. Maybe we don't
>>> wait enough for it to respawn by itself, but then we just restart the
>>> StrongSwan daemon manually and we're good to go for another couple of hours.
>> Are you using auto=route or auto=start?
>> 
>> Tom
>> 
> Hello Tom,
> 
> Our settings are on auto=start.
> 
> Hoggins!
> 

Re: [strongSwan] DHCP!

[Tom Rymes]

On 05/04/2018 3:45 AM, Christian Salway wrote:
Thanks to Dirk Hartmann and his scripting idea,  The simplest way to add 
a VPN connection to Windows 10 that includes the routing to the internal 
IP, is by running the following commands in PowerShell commands.  This 
also enables strong ciphers (MODP2048)


/This is for a username/password VPN available to all users (remove 
-*AllUserConnection* from the /*Add-VpnConnection*/ command for just the 
current user)/


Apple configuration profiles and Windows scripting are definitely magic 
when done right.


The gold standard in my experience is Algo 
(https://blog.trailofbits.com/2016/12/12/meet-algo-the-vpn-that-works/), 
which is built on top of StrongSwan:


- Airdrop a file to an iOS device and you're configured.
- Double-click a file on a mac, and you're configured.
- Run a powershell script on Windows and you're configured.

It's pretty darned cool, to be honest.

Re: [strongSwan] DHCP!

[Tom Rymes]

It's designed for a very specific use case, but if you install it in a 
sandbox somewhere, you can get a feel for the powershell scripts and 
other bits that are used to configure the clients.


It's all wrapped around Strongswan, so you can transfer the 
functionality to your own setup, if you find it helpful.


Tom

On 05/04/2018 9:15 AM, Christian Salway wrote:

We are working with very locked down systems so wouldn’t be able to install 
that software unfortunately but will have a look out of interest,
Thanks


On 4 May 2018, at 13:15, Tom Rymes <try...@rymes.com> wrote:


On 05/04/2018 3:45 AM, Christian Salway wrote:
Thanks to Dirk Hartmann and his scripting idea,  The simplest way to add a VPN 
connection to Windows 10 that includes the routing to the internal IP, is by 
running the following commands in PowerShell commands.  This also enables 
strong ciphers (MODP2048)
/This is for a username/password VPN available to all users (remove 
-*AllUserConnection* from the /*Add-VpnConnection*/ command for just the 
current user)/


Apple configuration profiles and Windows scripting are definitely magic when 
done right.

The gold standard in my experience is Algo 
(https://blog.trailofbits.com/2016/12/12/meet-algo-the-vpn-that-works/), which 
is built on top of StrongSwan:

- Airdrop a file to an iOS device and you're configured.
- Double-click a file on a mac, and you're configured.
- Run a powershell script on Windows and you're configured.

It's pretty darned cool, to be honest.

Re: [strongSwan] High latency (satellite) link : what can we improve ?

[Tom Rymes]

Odd, it works fine for us. The tunnel is set up as routed, and once traffic 
destined for the other side of the tunnel shows up, the connection is 
established and all is well.

You've reached the limit of my abilities, hopefully someone else can help.

> On Oct 26, 2017, at 5:14 AM, Hoggins!  wrote:
> 
> [...] Connection is *not* automatically established when needed [...]
> 
>> Le 26/10/2017 à 10:31, Hoggins! a écrit :
>> With this in place, strongswan statusall shows that there are policies
>> loaded, but connection is automatically established when needed,
>> although I thought this would be the case.
> 
> 

[strongSwan] Challenges with MacOS Roadwarrior

[Tom Rymes]

I have spent a fair amount of time lurking and searching for the answers 
to this, and I am fairly certain that I have overlooked something basic, 
such as putting the right data in the proper SAN. Unfortunately, the 
learning curve here seems to be quite steep, and I am not keeping up.


Regardless, I cannot get a working RW connection to a MacOS client using 
machine certs. Windows 10 works just fine.


I have tried various combinations of leftid and rightid, along with 
adding different things to the SAN field of the responder's cert, but 
nothing so far has done the trick.


I did notice lines similar to these when trying various different rightids:

"id '%any' not confirmed by certificate, defaulting to 'C=US, ST=ST, 
O=MyOrg, OU=Engineering Dept., CN=RW'"


Can someone please (gently) point out the dumb mistake I have been making?

The error indicates that StrongSwan (5.6.1) cannot find a valid peer 
config, which is why I have been trying to fiddle with the left/rightid 
and the cert SANs.


Many thanks,

Tom

PS: I am attempting to make this work using the built-in VPN client on 
MacOS 10.11 - without importing a special configuration file, just using 
System Preferences.


Error:
Jan 25 14:48:06 myhost charon: 09[NET] received packet: from 
x.x.x.x[500] to y.y.y.y[500] (604 bytes)
Jan 25 14:48:06 myhost charon: 09[ENC] parsed IKE_SA_INIT request 0 [ SA 
KE No N(REDIR_SUP) N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ]

Jan 25 14:48:06 myhost charon: 09[IKE] x.x.x.x is initiating an IKE_SA
Jan 25 14:48:06 myhost charon: 09[IKE] x.x.x.x is initiating an IKE_SA
Jan 25 14:48:06 myhost charon: 09[IKE] remote host is behind NAT
Jan 25 14:48:06 myhost charon: 09[IKE] sending cert request for "C=US, 
ST=ST, L=TownA, O=MyOrg, OU=Engineering Dept., CN=MyOrg CA, E=m...@domain.dom"
Jan 25 14:48:06 myhost charon: 09[IKE] sending cert request for "C=US, 
ST=ST, L=TownB, O=MyOrg, OU=Engineering Dept., CN=MyOrg CA, E=m...@domain.dom"
Jan 25 14:48:06 myhost charon: 09[ENC] generating IKE_SA_INIT response 0 
[ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) N(MULT_AUTH) ]
Jan 25 14:48:06 myhost charon: 09[NET] sending packet: from y.y.y.y[500] 
to x.x.x.x[500] (493 bytes)
Jan 25 14:48:06 myhost charon: 11[NET] received packet: from 
x.x.x.x[4500] to y.y.y.y[4500] (512 bytes)

Jan 25 14:48:06 myhost charon: 11[ENC] unknown attribute type (25)
Jan 25 14:48:06 myhost charon: 11[ENC] parsed IKE_AUTH request 1 [ IDi 
N(INIT_CONTACT) N(MOBIKE_SUP) IDr CPRQ(ADDR DHCP DNS MASK ADDR6 DHCP6 
DNS6 (25)) N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) SA TSi TSr ]
Jan 25 14:48:06 myhost charon: 11[CFG] looking for peer configs matching 
y.y.y.y[@myhost.domain.dom]...x.x.x.x[m...@domain.dom]

Jan 25 14:48:06 myhost charon: 11[CFG] no matching peer config found
Jan 25 14:48:06 myhost charon: 11[IKE] received 
ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding

Jan 25 14:48:06 myhost charon: 11[IKE] peer supports MOBIKE
Jan 25 14:48:06 myhost charon: 11[ENC] generating IKE_AUTH response 1 [ 
N(AUTH_FAILED) ]
Jan 25 14:48:06 myhost charon: 11[NET] sending packet: from 
y.y.y.y[4500] to x.x.x.x[4500] (80 bytes)


Config:

version 2

conn %default
keyingtries=%forever

include /etc/ipsec.user.conf

conn RW2
left=y.y.y.y
leftsubnet=0.0.0.0/0
leftsendcert=always
leftallowany=yes
rekey=no
leftfirewall=yes
lefthostaccess=yes
right=%any
leftcert=/var/ipfire/certs/hostcert.pem
rightcert=/var/ipfire/certs/RW2cert.pem

ike=aes256-sha2_256-modp1024,aes192-sha2_256-modp1024,aes128-sha2_256-modp1024

esp=aes256-sha2_256-modp1024,aes192-sha2_256-modp1024,aes128-sha2_256-modp1024
keyexchange=ikev2
ikelifetime=3h
keylife=1h
dpdaction=clear
dpddelay=30
dpdtimeout=90
authby=rsasig
leftrsasigkey=%cert
rightrsasigkey=%cert
auto=add
rightsourceip=10.100.2.200/21
fragmentation=yes

StrongSwan's Cert:

Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, ST=ST, L=TownB, O=MyOrg, OU=Engineering Dept., 
CN=MyOrg CA/emailAddress=m...@domain.dom

Validity
Not Before: Jan 25 18:19:07 2018 GMT
Not After : Dec 22 18:19:07 4755 GMT
Subject: C=US, ST=ST, O=MyOrg, OU=Engineering Dept., 
CN=myhost.domain.dom

Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:

Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
3D:37:14:B8:B4:6A:AD:44:D2:C2:66:BE:10:6B:99:E1:95:29:CD:9D
X509v3 Authority Key Identifier:

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

[Tom Rymes]

Martin,

I can't help with the more technical portions of your query, but I can confirm 
that using auto=route has proven to be more reliable than auto=start, as a 
dropped tunnel seems more likely to be brought back up automatically.

I had asked specifically about that setting a few years ago, and this is the 
advice I received:

https://lists.strongswan.org/pipermail/users/2015-July/008552.html

Tom

> On Mar 7, 2018, at 1:53 AM, Martijn Grendelman  
> wrote:
> 
> Hi,
> 
> I have been running StrongSwan on Debian Wheezy (with StrongSwan 4.5.2)
> for a long time. We have about 70 ESP tunnels with 19 different
> endpoints, most of them IKEv1. The setup has been rock solid for years,
> with tunnel outages being extremely rare, and almost always the remote
> side's fault.
> 
> 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, or they disappear after some time. I haven't
> really discovered a pattern, and I'm a bit overwhelmed by Charon's
> logging output at higher levels. The problems are restricted to IKEv1
> connections, IKEv2 connections seem unaffected. There don't seem to be
> any issues establishing IKE SAs.
> 
> Since I didn't make any changes to the configuration in the course of
> the upgrade, I can imagine that my config is not up to the standards of
> version 5. I pasted relevant parts of my config below. Are there things
> that can be improved?
> 
> I am sorry I can't be more concrete. I am mostly looking for pointers on
> how to solve the issues.
> 
> If I want to know why a CHILD_SA is not established, what logging
> settings should I use? I'd like some pointers to what kind of messages
> to look for, and at what level from which subsystem they would be
> logged. Currently, I have this:
> 
> /var/log/charon.log {
> time_format = %b %e %T
> ike_name = yes
> append = yes
> default = 1
> cfg = 4
> net = 0
> flush_line = yes
> }
> 
> The problem is, that with 70 tunnels, raising the default log level
> higher than 1 leads to A LOT of logging (GBs / day) which quickly
> becomes hard to digest.
> 
> Here are my 'default' config and some config samples for connections
> that suffer from these problems. The example describes two tunnels to
> the same endpoint. Only 'leftsubnet' differs. In total, there are 16
> tunnels to this endpoint, all sharing the same IKE SA. They only differ
> in left- and rightsubnet. Does this make sense?
> 
> conn %default
> ikelifetime=8h
> keylife=1h
> rekeymargin=9m
> authby=secret
> keyexchange=ikev2
> mobike=no
> auto=start
> leftfirewall=no
> lefthostaccess=no
> closeaction=restart
> dpdaction=restart
> keyingtries=%forever
> 
> conn hq_uk_b4a
> left=
> leftsubnet=172.17.1.0/24
> right=
> rightsubnet=10.53.13.0/24
> ike=aes256-sha1-modp1024
> esp=aes256-sha1-modp1024
> keyexchange=ikev1
> ikelifetime=8h
> 
> conn hq_uk_b4b
> left=
> leftsubnet=172.17.5.0/24
> right=
> rightsubnet=10.53.13.0/24
> ike=aes256-sha1-modp1024
> esp=aes256-sha1-modp1024
> keyexchange=ikev1
> ikelifetime=8h
> 
> Hoping for some useful pointers...
> 
> Best regards,
> Martijn Grendelman.
> 

[strongSwan] Challenges with MacOS Roadwarrior (again)

[Tom Rymes]

My apologies for having to ask about this again, but I am stuck trying to make 
a MacOS IPSec connection to Strongswan. I had similar issues in the past, and 
Noel kindly helped me out, and I thought I had it all documented, but here I am 
again. Once again, Strongswan is reporting that it cannot find a matching peer 
config.

Noel’s response to my last post: 
https://lists.strongswan.org/pipermail/users/2018-January/012155.html 


Once again, I’m sure this is me doing something dumb here, but I cannot figure 
out what it is.

[root@MyHost ~]# ipsec --version
Linux strongSwan U5.6.3/K4.14.72-ipfire

conn MacIPSec
left=x.x.x.x
leftsubnet=0.0.0.0/0
right=%any
leftcert=/var/ipfire/certs/hostcert.pem
rightcert=/var/ipfire/certs/MacIPSeccert.pem
leftid=myhost.mydom.dom
rightid=u...@mydom.dom 

ike=aes256-sha2_384-ecp384,aes256-sha2_384-ecp256,aes256-sha2_256-ecp384,aes256-sha2_256-ecp256!

esp=aes256-sha2_384-ecp384,aes256-sha2_384-ecp256,aes256-sha2_256-ecp384,aes256-sha2_256-ecp256!
keyexchange=ikev2
ikelifetime=3h
keylife=1h
dpdaction=clear
dpddelay=30
dpdtimeout=120
auto=add
rightsourceip=10.252.0.240/28
fragmentation=yes
leftsendcert=always
leftallowany=yes
rightdns=10.252.0.1
rekey=no
reauth=no

When starting Strongswan, these messages are logged:

Dec  9 09:47:30 MyHost charon: 06[CFG]   id ‘myhost.mydom.dom' not confirmed by 
certificate, defaulting to 'C=US, ST=ST, O=MyOrg, OU=My Dept., 
CN=myhost.mydom.dom' 
Dec  9 09:47:30 TheShack charon: 06[CFG]   id ‘u...@mydom.dom 
' not confirmed by certificate, defaulting to 'C=US, 
ST=ST, O=MyOrg, OU=My Dept., CN=MacIPSec' 


And this hits the logs when I try to connect: 

Dec  9 09:47:50 MyHost charon: 16[NET] received packet: from y.y.y.y[500] to 
x.x.x.x[500] (604 bytes) 
Dec  9 09:47:50 MyHost charon: 16[ENC] parsed IKE_SA_INIT request 0 [ SA KE No 
N(REDIR_SUP) N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ] 
Dec  9 09:47:50 MyHost charon: 16[IKE] y.y.y.y is initiating an IKE_SA 
Dec  9 09:47:50 MyHost charon: 16[IKE] y.y.y.y is initiating an IKE_SA 
Dec  9 09:47:50 MyHost charon: 16[IKE] remote host is behind NAT 
Dec  9 09:47:50 MyHost charon: 16[IKE] DH group MODP_2048 inacceptable, 
requesting ECP_256 
Dec  9 09:47:50 MyHost charon: 16[ENC] generating IKE_SA_INIT response 0 [ 
N(INVAL_KE) ] 
Dec  9 09:47:50 MyHost charon: 16[NET] sending packet: from x.x.x.x[500] to 
y.y.y.y[500] (38 bytes) 
Dec  9 09:47:50 MyHost charon: 06[NET] received packet: from y.y.y.y[500] to 
x.x.x.x[500] (412 bytes) 
Dec  9 09:47:50 MyHost charon: 06[ENC] parsed IKE_SA_INIT request 0 [ SA KE No 
N(REDIR_SUP) N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ] 
Dec  9 09:47:50 MyHost charon: 06[IKE] y.y.y.y is initiating an IKE_SA 
Dec  9 09:47:50 MyHost charon: 06[IKE] y.y.y.y is initiating an IKE_SA 
Dec  9 09:47:50 MyHost charon: 06[IKE] remote host is behind NAT 
Dec  9 09:47:50 MyHost charon: 06[IKE] sending cert request for "C=US, ST=ST, 
L=MyTown, O=MyOrg, OU=My Dept., CN=MyOrg CA, E=u...@mydom.dom 
" 
Dec  9 09:47:50 MyHost charon: 06[IKE] sending cert request for "C=US, ST=ST, 
L=MyTown, O=MyOrg, OU=My Dept, CN=MyOrg CA, E=u...@mydom.dom 
" 
Dec  9 09:47:50 MyHost charon: 06[IKE] sending cert request for "C=US, ST=ST, 
L=OtherTown, O=MyOrg, OU=My Dept., CN=MyOrg CA, E=u...@mydom.dom 
" 
Dec  9 09:47:50 MyHost charon: 06[IKE] sending cert request for "C=US, ST=ST, 
L=OtherTown2, O=MyOrg, OU=My Dept, CN=MyOrg CA, E=u...@mydom.dom 
" 
Dec  9 09:47:50 MyHost charon: 06[ENC] generating IKE_SA_INIT response 0 [ SA 
KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) N(MULT_AUTH) ] 
Dec  9 09:47:50 MyHost charon: 06[NET] sending packet: from x.x.x.x[500] to 
y.y.y.y[500] (341 bytes) 
Dec  9 09:47:50 MyHost charon: 05[NET] received packet: from y.y.y.y[4500] to 
x.x.x.x[4500] (532 bytes) 
Dec  9 09:47:50 MyHost charon: 05[ENC] parsed IKE_AUTH request 1 [ EF(1/5) ] 
Dec  9 09:47:50 MyHost charon: 05[ENC] received fragment #1 of 5, waiting for 
complete IKE message 
Dec  9 09:47:50 MyHost charon: 08[NET] received packet: from y.y.y.y[4500] to 
x.x.x.x[4500] (532 bytes) 
Dec  9 09:47:50 MyHost charon: 08[ENC] parsed IKE_AUTH request 1 [ EF(2/5) ] 
Dec  9 09:47:50 MyHost charon: 08[ENC] received fragment #2 of 5, waiting for 
complete IKE message 
Dec  9 09:47:50 MyHost charon: 07[NET] received packet: from y.y.y.y[4500] to 
x.x.x.x[4500] (532 bytes) 
Dec  9 09:47:50 MyHost charon: 07[ENC] parsed IKE_AUTH request 1 [ EF(3/5) ] 
Dec  9 09:47:50 MyHost charon: 07[ENC] received fragment #3 of 5, waiting for 
complete IKE message 
Dec  9 09:47:50 MyHost charon: 09[NET] received packet: from 

Re: [strongSwan] Challenges with MacOS Roadwarrior (again)

[Tom Rymes]

I’m replying to my own e-mail here, but with help from Benn of PiStrong fame, I 
was able to figure out what I had omitted from my configuration: It was the 
Subject Alt Names in the certificates.

Specifically, I read Noel’s note to remove the SAN for the IP Address from the 
cert and unwisely left out all SANs. In the end, adding “DNS:myhost.mydom.dom” 
to the server’s certificate and “email:u...@mydom.dom” to the Mac’s certificate 
solved the issue.

Thank you for your patience and my apologies for the wasted bandwidth.

Tom

> On Dec 9, 2018, at 10:12 AM, Tom Rymes  wrote:
> 
> My apologies for having to ask about this again, but I am stuck trying to 
> make a MacOS IPSec connection to Strongswan. I had similar issues in the 
> past, and Noel kindly helped me out, and I thought I had it all documented, 
> but here I am again. Once again, Strongswan is reporting that it cannot find 
> a matching peer config.
> 
> Noel’s response to my last post: 
> https://lists.strongswan.org/pipermail/users/2018-January/012155.html 
> <https://lists.strongswan.org/pipermail/users/2018-January/012155.html>
> 
> Once again, I’m sure this is me doing something dumb here, but I cannot 
> figure out what it is.
> 
> [root@MyHost ~]# ipsec --version
> Linux strongSwan U5.6.3/K4.14.72-ipfire
> 
> conn MacIPSec
>   left=x.x.x.x
>   leftsubnet=0.0.0.0/0
>   right=%any
>   leftcert=/var/ipfire/certs/hostcert.pem
>   rightcert=/var/ipfire/certs/MacIPSeccert.pem
>   leftid=myhost.mydom.dom
>   rightid=u...@mydom.dom <mailto:rightid=u...@mydom.dom>
>   
> ike=aes256-sha2_384-ecp384,aes256-sha2_384-ecp256,aes256-sha2_256-ecp384,aes256-sha2_256-ecp256!
>   
> esp=aes256-sha2_384-ecp384,aes256-sha2_384-ecp256,aes256-sha2_256-ecp384,aes256-sha2_256-ecp256!
>   keyexchange=ikev2
>   ikelifetime=3h
>   keylife=1h
>   dpdaction=clear
>   dpddelay=30
>   dpdtimeout=120
>   auto=add
>   rightsourceip=10.252.0.240/28
>   fragmentation=yes
>   leftsendcert=always
>   leftallowany=yes
>   rightdns=10.252.0.1
>   rekey=no
>   reauth=no
> 
> When starting Strongswan, these messages are logged:
> 
> Dec  9 09:47:30 MyHost charon: 06[CFG]   id ‘myhost.mydom.dom' not confirmed 
> by certificate, defaulting to 'C=US, ST=ST, O=MyOrg, OU=My Dept., 
> CN=myhost.mydom.dom' 
> Dec  9 09:47:30 TheShack charon: 06[CFG]   id ‘u...@mydom.dom 
> <mailto:u...@mydom.dom>' not confirmed by certificate, defaulting to 'C=US, 
> ST=ST, O=MyOrg, OU=My Dept., CN=MacIPSec' 
> 
> 
> And this hits the logs when I try to connect: 
> 
> Dec  9 09:47:50 MyHost charon: 16[NET] received packet: from y.y.y.y[500] to 
> x.x.x.x[500] (604 bytes) 
> Dec  9 09:47:50 MyHost charon: 16[ENC] parsed IKE_SA_INIT request 0 [ SA KE 
> No N(REDIR_SUP) N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ] 
> Dec  9 09:47:50 MyHost charon: 16[IKE] y.y.y.y is initiating an IKE_SA 
> Dec  9 09:47:50 MyHost charon: 16[IKE] y.y.y.y is initiating an IKE_SA 
> Dec  9 09:47:50 MyHost charon: 16[IKE] remote host is behind NAT 
> Dec  9 09:47:50 MyHost charon: 16[IKE] DH group MODP_2048 inacceptable, 
> requesting ECP_256 
> Dec  9 09:47:50 MyHost charon: 16[ENC] generating IKE_SA_INIT response 0 [ 
> N(INVAL_KE) ] 
> Dec  9 09:47:50 MyHost charon: 16[NET] sending packet: from x.x.x.x[500] to 
> y.y.y.y[500] (38 bytes) 
> Dec  9 09:47:50 MyHost charon: 06[NET] received packet: from y.y.y.y[500] to 
> x.x.x.x[500] (412 bytes) 
> Dec  9 09:47:50 MyHost charon: 06[ENC] parsed IKE_SA_INIT request 0 [ SA KE 
> No N(REDIR_SUP) N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ] 
> Dec  9 09:47:50 MyHost charon: 06[IKE] y.y.y.y is initiating an IKE_SA 
> Dec  9 09:47:50 MyHost charon: 06[IKE] y.y.y.y is initiating an IKE_SA 
> Dec  9 09:47:50 MyHost charon: 06[IKE] remote host is behind NAT 
> Dec  9 09:47:50 MyHost charon: 06[IKE] sending cert request for "C=US, ST=ST, 
> L=MyTown, O=MyOrg, OU=My Dept., CN=MyOrg CA, E=u...@mydom.dom 
> <mailto:E=u...@mydom.dom>" 
> Dec  9 09:47:50 MyHost charon: 06[IKE] sending cert request for "C=US, ST=ST, 
> L=MyTown, O=MyOrg, OU=My Dept, CN=MyOrg CA, E=u...@mydom.dom 
> <mailto:E=u...@mydom.dom>" 
> Dec  9 09:47:50 MyHost charon: 06[IKE] sending cert request for "C=US, ST=ST, 
> L=OtherTown, O=MyOrg, OU=My Dept., CN=MyOrg CA, E=u...@mydom.dom 
> <mailto:E=u...@mydom.dom>" 
> Dec  9 09:47:50 MyHost charon: 06[IKE] sending cert request for "C=US, ST=ST, 
> L=OtherTown2, O=MyOrg, OU=My Dept, CN=MyOrg CA, E=u...@mydom.dom 
> <mailto:E=u...@mydom.dom>" 
> Dec  9 09:47:50 MyHost charon: 06[ENC] generating IKE_SA_INIT response 0 [ SA 
> KE No N(NATD_S_IP) N(

Re: [strongSwan] Strongswan on Ubuntu - Failure to connect from Windows 10 client -error: deleting half open IKE_SA with 154.**.***.** after timeout

[Tom Rymes]

Moses,

While I cannot speak to your specific issue here, you should likely look into 
using PowerShell to modify the Windows VPN parameters to use more robust 
encryption, as it provides many more options:

https://docs.microsoft.com/en-us/powershell/module/vpnclient/set-vpnconnectionipsecconfiguration?view=win10-ps

Tom

> On Feb 18, 2019, at 6:43 PM, MOSES KARIUKI  wrote:
> 
> Dear Team,
> 
> I have been having long days trying to configure Strongswan on Ubuntu 18.04. 
> I am not able to connect to the VPN from Windows 10 client, after following 
> the instructions on this link : 
> https://www.digitalocean.com/community/tutorials/how-to-set-up-an-ikev2-vpn-server-with-strongswan-on-ubuntu-18-04-2
> and setting up windows for modp_2048 following these instructions here :
> https://wiki.strongswan.org/projects/strongswan/wiki/WindowsClients#AES-256-CBC-and-MODP2048
> 
> See below my settings
> 
> ipsec statusall
> Status of IKE charon daemon (strongSwan 5.6.2, Linux 4.15.0-45-generic, 
> x86_64):
>   uptime: 45 minutes, since Feb 19 01:27:59 2019
>   malloc: sbrk 2568192, mmap 0, used 664784, free 1903408
>   worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, 
> scheduled: 0
>   loaded plugins: charon aesni aes rc2 sha2 sha1 md4 md5 mgf1 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 stroke updown eap-mschapv2 xauth-generic counters
> Virtual IP pools (size/online/offline):
>   10.10.10.0/24: 254/0/0
> Listening IP addresses:
>   102.1*9.2**.***
> Connections:
>ikev2-vpn:  %any...%any  IKEv2, dpddelay=300s
>ikev2-vpn:   local:  [102.1*9.2**.***] uses public key authentication
>ikev2-vpn:cert:  "CN=102.1*9.2**.***"
>ikev2-vpn:   remote: uses EAP_MSCHAPV2 authentication with EAP identity 
> '%any'
>ikev2-vpn:   child:  0.0.0.0/0 === dynamic TUNNEL, dpdaction=clear
> Security Associations (0 up, 0 connecting):
>   none
> 
> vi /etc/ipsec.conf
> config setup
> charondebug="ike 1, knl 1, cfg 2"
> uniqueids=no
> 
> conn ikev2-vpn
> auto=add
> compress=no
> type=tunnel
> keyexchange=ikev2
> fragmentation=yes
> forceencaps=yes
> dpdaction=clear
> dpddelay=300s
> rekey=no
> left=%any
> leftid=102.1*9.2**.***
> leftcert=server-cert.pem
> leftsendcert=always
> leftsubnet=0.0.0.0/0
> right=%any
> rightid=%any
> rightauth=eap-mschapv2
> rightsourceip=10.10.10.0/24
> rightdns=8.8.8.8,8.8.4.4
> rightsendcert=never
> eap_identity=%identity
> 
> ike=aes256-sha1-modp1024,aes128-sha1-modp1024,3des-sha1-modp1024,aes256-sha256-modp2048,aes128-sha256-modp2048,aes256-sha1-modp2048,aes128-sha1-modp2048
> 
> esp=aes256-sha256,aes256-sha1,3des-sha1,aes256-sha256-modp2048,aes128-sha256-modp2048,aes256-sha1-modp2048,aes128-sha1-modp2048
> 
> Below is the log :
> 
> Feb 19 02:10:00 VM-e2b7 charon: 07[NET] received packet: from 
> 154.77.***.**[500] to 102.1*9.2**.***[500] (632 bytes)
> Feb 19 02:10:00 VM-e2b7 charon: 07[ENC] parsed IKE_SA_INIT request 0 [ SA KE 
> No N(FRAG_SUP) N(NATD_S_IP) N(NATD_D_IP) V V V V ]
> Feb 19 02:10:00 VM-e2b7 ipsec[1011]: 11[CFG] configured proposals: 
> IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, 
> IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048,
> 
> Feb 19 02:10:00 VM-e2b7 ipsec[1011]: 11[CFG] selected proposal: 
> IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
> Feb 19 02:10:00 VM-e2b7 ipsec[1011]: 11[IKE] remote host is behind NAT
> Feb 19 02:10:00 VM-e2b7 ipsec[1011]: 11[ENC] generating IKE_SA_INIT response 
> 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(MULT_AUTH) ]
> Feb 19 02:10:00 VM-e2b7 ipsec[1011]: 11[NET] sending packet: from 
> 102.1*9.2**.***[500] to 154.77.***.**[500] (448 bytes)
> Feb 19 02:10:00 VM-e2b7 ipsec[1011]: 12[NET] received packet: from 
> 154.77.***.**[4500] to 102.1*9.2**.***[4500] (580 bytes)
> Feb 19 02:10:00 VM-e2b7 ipsec[1011]: 12[ENC] parsed IKE_AUTH request 1 [ 
> EF(1/3) ]
> Feb 19 02:10:00 VM-e2b7 ipsec[1011]: 12[ENC] received fragment #1 of 3, 
> waiting for complete IKE message
> Feb 19 02:10:00 VM-e2b7 ipsec[1011]: 12[NET] received packet: from 
> 154.77.***.**[4500] to 102.1*9.2**.***[4500] (532 bytes)
> Feb 19 02:10:00 VM-e2b7 ipsec[1011]: 12[ENC] parsed IKE_AUTH request 1 [ 
> EF(3/3) ]
> Feb 19 02:10:00 VM-e2b7 ipsec[1011]: 12[ENC] received fragment #3 of 3, 
> waiting for complete IKE message
> Feb 19 02:10:00 VM-e2b7 charon: 07[CFG] looking for an ike config for 
> 102.1*9.2**.***...154.77.***.**
> Feb 19 02:10:00 VM-e2b7 ipsec[1011]: 12[NET] received packet: from 
> 154.77.***.**[4500] to 102.1*9.2**.***[4500] (580 bytes)
> Feb 19 02:10:00 VM-e2b7 ipsec[1011]: 12[ENC] parsed IKE_AUTH request 1 [ 
> EF(2/3) ]
> Feb 19 02:10:00 VM-e2b7 ipsec[1011]: 12[ENC] received fragment #2 of 3, 
> reassembling fragmented IKE 

[strongSwan] Windows Client - Multiple Connections, Multiple Certs

[Tom Rymes]

Hopefully this will not result in a duplicate post, I sent the first 
version of this message from a different address.


I have specified two IKEv2 connections on a Windows 10 client, each one 
connecting to a different Strongswan machine using machine certificates. 
Connection1 works just fine, but when I add the second connection, along 
with its certificate, it does not work. The Strongswan server for 
Connection2 reports this in the log:


charon: 13[IKE] received cert request for "C=US, ST=QQ, 
L=Connection2Town, O=Connection2Org, OU=Connection2Dept, CN=Connection2 
CA, E=u...@connection2.com"
charon: 13[IKE] received cert request for "C=US, ST=ZZ, 
L=Connection1Town, O=Connection1Org, OU=Connection1Dept, 
CN=Connection1CA, E=u...@connection1.com"

charon: 13[IKE] received 42 cert requests for an unknown ca
charon: 13[IKE] received end entity cert "C=US, ST=ZZ, O=MyOrg, 
OU=MyDept, CN=Connection1"
charon: 13[CFG] looking for peer configs matching 
x.x.x.x[%any]...y.y.y.y[C=US, ST=ZZ, O=MyOrg, OU=MyDept, CN=Connection1]

charon: 13[CFG] no matching peer config found
charon: 13[IKE] peer supports MOBIKE
charon: 13[ENC] generating IKE_AUTH response 1 [ N(AUTH_FAILED) ]

I have imported two certificates to the client, one for each connection, 
and if I delete the certificate for Connection1, Connection2 will 
successfully connect. Is Windows sending the wrong certificate, or is 
Strongswan somehow choosing the wrong one? I do not see anywhere that I 
can specify which certificate the client should use for a given connection.


The only conclusion I can reach is that the assumption is that thie 
client will only have one certificate installed to identify itself, so I 
will need to either import the certs from one host to the other, or I 
will need to create a certificate on the windows machine and upload that 
to both hosts instead of creating separate certs for each connection?


Can anyone point out what boneheaded mistakes I am making here?

Many thanks,

Tom

Re: [strongSwan] Strongswan on Ubuntu - Failure to connect from Windows 10 client -error: deleting half open IKE_SA with 154.**.***.** after timeout

[Tom Rymes]

> On Feb 19, 2019, at 7:07 AM, IL Ka  wrote:
> 
> 1701 is L2TP port.
> It could be that Windows client tries several protos including PPTP/GRE, L2TP 
> and so on.
> 
> What do you see on Windows side? Which error?

[snip]

Moses,

I think your instructions for configuring the connection in windows are 
incomplete. As pointed out above, Windows is configured to use a VPN of type 
“auto”, so it throws everything at the server until something works.

Go back into Network and Sharing Center and click edit adapter settings on the 
left side. Get properties for the VPN connection you are using and set it to a 
type of IKE2 and configure it to use machine certificates, assuming that’s how 
you intend to authenticate (is it?).

Also, when windows fails to connect, it’s giving you an error. Multiple folks 
have asked what it is, but I don’t think you’ve answered them. That would be 
helpful.

Lastly, rather than build your own server from scratch, you may want to 
consider using a firewall distribution like IPFire, or a project like Algo that 
makes the configuration far simpler.

Tom

[strongSwan] Windows Client - Specify Machine Cert

[Tom Rymes]

I have specified two IKEv2 connections on a Windows 10 client, each one 
connecting to a different Strongswan machine using machine certificates. 
Connection1 works just fine, but when I add the second connection, along 
with its certificate, it does not work. The Strongswan server for 
Connection2 reports this in the log:


charon: 13[IKE] received cert request for "C=US, ST=QQ, 
L=Connection2Town, O=Connection2Org, OU=Connection2Dept, CN=Connection2 
CA, E=u...@connection2.com"
charon: 13[IKE] received cert request for "C=US, ST=ZZ, 
L=Connection1Town, O=Connection1Org, OU=Connection1Dept, 
CN=Connection1CA, E=u...@connection1.com"

charon: 13[IKE] received 42 cert requests for an unknown ca
charon: 13[IKE] received end entity cert "C=US, ST=ZZ, O=MyOrg, 
OU=MyDept, CN=Connection1"
charon: 13[CFG] looking for peer configs matching 
x.x.x.x[%any]...y.y.y.y[C=US, ST=ZZ, O=MyOrg, OU=MyDept, CN=Connection1]

charon: 13[CFG] no matching peer config found
charon: 13[IKE] peer supports MOBIKE
charon: 13[ENC] generating IKE_AUTH response 1 [ N(AUTH_FAILED) ]

I have imported two certificates to the client, one for each connection, 
and if I delete the certificate for Connection1, Connection2 will 
successfully connect. Is Windows sending the wrong certificate, or is 
Strongswan somehow choosing the wrong one? I do not see anywhere that I 
can specify which certificate the client should use for a given connection.


The only conclusion I can reach is that the assumption is that thie 
client will only have one certificate installed to identify itself, so I 
will need to either import the certs from one host to the other, or I 
will need to create a certificate on the windows machine and upload that 
to both hosts instead of creating separate certs for each connection?


Can anyone point out what boneheaded mistakes I am making here?

Many thanks,

Tom

[strongSwan] Selecting proper encryption pairings

[Tom Rymes]

Can anyone point me to some good information for which of the various 
options should be paired together? I've done a fair amount of digging, 
but it's always nice to have some confirmation that my interpretation is 
accurate.


I am working with Strongswan and Windows Roadwarrior clients, and am 
thus limited to (I have omitted some of the weaker options):


Encryption: AES128, AES192, AES256, GCMAES128, GCMAES192, GCMAES256

Integrity: SHA2_256, SHA2_384

Grouptype: MODP2048, ECP256, ECP384


Which combinations of encryption and integrity options provides the best 
possible security without wasting computational effort for each of the 
grouptypes?


Many thanks,

Tom

[strongSwan] MacOS X and DNS

[Tom Rymes]

While digging around a bit, I have found a number of older posts regarding DNS 
and MacOS clients, and it seems like a bit of a mess. Among other things, it 
seems that MacOS will not use pushed DNS servers unless all traffic is 
tunneled. That does work for me. When sending all traffic across the tunnel 
(leftsubnet=0.0.0.0/0), the DNS server is pushed, and name resolution works 
just fine. However, I want to split traffic and have DNS queries for one 
specific domain sent to a DNS server on the other side of the tunnel, and 
that’s where things get squirrelly.

I looked at the Wiki’s recommendations here: 
https://wiki.strongswan.org/projects/strongswan/wiki/AppleClients 


That pointed me to this: 
https://lists.strongswan.org/pipermail/users/2015-October/008844.html 


And in the end, it seems that the only way to send traffic for one specific 
search domain to a DNS server on the other end of the tunnel is to use a 
configuration profile? Setting that up manually in the IPSec configuration does 
not work (then why allow it, Apple?!). 

Am I missing anything?

Tom

Re: [strongSwan] NATing around a subnet conflict

[Tom Rymes]

On 09/15/2020 4:47 AM, Tobias Brunner wrote:

Hi Tom,


Any help and pointers to the appropriate documentation would be appreciated.


Please have a look at the ikev2/net2net-same-nets test scenario [1].

Regards,
Tobias

[1] https://www.strongswan.org/testing/testresults/ikev2/net2net-same-nets/


Thank you so much for the link, Tobias, it's a big help. There doesn't 
seem to be a copy of the "mark_updown" script for sun defined under the 
/etc/ipsec.conf file.


I'll eventually figure out how to recreate it on my own, but if there's 
already a version floating around, it would be quite helpful in tying 
the whole thing together.


Many thanks,

Tom

[strongSwan] NATing around a subnet conflict

[Tom Rymes]

Can anyone point me in the right direction to getting traffic routed 
across a site-site tunnel in a scenario where there is a subnet conflict?


Basically, our local subnet (10.100.0.0/23) conflicts with one on the 
remote side, so we need to use NAT to trick the other side into seeing 
us as 10.100.0.252/23. We have configured the tunnel and brought it up 
so that this is the output of "ipsec status tunnelname"


[root@myhost ~]# ipsec status tunnelname
Security Associations (53 up, 0 connecting):
tunnelname[6102]: ESTABLISHED 107 minutes ago, 
xxx.xxx.xxx.xxx[xxx.xxx.xxx.xxx]...yyy.yyy.yyy.yyy[yyy.yyy.yyy.yyy]
tunnelname{10971}:  INSTALLED, TUNNEL, reqid 36, ESP SPIs: ced441ef_i 
2dc9af95_o

tunnelname{10971}:   10.100.252.0/23 === 10.210.2.0/23

Now, I know that I need some SNAT/DNAT/? magic to tell the local 
machine where to send the traffic and how to translate it, but I'm in 
over my head.


Any help and pointers to the appropriate documentation would be appreciated.

Many thanks,

Tom