[strongSwan] (no subject)

[Houman]

Hello,

I would like to change the encryption to support the following on iOS:

ikev2.ikeSecurityAssociationParameters.encryptionAlgorithm =
.algorithmAES256GCM
ikev2.ikeSecurityAssociationParameters.integrityAlgorithm = .SHA384
ikev2.ikeSecurityAssociationParameters.diffieHellmanGroup = .group19
ikev2.childSecurityAssociationParameters.encryptionAlgorithm =
.algorithmAES256GCM
ikev2.childSecurityAssociationParameters.integrityAlgorithm = .SHA384
ikev2.childSecurityAssociationParameters.diffieHellmanGroup = .group19

This is how the server is setup:
config setup
  strictcrlpolicy=yes
  uniqueids=never
conn ${SERVERNAME}
  auto=add
  compress=no
  type=tunnel
  keyexchange=ikev2
  fragmentation=yes
  forceencaps=yes

ike=aes256gcm16-aes192gcm16-aes128gcm16-prfsha256-ecp521-ecp256-modp4096-modp2048,
aes256-sha256-ecp521-ecp256-modp4096-modp2048!
  esp=aes256gcm16-aes192gcm16-aes128gcm16-ecp521-ecp256-modp4096-modp2048,
aes256-sha256-sha1-ecp521-ecp256-modp4096-modp2048, aes256-sha256-sha1!
  dpdaction=clear
  dpddelay=180s
  dpdtimeout=3600s
  rekey=no
  left=%any
  leftid=@${VPNHOST}
  leftcert=cert.pem
  leftsendcert=always
  leftsubnet=0.0.0.0/0, ::/0
  right=%any
  rightid=%any
  rightauth=eap-radius
  eap_identity=%any
  rightdns=${DNS1},${DNS2}
  rightsourceip=${VPNIPPOOL},${VPNIP6POOL}
  leftfirewall=no

But I can't connect, what do I have to change to make this possible,
please?
Thanks
Houman

[strongSwan] (no subject)

[Ihor Bordun]

Hello

I am trying to implement the customized crypto kernel AES module, which
should be used only to encrypt IPsec payloads.
How can I integrate it into strongswan?

The custom AES version should be used only for IPsec thats why this crypto
module cannot have the highest priority in kernel and used by any other
crypto requests in kernel.
The Strongswan uses predefined cipher suites. Can I still configure
strongswan in the way, it should take my custom crypto module by unique
name for example or any other solution?

Regards,
Ihor

[strongSwan] (no subject)

[Yogesh Purohit]

Hi Team,

I am trying to establish tunnel with my strongswan.
But after receiving IKE_AUTH response my local strongswan end (initiator)
rejects tunnel saying ' length of TRAFFIC_SELECTOR_SUBSTRUCTURE
substructure list invalid'.

And I am unable to get the reason for the same. Because I have configured
traffic selectors matching.

IKE_Auth response which is recived is of 252 bytes, whereas when my tunnel
was established in other case IKE_AUTH response was of 204 bytes.
NOTE: I am trying the tunnel with PSK and version is IKEv2.

So is there fixed bytes of IKE_AUTH response which is expected by
strongswan for PSK.

And what does 'length of TRAFFIC_SELECTOR_SUBSTRUCTURE substructure list
invalid' means, I tried finding it in RFC, but could not find the same.


Thanks & Regards,

Yogesh Purohit

Re: [strongSwan] (no subject)

[Andreas Steffen]

Hi Sandesh,

RSA signature-based authentication can only be broken if the
same RSA key is being used as for RSA encryption-based authentication
and this RSA key is broken applying the Bleichenbacher oracle to
RSA encryption-based authentication.

Since strongSwan does not implement RSA encryption, the RSA key cannot
be determined using the Bleichenbacher oracle and therefore IKEv1 and
IKEv2 RSA signatures cannot be compromised.

It has always been known that IKEv1 and IKEv2 PSK-based authentication
can be broken with an offline attack if the PSK is too weak. This is why
we recommend EAP-based user authentication with IKEv2 where the server
must authenticate itself first

PSKs with 128 bit cryptographic strength or more cannot be broken.

Best regards

Andreas

On 03.09.2018 11:20, Sandesh Sawant wrote:
> Hello Andreas,
> 
> 
> Thanks for confirming that strongSwan isn't vulnerable to the mentioned
> attack.
> 
> 
> However the report claims to have exploits for PSK and RSA signature
> based authentication also... Quoting from the report abstract: 
> 
>  "We exploit a Bleichenbacher oracle in an IKEv1 mode, where RSA
> 
> encrypted nonces are used for authentication. Using this
> 
> exploit, we break these RSA encryption  based modes,
> 
> and in addition break RSA signature  based authentication
> 
> in both IKEv1 and IKEv2. Additionally, we describe
> 
> an offline dictionary attack against the PSK (Pre-Shared
> 
> Key) based IKE modes, thus covering all available authentication
> 
> mechanisms of IKE."
> 
> 
> Can you please confirm that strongSwan isn't vulnerable to the
> Bleichenbacher attack against IKEv2 signature based auth and offline
> dictionary attack mentioned for PSK based auth (irrespective of the PSK
> chosen by the user)?
> 
> 
> Thanks,
> 
> Sandesh
> 
> 
> On Fri, Aug 31, 2018 at 3:50 PM Andreas Steffen
> mailto:andreas.stef...@strongswan.org>>
> wrote:
> 
> Hi Sandesh,
> 
> strongSwan is not vulnerable to the Bleichenbacher oracle attack
> since we did not implement the RSA encryption authentication variant
> for IKEv1.
> 
> Best regards
> 
> Andreas
> 
> On 31.08.2018 10:53, Sandesh Sawant wrote:
> > Hi all,
> >
> > I came across below news about a paper enlisting attacks pertaining to
> > IKE protocol, and want to know whether the latest version of trongSwan
> > stack is vulnerable to the attacks mentioned in this
> >
> paper: 
> https://www.ei.rub.de/media/nds/veroeffentlichungen/2018/08/13/sec18-felsch.pdf
> > References:
> >
> 
> https://latesthackingnews.com/2018/08/20/ipsec-vpn-connections-broken-using-20-year-old-flaw/
> >
> 
> https://securityaffairs.co/wordpress/75352/hacking/key-reuse-ipsec-attack.html
> >
> > Thanks,
> > Sandesh
> 
==
Andreas Steffen andreas.stef...@strongswan.org
strongSwan - the Open Source VPN Solution!  www.strongswan.org
Institute for Networked Solutions
HSR University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===[INS-HSR]==

Re: [strongSwan] (no subject)

[Sandesh Sawant]

Hi Graham,

Thanks for clarifying this further.

Best,
Sandesh
On Mon, Sep 3, 2018 at 3:49 PM Graham Bartlett (grbartle) <
grbar...@cisco.com> wrote:

> Hi Sandesh
>
>
>
> The offline dictionary PSK attack isn’t something new (people have known
> about this since last millennia!).
>
>
>
> In summary if you have a ‘strong’ PSK you’re safe.. But if you have an
> active MiTM as described in the paper then they can perform an offline
> brute force attack against your PSK assuming they have the computing power
> to find it..
>
>
>
> I wrote the following to help explain this..
>
>
>
>
> https://www.linkedin.com/pulse/ike-brute-force-attack-explained-graham-bartlett/
>
>
>
> cheers
>
>
>
> *From: *Users  on behalf of Sandesh
> Sawant 
> *Date: *Monday, 3 September 2018 at 10:20
> *To: *"andreas.stef...@strongswan.org" 
> *Cc: *"users@lists.strongswan.org" 
> *Subject: *Re: [strongSwan] (no subject)
>
>
>
> Hello Andreas,
>
>
>
> Thanks for confirming that strongSwan isn't vulnerable to the mentioned
> attack.
>
>
>
> However the report claims to have exploits for PSK and RSA signature based
> authentication also... Quoting from the report abstract:
>
>  "We exploit a Bleichenbacher oracle in an IKEv1 mode, where RSA
>
> encrypted nonces are used for authentication. Using this
>
> exploit, we break these RSA encryption  based modes,
>
> and in addition break RSA signature  based authentication
>
> in both IKEv1 and IKEv2. Additionally, we describe
>
> an offline dictionary attack against the PSK (Pre-Shared
>
> Key) based IKE modes, thus covering all available authentication
>
> mechanisms of IKE."
>
>
>
> Can you please confirm that strongSwan isn't vulnerable to the
> Bleichenbacher attack against IKEv2 signature based auth and offline
> dictionary attack mentioned for PSK based auth (irrespective of the PSK
> chosen by the user)?
>
>
>
> Thanks,
>
> Sandesh
>
>
>
> On Fri, Aug 31, 2018 at 3:50 PM Andreas Steffen <
> andreas.stef...@strongswan.org> wrote:
>
> Hi Sandesh,
>
> strongSwan is not vulnerable to the Bleichenbacher oracle attack
> since we did not implement the RSA encryption authentication variant
> for IKEv1.
>
> Best regards
>
> Andreas
>
> On 31.08.2018 10:53, Sandesh Sawant wrote:
> > Hi all,
> >
> > I came across below news about a paper enlisting attacks pertaining to
> > IKE protocol, and want to know whether the latest version of trongSwan
> > stack is vulnerable to the attacks mentioned in this
> > paper:
> https://www.ei.rub.de/media/nds/veroeffentlichungen/2018/08/13/sec18-felsch.pdf
> > References:
> >
> https://latesthackingnews.com/2018/08/20/ipsec-vpn-connections-broken-using-20-year-old-flaw/
> >
> https://securityaffairs.co/wordpress/75352/hacking/key-reuse-ipsec-attack.html
> >
> > Thanks,
> > Sandesh
>
> ==
> Andreas Steffen andreas.stef...@strongswan.org
> strongSwan - the Open Source VPN Solution!  www.strongswan.org
> Institute for Networked Solutions
> HSR University of Applied Sciences Rapperswil
> CH-8640 Rapperswil (Switzerland)
> ===[INS-HSR]==
>
>

Re: [strongSwan] (no subject)

[Graham Bartlett (grbartle)]

Hi Sandesh

 

The offline dictionary PSK attack isn’t something new (people have known about 
this since last millennia!).

 

In summary if you have a ‘strong’ PSK you’re safe.. But if you have an active 
MiTM as described in the paper then they can perform an offline brute force 
attack against your PSK assuming they have the computing power to find it.. 

 

I wrote the following to help explain this..

 

https://www.linkedin.com/pulse/ike-brute-force-attack-explained-graham-bartlett/

 

cheers

 

From: Users  on behalf of Sandesh Sawant 

Date: Monday, 3 September 2018 at 10:20
To: "andreas.stef...@strongswan.org" 
Cc: "users@lists.strongswan.org" 
Subject: Re: [strongSwan] (no subject)

 

Hello Andreas,

 

Thanks for confirming that strongSwan isn't vulnerable to the mentioned attack.

 

However the report claims to have exploits for PSK and RSA signature based 
authentication also... Quoting from the report abstract: 

 "We exploit a Bleichenbacher oracle in an IKEv1 mode, where RSA

encrypted nonces are used for authentication. Using this

exploit, we break these RSA encryption  based modes,

and in addition break RSA signature  based authentication

in both IKEv1 and IKEv2. Additionally, we describe

an offline dictionary attack against the PSK (Pre-Shared

Key) based IKE modes, thus covering all available authentication

mechanisms of IKE."

 

Can you please confirm that strongSwan isn't vulnerable to the Bleichenbacher 
attack against IKEv2 signature based auth and offline dictionary attack 
mentioned for PSK based auth (irrespective of the PSK chosen by the user)?

 

Thanks,

Sandesh

 

On Fri, Aug 31, 2018 at 3:50 PM Andreas Steffen 
 wrote:

Hi Sandesh,

strongSwan is not vulnerable to the Bleichenbacher oracle attack
since we did not implement the RSA encryption authentication variant
for IKEv1.

Best regards

Andreas

On 31.08.2018 10:53, Sandesh Sawant wrote:
> Hi all,
> 
> I came across below news about a paper enlisting attacks pertaining to
> IKE protocol, and want to know whether the latest version of trongSwan
> stack is vulnerable to the attacks mentioned in this
> paper: 
> https://www.ei.rub.de/media/nds/veroeffentlichungen/2018/08/13/sec18-felsch.pdf
> References:
> https://latesthackingnews.com/2018/08/20/ipsec-vpn-connections-broken-using-20-year-old-flaw/
> https://securityaffairs.co/wordpress/75352/hacking/key-reuse-ipsec-attack.html
> 
> Thanks,
> Sandesh

==
Andreas Steffen andreas.stef...@strongswan.org
strongSwan - the Open Source VPN Solution!  www.strongswan.org
Institute for Networked Solutions
HSR University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===[INS-HSR]==



smime.p7s
Description: S/MIME cryptographic signature

Re: [strongSwan] (no subject)

[Sandesh Sawant]

Hello Andreas,


Thanks for confirming that strongSwan isn't vulnerable to the mentioned
attack.


However the report claims to have exploits for PSK and RSA signature based
authentication also... Quoting from the report abstract:

 "We exploit a Bleichenbacher oracle in an IKEv1 mode, where RSA

encrypted nonces are used for authentication. Using this

exploit, we break these RSA encryption  based modes,

and in addition break RSA signature  based authentication

in both IKEv1 and IKEv2. Additionally, we describe

an offline dictionary attack against the PSK (Pre-Shared

Key) based IKE modes, thus covering all available authentication

mechanisms of IKE."


Can you please confirm that strongSwan isn't vulnerable to the
Bleichenbacher attack against IKEv2 signature based auth and offline
dictionary attack mentioned for PSK based auth (irrespective of the PSK
chosen by the user)?


Thanks,

Sandesh

On Fri, Aug 31, 2018 at 3:50 PM Andreas Steffen <
andreas.stef...@strongswan.org> wrote:

> Hi Sandesh,
>
> strongSwan is not vulnerable to the Bleichenbacher oracle attack
> since we did not implement the RSA encryption authentication variant
> for IKEv1.
>
> Best regards
>
> Andreas
>
> On 31.08.2018 10:53, Sandesh Sawant wrote:
> > Hi all,
> >
> > I came across below news about a paper enlisting attacks pertaining to
> > IKE protocol, and want to know whether the latest version of trongSwan
> > stack is vulnerable to the attacks mentioned in this
> > paper:
> https://www.ei.rub.de/media/nds/veroeffentlichungen/2018/08/13/sec18-felsch.pdf
> > References:
> >
> https://latesthackingnews.com/2018/08/20/ipsec-vpn-connections-broken-using-20-year-old-flaw/
> >
> https://securityaffairs.co/wordpress/75352/hacking/key-reuse-ipsec-attack.html
> >
> > Thanks,
> > Sandesh
>
> ==
> Andreas Steffen andreas.stef...@strongswan.org
> strongSwan - the Open Source VPN Solution!  www.strongswan.org
> Institute for Networked Solutions
> HSR University of Applied Sciences Rapperswil
> CH-8640 Rapperswil (Switzerland)
> ===[INS-HSR]==
>

Re: [strongSwan] (no subject)

[Andreas Steffen]

Hi Sandesh,

strongSwan is not vulnerable to the Bleichenbacher oracle attack
since we did not implement the RSA encryption authentication variant
for IKEv1.

Best regards

Andreas

On 31.08.2018 10:53, Sandesh Sawant wrote:
> Hi all,
> 
> I came across below news about a paper enlisting attacks pertaining to
> IKE protocol, and want to know whether the latest version of trongSwan
> stack is vulnerable to the attacks mentioned in this
> paper: 
> https://www.ei.rub.de/media/nds/veroeffentlichungen/2018/08/13/sec18-felsch.pdf
> References:
> https://latesthackingnews.com/2018/08/20/ipsec-vpn-connections-broken-using-20-year-old-flaw/
> https://securityaffairs.co/wordpress/75352/hacking/key-reuse-ipsec-attack.html
> 
> Thanks,
> Sandesh

==
Andreas Steffen andreas.stef...@strongswan.org
strongSwan - the Open Source VPN Solution!  www.strongswan.org
Institute for Networked Solutions
HSR University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===[INS-HSR]==

[strongSwan] (no subject)

[Sandesh Sawant]

Hi all,

I came across below news about a paper enlisting attacks pertaining to IKE
protocol, and want to know whether the latest version of trongSwan stack is
vulnerable to the attacks mentioned in this paper:
https://www.ei.rub.de/media/nds/veroeffentlichungen/2018/08/13/sec18-felsch.pdf
References:
https://latesthackingnews.com/2018/08/20/ipsec-vpn-connections-broken-using-20-year-old-flaw/
https://securityaffairs.co/wordpress/75352/hacking/key-reuse-ipsec-attack.html

Thanks,
Sandesh

[strongSwan] (no subject)

[Dan Vee]

Hi,

I currently have strongSwan server setup on a VPS host, and I'm also
running an adblocking DNS server (not exposed to internet) on this same
host. The server only has one interface and it has a public IP address
(e.g. 1.2.3.4). I'd like to configure strongSwan to hand out a DNS address
(for this local DNS server) for any clients that connect. I have two
problems:
* I don't know how to make the DNS service running on the same VPS host
accessible to the connecting client. My client has a virtual IP (e.g.
10.20.30.1) and not sure how I can communicate directly with a service
running locally on this VPS host.
* I don't know what IP I should I pass back to the client for this DNS
address. I have no private IP address on this server. Should I return the
public IP address for the server?


Server config

config setup
uniqueids=never
charondebug="cfg 2, dmn 2, ike 2, net 2"
conn %default
keyexchange=ike
dpdaction=clear
dpddelay=300s
rekey=no
left=%any
leftca=ca.cert.pem
leftcert=server.cert.pem
leftsubnet=0.0.0.0/0
right=%any
rightdns=
rightsourceip=10.20.30.0/24
rightsubnets=192.168.3.0/24
conn IPSec-IKEv2
keyexchange=ikev2
ike=aes256-sha256-modp1024,3des-sha1-modp1024,aes256-sha1-modp1024!
esp=aes256-sha256,3des-sha1,aes256-sha1!
leftid="1.2.3.4"
leftsendcert=always
leftauth=pubkey
rightauth=pubkey
rightid="client@1.2.3.4"
rightcert=client.cert.pem
auto=add

Any help would be greatly appreciated. Thanks!

Re: [strongSwan] (no subject)

[Noel Kuntze]

Hi Sandesh

There's no POSTROUTING chain in the *filter table, so your command will never 
work.
The table is probably *mangle, because *nat never gets packets with ctstate 
INVALID.
You're probably missing something major here.

Please provide the information listed here[1] using the provided commands.

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

On 03.10.2017 14:34, Sandesh Sawant wrote:
> Hi Noel,
> 
> Apologies for late response. The setup I was using had to be dismantled and 
> rebuilt. After further debugging it is found that this issue isn't related to 
> strongswan/xfrm behavior - it's related to firewall. The reason for the VTI 
> ping not going out of ipsec tunnel was a firewall rule: iptables -A 
> POSTROUTING -m state --state INVALID -j DROP
> If this rule is deleted or overridden with iptables -I POSTROUTING -o vNic_0 
> -j ACCEPT
> then everything works fine. But I don't want to do it for security reasons. 
> Any idea why packet originating from VTI and entering corresponding tunnel 
> local endpoint interface is considered as INVALID state?
>  
> Thanks,
> Sandesh
> 
> On Fri, Sep 22, 2017 at 2:50 PM, Noel Kuntze 
>  > wrote:
> 
> Please provide the following data:
> 
> - Output of `iptables-save` of both hosts
> - Output of `ip route show table all` of both hosts
> - Output of `ip address` of both hosts
> 
> Kind regards
> 
> Noel
> 
> On 22.09.2017 07 :17, Sandesh Sawant wrote:
> > I have referred to following links and configured strongSwan to 
> establish a route-based VPN tunnel between 2 Linux 4.4.57 boxes.
> > https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN 
>  
>  >
> > https://wiki.strongswan.org/projects/strongswan/wiki/ReducedPrivileges 
>  
>  >
> >
> > The data path used to work perfectly fine when both sides are using 
> strongSwan v5.5.1. After upgrading same setup to v5.5.2, tunnel gets 
> established but ping between the VTI interfaces doesn't work. If we ping from 
> host running v5.5.2, no ESP packet is sent out. If we ping form host running 
> v5.5.1 to host running v5.5.2, ESP packet goes out, but host running v5.5.2 
> doesn't send ESP in response.
> >
> > My ipsec.conf file is as follows (install_route=no is added in 
> strongswan.conf):
> > conn 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0
> >         left=10.160.229.241
> >         leftid=10.160.229.241
> >         rightid=10.160.229.240
> >         leftsubnet=0.0.0.0/0  
> >         right=10.160.229.240
> >         rightsubnet=0.0.0.0/0  
> >         authby=secret
> >         keyexchange = ikev2
> >         mark = 1
> >         auto = start
> >         esp=aes128-sha1-modp2048
> >         ike=aes128-sha1-modp2048!
> >
> > Tunnel establishment works fine, there is nothing suspicious in logs, 
> and the output of 'ipsec statusall' is as follows:
> >
> > Status of IKE charon daemon (strongSwan 5.5.2, Linux 4.4.57, x86_64):
> >   uptime: 18 days, since Aug 18 10:58:17 2017
> >   malloc: sbrk 1477008, mmap 0, used 357360, free 1119648
> >   worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, 
> scheduled: 6
> >   loaded plugins: charon aes des rc2 sha2 sha1 md5 random nonce x509 
> revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem 
> openssl fips-prf xcbc cmac hmac attr kernel-netlink resolve socket-default 
> stroke vici updown xauth-generic
> > Listening IP addresses:
> >   10.160.229.241
> > Connections:
> > 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0:  
> 10.160.229.241...10.160.229.240  IKEv2, dpddelay=30s
> > 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0:   local:  
> [10.160.229.241] uses pre-shared key authentication
> > 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0:   remote: 
> [10.160.229.240] uses pre-shared key authentication
> > 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0:   child:  0.0.0.0/0 
>   === 0.0.0.0/0  
>  TUNNEL, dpdaction=restart
> > Routed Connections:
> > 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0{253}:  ROUTED, 
> TUNNEL, reqid 6
> > 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0{253}:   0.0.0.0/0 
> 

Re: [strongSwan] (no subject)

[Sandesh Sawant]

Hi Noel,

Apologies for late response. The setup I was using had to be dismantled and
rebuilt. After further debugging it is found that this issue isn't related
to strongswan/xfrm behavior - it's related to firewall. The reason for the
VTI ping not going out of ipsec tunnel was a firewall rule: iptables -A
POSTROUTING -m state --state INVALID -j DROP
If this rule is deleted or overridden with iptables -I POSTROUTING -o
vNic_0 -j ACCEPT
then everything works fine. But I don't want to do it for security reasons.
Any idea why packet originating from VTI and entering corresponding tunnel
local endpoint interface is considered as INVALID state?

Thanks,
Sandesh

On Fri, Sep 22, 2017 at 2:50 PM, Noel Kuntze <
noel.kuntze+strongswan-users-ml@thermi.consulting> wrote:

> Please provide the following data:
>
> - Output of `iptables-save` of both hosts
> - Output of `ip route show table all` of both hosts
> - Output of `ip address` of both hosts
>
> Kind regards
>
> Noel
>
> On 22.09.2017 07:17, Sandesh Sawant wrote:
> > I have referred to following links and configured strongSwan to
> establish a route-based VPN tunnel between 2 Linux 4.4.57 boxes.
> > https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN <
> https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN>
> > https://wiki.strongswan.org/projects/strongswan/wiki/ReducedPrivileges <
> https://wiki.strongswan.org/projects/strongswan/wiki/ReducedPrivileges>
> >
> > The data path used to work perfectly fine when both sides are using
> strongSwan v5.5.1. After upgrading same setup to v5.5.2, tunnel gets
> established but ping between the VTI interfaces doesn't work. If we ping
> from host running v5.5.2, no ESP packet is sent out. If we ping form host
> running v5.5.1 to host running v5.5.2, ESP packet goes out, but host
> running v5.5.2 doesn't send ESP in response.
> >
> > My ipsec.conf file is as follows (install_route=no is added in
> strongswan.conf):
> > conn 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0
> > left=10.160.229.241
> > leftid=10.160.229.241
> > rightid=10.160.229.240
> > leftsubnet=0.0.0.0/0 
> > right=10.160.229.240
> > rightsubnet=0.0.0.0/0 
> > authby=secret
> > keyexchange = ikev2
> > mark = 1
> > auto = start
> > esp=aes128-sha1-modp2048
> > ike=aes128-sha1-modp2048!
> >
> > Tunnel establishment works fine, there is nothing suspicious in logs,
> and the output of 'ipsec statusall' is as follows:
> >
> > Status of IKE charon daemon (strongSwan 5.5.2, Linux 4.4.57, x86_64):
> >   uptime: 18 days, since Aug 18 10:58:17 2017
> >   malloc: sbrk 1477008, mmap 0, used 357360, free 1119648
> >   worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0,
> scheduled: 6
> >   loaded plugins: charon aes des rc2 sha2 sha1 md5 random nonce x509
> revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey
> pem openssl fips-prf xcbc cmac hmac attr kernel-netlink resolve
> socket-default stroke vici updown xauth-generic
> > Listening IP addresses:
> >   10.160.229.241
> > Connections:
> > 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0:
>  10.160.229.241...10.160.229.240  IKEv2, dpddelay=30s
> > 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0:   local:
>  [10.160.229.241] uses pre-shared key authentication
> > 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0:   remote:
> [10.160.229.240] uses pre-shared key authentication
> > 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0:   child:  0.0.0.0/0 <
> http://0.0.0.0/0> === 0.0.0.0/0  TUNNEL,
> dpdaction=restart
> > Routed Connections:
> > 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0{253}:  ROUTED,
> TUNNEL, reqid 6
> > 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0{253}:   0.0.0.0/0 <
> http://0.0.0.0/0> === 0.0.0.0/0 
> > Security Associations (1 up, 0 connecting):
> > 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0[30]: ESTABLISHED 6
> hours ago, 10.160.229.241[10.160.229.241]...10.160.229.240[10.160.229.240]
> > 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0[30]: IKEv2 SPIs:
> 066c631f67deb19d_i 009d1bbbed44b77a_r*, pre-shared key reauthentication in
> 91 minutes
> > 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0[30]: IKE proposal:
> AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
> > 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0{263}:  INSTALLED,
> TUNNEL, reqid 6, ESP SPIs: cc9cecd6_i ce4575a3_o
> > 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0{263}:
>  AES_CBC_128/HMAC_SHA1_96/MODP_2048, 0 bytes_i (0 pkts, 1556478s ago) ( 0
> integrity_failed_errors) (0 replay_errors) (0 decryption_failures) (0
> sa_expired_error) (0 recv_errors), 0 bytes_o (0 pkts, 1556478s ago) (0
> encryption_failures)(0 spi_overflow_error)(0 send_errors), rekeying in 35
> minutes
> > 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0{263}:   0.0.0.0/0 <
> http://0.0.0.0/0> === 

Re: [strongSwan] (no subject)

[Noel Kuntze]

Please provide the following data:

- Output of `iptables-save` of both hosts
- Output of `ip route show table all` of both hosts
- Output of `ip address` of both hosts

Kind regards

Noel

On 22.09.2017 07:17, Sandesh Sawant wrote:
> I have referred to following links and configured strongSwan to establish a 
> route-based VPN tunnel between 2 Linux 4.4.57 boxes.
> https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN 
> 
> https://wiki.strongswan.org/projects/strongswan/wiki/ReducedPrivileges 
> 
>
> The data path used to work perfectly fine when both sides are using 
> strongSwan v5.5.1. After upgrading same setup to v5.5.2, tunnel gets 
> established but ping between the VTI interfaces doesn't work. If we ping from 
> host running v5.5.2, no ESP packet is sent out. If we ping form host running 
> v5.5.1 to host running v5.5.2, ESP packet goes out, but host running v5.5.2 
> doesn't send ESP in response.
>
> My ipsec.conf file is as follows (install_route=no is added in 
> strongswan.conf):
> conn 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0
>         left=10.160.229.241
>         leftid=10.160.229.241
>         rightid=10.160.229.240
>         leftsubnet=0.0.0.0/0 
>         right=10.160.229.240
>         rightsubnet=0.0.0.0/0 
>         authby=secret
>         keyexchange = ikev2
>         mark = 1
>         auto = start
>         esp=aes128-sha1-modp2048
>         ike=aes128-sha1-modp2048!
>
> Tunnel establishment works fine, there is nothing suspicious in logs, and the 
> output of 'ipsec statusall' is as follows:
>
> Status of IKE charon daemon (strongSwan 5.5.2, Linux 4.4.57, x86_64):
>   uptime: 18 days, since Aug 18 10:58:17 2017
>   malloc: sbrk 1477008, mmap 0, used 357360, free 1119648
>   worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, 
> scheduled: 6
>   loaded plugins: charon aes des rc2 sha2 sha1 md5 random nonce x509 
> revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem 
> openssl fips-prf xcbc cmac hmac attr kernel-netlink resolve socket-default 
> stroke vici updown xauth-generic
> Listening IP addresses:
>   10.160.229.241
> Connections:
> 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0:  
> 10.160.229.241...10.160.229.240  IKEv2, dpddelay=30s
> 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0:   local:  [10.160.229.241] 
> uses pre-shared key authentication
> 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0:   remote: [10.160.229.240] 
> uses pre-shared key authentication
> 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0:   child:  0.0.0.0/0 
>  === 0.0.0.0/0  TUNNEL, dpdaction=restart
> Routed Connections:
> 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0{253}:  ROUTED, TUNNEL, 
> reqid 6
> 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0{253}:   0.0.0.0/0 
>  === 0.0.0.0/0 
> Security Associations (1 up, 0 connecting):
> 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0[30]: ESTABLISHED 6 hours 
> ago, 10.160.229.241[10.160.229.241]...10.160.229.240[10.160.229.240]
> 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0[30]: IKEv2 SPIs: 
> 066c631f67deb19d_i 009d1bbbed44b77a_r*, pre-shared key reauthentication in 91 
> minutes
> 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0[30]: IKE proposal: 
> AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
> 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0{263}:  INSTALLED, TUNNEL, 
> reqid 6, ESP SPIs: cc9cecd6_i ce4575a3_o
> 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0{263}:  
> AES_CBC_128/HMAC_SHA1_96/MODP_2048, 0 bytes_i (0 pkts, 1556478s ago) ( 0 
> integrity_failed_errors) (0 replay_errors) (0 decryption_failures) (0 
> sa_expired_error) (0 recv_errors), 0 bytes_o (0 pkts, 1556478s ago) (0 
> encryption_failures)(0 spi_overflow_error)(0 send_errors), rekeying in 35 
> minutes
> 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0{263}:   0.0.0.0/0 
>  === 0.0.0.0/0 
>
> The SA & SP downloaded in kernel are as follows:
>
> # ip x s s
> src 10.160.229.241 dst 10.160.229.240
> proto esp spi 0xce4575a3 reqid 6 mode tunnel
> replay-window 0 flag af-unspec
> mark 0x1/0x
> auth-trunc hmac(sha1) 0x542da7b70b7a0ad1ba0814a6bf544eb96a5826ab 96
> enc cbc(aes) 0xedf587dc5374762dcb6330ccd495eecb
> anti-replay context: seq 0x0, oseq 0x0, bitmap 0x
> src 10.160.229.240 dst 10.160.229.241
> proto esp spi 0xcc9cecd6 reqid 6 mode tunnel
> replay-window 32 flag af-unspec
> auth-trunc hmac(sha1) 0xcc345e738d8969334d8c4e6588c98ca43029fd8a 96
> enc cbc(aes) 0x9867e41aa23002f9cdd1b5b17cfde26c
> anti-replay context: seq 0x0, oseq 0x0, bitmap 0x
> # ip x p s
> src 0.0.0.0/0  dst 0.0.0.0/0  
> dir fwd priority 39 ptype main 
> mark 0x1/0x

[strongSwan] (no subject)

[Sandesh Sawant]

I have referred to following links and configured strongSwan to establish a
route-based VPN tunnel between 2 Linux 4.4.57 boxes.
https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN
https://wiki.strongswan.org/projects/strongswan/wiki/ReducedPrivileges

The data path used to work perfectly fine when both sides are using
strongSwan v5.5.1. After upgrading same setup to v5.5.2, tunnel gets
established but ping between the VTI interfaces doesn't work. If we ping
from host running v5.5.2, no ESP packet is sent out. If we ping form host
running v5.5.1 to host running v5.5.2, ESP packet goes out, but host
running v5.5.2 doesn't send ESP in response.

My ipsec.conf file is as follows (install_route=no is added in
strongswan.conf):
conn 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0
left=10.160.229.241
leftid=10.160.229.241
rightid=10.160.229.240
leftsubnet=0.0.0.0/0
right=10.160.229.240
rightsubnet=0.0.0.0/0
authby=secret
keyexchange = ikev2
mark = 1
auto = start
esp=aes128-sha1-modp2048
ike=aes128-sha1-modp2048!

Tunnel establishment works fine, there is nothing suspicious in logs, and
the output of 'ipsec statusall' is as follows:

Status of IKE charon daemon (strongSwan 5.5.2, Linux 4.4.57, x86_64):
  uptime: 18 days, since Aug 18 10:58:17 2017
  malloc: sbrk 1477008, mmap 0, used 357360, free 1119648
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0,
scheduled: 6
  loaded plugins: charon aes des rc2 sha2 sha1 md5 random nonce x509
revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey
pem openssl fips-prf xcbc cmac hmac attr kernel-netlink resolve
socket-default stroke vici updown xauth-generic
Listening IP addresses:
  10.160.229.241
Connections:
10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0:
 10.160.229.241...10.160.229.240  IKEv2, dpddelay=30s
10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0:   local:
 [10.160.229.241] uses pre-shared key authentication
10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0:   remote:
[10.160.229.240] uses pre-shared key authentication
10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0:   child:  0.0.0.0/0 ===
0.0.0.0/0 TUNNEL, dpdaction=restart
Routed Connections:
10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0{253}:  ROUTED, TUNNEL,
reqid 6
10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0{253}:   0.0.0.0/0 ===
0.0.0.0/0
Security Associations (1 up, 0 connecting):
10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0[30]: ESTABLISHED 6 hours
ago, 10.160.229.241[10.160.229.241]...10.160.229.240[10.160.229.240]
10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0[30]: IKEv2 SPIs:
066c631f67deb19d_i 009d1bbbed44b77a_r*, pre-shared key reauthentication in
91 minutes
10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0[30]: IKE proposal:
AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0{263}:  INSTALLED, TUNNEL,
reqid 6, ESP SPIs: cc9cecd6_i ce4575a3_o
10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0{263}:
 AES_CBC_128/HMAC_SHA1_96/MODP_2048, 0 bytes_i (0 pkts, 1556478s ago) ( 0
integrity_failed_errors) (0 replay_errors) (0 decryption_failures) (0
sa_expired_error) (0 recv_errors), 0 bytes_o (0 pkts, 1556478s ago) (0
encryption_failures)(0 spi_overflow_error)(0 send_errors), rekeying in 35
minutes
10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0{263}:   0.0.0.0/0 ===
0.0.0.0/0

The SA & SP downloaded in kernel are as follows:

# ip x s s
src 10.160.229.241 dst 10.160.229.240
proto esp spi 0xce4575a3 reqid 6 mode tunnel
replay-window 0 flag af-unspec
mark 0x1/0x
auth-trunc hmac(sha1) 0x542da7b70b7a0ad1ba0814a6bf544eb96a5826ab 96
enc cbc(aes) 0xedf587dc5374762dcb6330ccd495eecb
anti-replay context: seq 0x0, oseq 0x0, bitmap 0x
src 10.160.229.240 dst 10.160.229.241
proto esp spi 0xcc9cecd6 reqid 6 mode tunnel
replay-window 32 flag af-unspec
auth-trunc hmac(sha1) 0xcc345e738d8969334d8c4e6588c98ca43029fd8a 96
enc cbc(aes) 0x9867e41aa23002f9cdd1b5b17cfde26c
anti-replay context: seq 0x0, oseq 0x0, bitmap 0x
# ip x p s
src 0.0.0.0/0 dst 0.0.0.0/0
dir fwd priority 39 ptype main
mark 0x1/0x
tmpl src 10.160.229.240 dst 10.160.229.241
proto esp reqid 6 mode tunnel
src 0.0.0.0/0 dst 0.0.0.0/0
dir in priority 39 ptype main
mark 0x1/0x
tmpl src 10.160.229.240 dst 10.160.229.241
proto esp reqid 6 mode tunnel
src 0.0.0.0/0 dst 0.0.0.0/0
dir out priority 39 ptype main
mark 0x1/0x
tmpl src 10.160.229.241 dst 10.160.229.240
proto esp reqid 6 mode tunnel
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0 ptype main

The corresponding VTI is configured as follows:

ip link add vti-1 type vti key 1 local 10.160.229.241 remote 10.160.229.240
ip link set vti-1 up
ip addr add 

Re: [strongSwan] (no subject)

[Martin Willi]

 However, swanctl -L shows conns multiple times

I couldn't reproduce this. Is there anything suspicious when invoking
swanctl --load-conns?

And please be aware: --list-conns enumerates all configurations it
finds, not only those loaded through swanctl itself. So if you still
have the same configuration loaded through ipsec.conf, this could
explain why you are seeing it twice.

 and swanctl -P doesn't show any pool definitions.

And it shouldn't; -P is the short form for --list-pols to list trap,
drop and bypass policies. -A is short for --list-pools, which should
show your loaded pool definitions from swanctl.conf.

Regards
Martin

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

[strongSwan] (no subject)

[Noel Kuntze]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello list,

I'm using swanctl and could convert my ipsec.conf into swanctl.conf.
However, swanctl -L shows conns multiple times and swanctl -P doesn't show any 
pool definitions.

Can anyone reproduce that problem?

Regards,
Noel Kuntze

- -- 
GPG Key id: 0x63EC6658
Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJTwFdXAAoJEDg5KY9j7GZYMQoP/RuqZlOYRiTO/Ih/9ra2cXwf
mokJZlICQg/PZieH7c5XQhO9kxGDSCHqqTDoDQc1lD0kV0yALi37dsgxtZSLt+i1
tzbSnazNcSM1KhAZaeSJHMDpSc1xBlBn+a/SWQ4ewnT5Iwt6ZgDBGGCJX9l/CuGF
8R2EiK4CszZIUmLZn8KFFeWI3HWvqcQacibOYHUT/nAFMzC3Yk4ZxGzV9KLDZBkb
BdHD0F0MPAxTmpipVcsI8xSoEDh8iN40iS1dS/ZfMK2hZDNDTOT5jsSUs3BVt8Do
Rw3zqvWjMUz6KozdCqP7P3XbvFmG1uZjhHM6RafcRBEHsImn0Xzj/+zq2fsfWOMI
H35Hb8uEbsEQNt/1nPWepsTAY1QA0DTbBB9iCidAHKtJjhjYh4XP2gQ6QOcpHj6F
XN9xO0oYxXrhanabRWVgEWsydv1QgNJFOL3vex9dDp3lNLhxo4YLXuX/Dtl2M7Nt
OLycA/inwWSjlJRVPecM8/O8292g4wt/fAPaDdeeMrfrlFdZBuSA7UGyr8z9yxhX
o/ODGzz1ogd6iUBgjAvH+fATvIm5MwYbERD9AjThzzljl9xQE7y/tkwh8GaTaR4N
sjGeEngI/46mRPy5X3p+hmppSpcI+HCKh3vcLh4sJbZm2V7TB7344aXupwmqmzrH
JP39h7cuSh5uiYmI+2CK
=oCTa
-END PGP SIGNATURE-

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

Re: [strongSwan] (no subject)

[Martin Willi]

Hi,

 10[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
 10[IKE] no IKE config found for 37.247.54.124...38.109.218.26, sending 
 NO_PROPOSAL_CHOSEN
 10[ENC] generating IKE_SA_INIT response 0 [ N(NO_PROP) ]

 left=%defaultroute
 right=37.247.54.124

Can you confirm that your %defaultroute is over 38.109.218.26? You may
try to use %any if you meant that, which should be much less problematic
in matching.

 leftsourceip=10.7.1.11
 rightsourceip=10.7.1.10

What's your intention with setting both left/rightsourceip? With IKEv2
(and also with IKEv1 since 5.x), left/rightsourceip get assigned (and
newly installed) to the peer using configuration payloads; does not make
that much sense in this scenario, and certainly doesn't work for both
ends.

charon automatically picks a source address for installed routes in the
appropriate subnet. This is perfectly fine for most setups. If it is
not, you might consider disabling automatic route installation and use
fixed routes or the updown script to install custom routes.

 12[ENC] parsed IKE_AUTH response 1 [ N(AUTH_FAILED) ]
 12[IKE] received AUTHENTICATION_FAILED notify error

 06[IKE] sending retransmit 1 of request message ID 0, seq 1
 06[NET] sending packet: from 37.247.54.124[500] to 87.117.195.92[500] (220 
 bytes)

Not sure how that AUTH_FAILED is related. That retransmission is for a
different configuration?

 Is this is related to the NO_PROPOSAL_CHOSEN line ?

NO_PROPOSAL_CHOSEN is sent because the peer addresses don't match your
configuration, see above.

 03[ENC] parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) 
 N(MULT_AUTH) ]

 indicate charon thinks NAT is in play, as it isn't at either end

No, these payloads are used to check if there is any NAT situation, not
after one has been detected.

Regards
Martin

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

[strongSwan] (no subject)

[Dean Smith]

I run a number of linux boxes on various VPS providers that use IPsec
to connect tunnelled ip interfaces which then run OSPF.

This setup has work fine for a number of years.

Recently my systems seem to have upgraded from 5.0.4 to 5.1.1 and
everything has stopped working, a few connection will come up but most
won't.

All configs are under puppet management and therefore I am sure they
have not changed.

For example between hosts corgi and prom

[root@corgi:~] # cat /etc/strongswan/ipsec.conf
# /etc/ipsec.conf - strongSwan IPsec configuration file
# Following need to go in setup part
# plutodebug=ike 2,knl 2,net 2
# charondebug=ike 2,knl 2,net 2

config setup
charonstart=yes
plutostart=yes
plutodebug=ike 0,knl 0,net 0
charondebug=ike 0,knl 0,net 0

conn %default
ikelifetime=60m
keylife=20m
rekeymargin=3m
keyingtries=1
keyexchange=ikev2
mobike=no
authby=psk
dpdaction=restart
closeaction=restart
dpddelay=30s
dpdtimeout=150s

include /etc/strongswan/*.conn.conf

[root@corgi:~] # cat /etc/strongswan/corgi-prom.conn.conf

conn corgi-prom
auto=route
left=%defaultroute
leftid=@corgi.zelotus.com
leftsourceip=10.7.1.11
leftsubnet=10.7.1.11/32
leftprotoport=gre
lefthostaccess=yes
right=37.247.54.124
rightid=@prom.zelotus.com
rightsourceip=10.7.1.10
rightsubnet=10.7.1.10/32
righthostaccess=yes
type=tunnel
rightprotoport=gre
keyexchange=ikev2
[root@corgi:~] #







[root@prom:~] # cat /etc/strongswan/ipsec.conf
# /etc/ipsec.conf - strongSwan IPsec configuration file
# Following need to go in setup part
# plutodebug=ike 2,knl 2,net 2
# charondebug=ike 2,knl 2,net 2

config setup
charonstart=yes
plutostart=yes
plutodebug=all
charondebug=all

conn %default
ikelifetime=60m
keylife=20m
rekeymargin=3m
keyingtries=1
keyexchange=ikev2
mobike=no
authby=secret
dpdaction=restart
closeaction=restart
dpddelay=30s
dpdtimeout=150s

include /etc/strongswan/*.conn.conf

[root@prom:~] # cat /etc/strongswan/prom-corgi.conn.conf

conn prom-corgi
auto=route
left=%defaultroute
leftid=@prom.zelotus.com
leftsourceip=10.7.1.10
leftsubnet=10.7.1.10/32
leftprotoport=gre
lefthostaccess=yes
right=185.35.77.128
rightid=@corgi.zelotus.com
rightsourceip=10.7.1.11
rightsubnet=10.7.1.11/32
righthostaccess=yes
type=tunnel
rightprotoport=gre
keyexchange=ikev2
[root@prom:~] #




[root@prom:~] # strongswan up prom-corgi
[root@prom:~] # tail -100 /var/log/messages
.
.
.
Feb  9 20:41:36 prom.zelotus.com charon: 07[IKE] giving up after 5 retransmits
Feb  9 20:41:36 prom.zelotus.com charon: 07[IKE] establishing IKE_SA
failed, peer not responding
Feb  9 20:41:41 prom.zelotus.com charon: 12[KNL] creating acquire job
for policy 10.7.1.10/32[gre] === 10.7.1.9/32[gre] with reqid {2}
Feb  9 20:41:41 prom.zelotus.com charon: 12[IKE] initiating Main Mode
IKE_SA prom-lfc[21] to 38.109.218.26
Feb  9 20:41:41 prom.zelotus.com charon: 12[ENC] generating ID_PROT
request 0 [ SA V V V V ]
Feb  9 20:41:41 prom.zelotus.com charon: 12[NET] sending packet: from
37.247.54.124[500] to 38.109.218.26[500] (220 bytes)
Feb  9 20:41:41 prom.zelotus.com charon: 07[KNL] creating acquire job
for policy 10.7.1.10/32[gre] === 10.7.1.11/32[gre] with reqid {3}
Feb  9 20:41:41 prom.zelotus.com charon: 07[IKE] initiating IKE_SA
prom-corgi[22] to 185.35.77.128
Feb  9 20:41:41 prom.zelotus.com charon: 08[KNL] creating acquire job
for policy 10.7.1.10/32[gre] === 10.7.1.4/32[gre] with reqid {1}
Feb  9 20:41:41 prom.zelotus.com charon: 16[IKE] initiating Main Mode
IKE_SA prom-vm-gateway[23] to 87.117.195.92
Feb  9 20:41:41 prom.zelotus.com charon: 16[ENC] generating ID_PROT
request 0 [ SA V V V V ]
Feb  9 20:41:41 prom.zelotus.com charon: 16[NET] sending packet: from
37.247.54.124[500] to 87.117.195.92[500] (220 bytes)
Feb  9 20:41:41 prom.zelotus.com charon: 07[ENC] generating
IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
Feb  9 20:41:41 prom.zelotus.com charon: 07[NET] sending packet: from
37.247.54.124[500] to 185.35.77.128[500] (708 bytes)
Feb  9 20:41:41 prom.zelotus.com charon: 03[NET] received packet: from
185.35.77.128[500] to 37.247.54.124[500] (440 bytes)
Feb  9 20:41:41 prom.zelotus.com charon: 03[ENC] parsed IKE_SA_INIT
response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(MULT_AUTH) ]
Feb  9 20:41:41 prom.zelotus.com charon: 03[IKE] authentication of
'prom.zelotus.com' (myself) with pre-shared key
Feb  9 20:41:41 prom.zelotus.com charon: 03[IKE] establishing CHILD_SA
prom-corgi{3}
Feb  9 20:41:41 prom.zelotus.com charon: 03[ENC] generating IKE_AUTH
request 1 [ IDi N(INIT_CONTACT) IDr AUTH SA TSi TSr N(MULT_AUTH)
N(EAP_ONLY) ]
Feb  9 20:41:41 prom.zelotus.com charon: 03[NET] sending packet: from
37.247.54.124[500] to 185.35.77.128[500] (428 bytes)
Feb  9 20:41:41 prom.zelotus.com charon: 05[NET] received packet: from

[strongSwan] (no subject)

[nagaraj]

HostA-GW1==GW2---HostB

HostA:
   ipadress: 192.167.2.2/24

GW1:
   ipaddress
  etho: 192.167.2.180/24
 eth1: 192.167.21.1/24
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] (no subject)

[Hafeez Rehman]

Hi,

I am using strongSwan on openwrt 10.0.3.1-rc4.

I am tryting to connect using using iphone and snow leopard using built in 
cisco client, but I get the same error. 

I am able to connect using ipsec/l2tp on both the devices. I am also able to 
connect using cisco client using windows os.

I followed the direction on the following page which allowed me to connect 
using cisco client using windows.

http://wiki.strongswan.org/projects/strongswan/wiki/IOS_%28Apple%29

root@OpenWrt:~# ipsec version
Linux strongSwan U4.3.7/K2.6.32.25
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil, Switzerland
See 'ipsec --copyright' for copyright information.


config setup
nat_traversal=yes
charonstart=no
plutostart=yes

conn L2TP
authby=psk
pfs=no
rekey=no
type=tunnel
esp=aes128-sha1
ike=aes128-sha-modp1024
left=%defaultroute
leftprotoport=17/1701
right=%any
rightprotoport=17/%any
rightsubnetwithin=0.0.0.0/0
auto=add

conn cisco
keyexchange=ikev1
authby=xauthrsasig
xauth=server
left=%defaultroute
leftsubnet=0.0.0.0/0
leftfirewall=yes
leftcert=serverCert.pem
right=%any
rightsubnet=192.168.168.0/24
rightsourceip=192.168.168.2
rightcert=clientCert.pem
pfs=no
auto=add



Jun  9 09:44:21 OpenWrt authpriv.warn pluto[1538]: packet from 
208.54.35.143:6720: received Vendor ID payload [RFC 3947]
Jun  9 09:44:21 OpenWrt authpriv.warn pluto[1538]: packet from 
208.54.35.143:6720: ignoring Vendor ID payload 
[4df37928e9fc4fd1b3262170d515c662]
Jun  9 09:44:21 OpenWrt authpriv.warn pluto[1538]: packet from 
208.54.35.143:6720: ignoring Vendor ID payload 
[8f8d83826d246b6fc7a8a6a428c11de8]
Jun  9 09:44:21 OpenWrt authpriv.warn pluto[1538]: packet from 
208.54.35.143:6720: ignoring Vendor ID payload 
[439b59f8ba676c4c7737ae22eab8f582]
Jun  9 09:44:21 OpenWrt authpriv.warn pluto[1538]: packet from 
208.54.35.143:6720: ignoring Vendor ID payload 
[4d1e0e136deafa34c4f3ea9f02ec7285]
Jun  9 09:44:21 OpenWrt authpriv.warn pluto[1538]: packet from 
208.54.35.143:6720: ignoring Vendor ID payload 
[80d0bb3def54565ee84645d4c85ce3ee]
Jun  9 09:44:21 OpenWrt authpriv.warn pluto[1538]: packet from 
208.54.35.143:6720: ignoring Vendor ID payload 
[9909b64eed937c6573de52ace952fa6b]
Jun  9 09:44:21 OpenWrt authpriv.warn pluto[1538]: packet from 
208.54.35.143:6720: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
Jun  9 09:44:21 OpenWrt authpriv.warn pluto[1538]: packet from 
208.54.35.143:6720: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]
Jun  9 09:44:21 OpenWrt authpriv.warn pluto[1538]: packet from 
208.54.35.143:6720: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
Jun  9 09:44:21 OpenWrt authpriv.warn pluto[1538]: packet from 
208.54.35.143:6720: received Vendor ID payload [XAUTH]
Jun  9 09:44:21 OpenWrt authpriv.warn pluto[1538]: cisco[2] 
208.54.35.143:6720 #2: NAT-Traversal: Result using RFC 3947: peer is NATed
Jun  9 09:44:25 OpenWrt authpriv.warn pluto[1538]: cisco[2] 
208.54.35.143:6720 #2: ignoring informational payload, type 
IPSEC_INITIAL_CONTACT
Jun  9 09:44:25 OpenWrt authpriv.warn pluto[1538]: cisco[2] 
208.54.35.143:6720 #2: Peer ID is ID_DER_ASN1_DN: 'C=US, O=strongSwan, 
CN=client'
Jun  9 09:44:25 OpenWrt authpriv.warn pluto[1538]: cisco[2] 
208.54.35.143:6720 #2: crl not found
Jun  9 09:44:25 OpenWrt authpriv.warn pluto[1538]: cisco[2] 
208.54.35.143:6720 #2: certificate status unknown
Jun  9 09:44:25 OpenWrt authpriv.warn pluto[1538]: cisco[2] 
208.54.35.143:6720 #2: we have a cert and are sending it upon request
Jun  9 09:44:26 OpenWrt authpriv.debug pluto[1538]: | NAT-T: new mapping 
208.54.35.143:6720/32850)
Jun  9 09:44:26 OpenWrt authpriv.warn pluto[1538]: cisco[2] 
208.54.35.143:32850 #2: sent MR3, ISAKMP SA established
Jun  9 09:44:26 OpenWrt authpriv.warn pluto[1538]: cisco[2] 
208.54.35.143:32850 #2: sending XAUTH request
Jun  9 09:44:26 OpenWrt authpriv.warn pluto[1538]: packet from 
208.54.35.143:32850: Informational Exchange is for an unknown (expired?) SA

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

Re: [strongSwan] (no subject)

[Michael Sneed]

Thanks.  Looks like you are correct.  I'm using CentOS 5.5, and no elliptic 
curve algorthms are listed in
the openssl list-* commands.  So apprently elliptic curve is disabled .

Regards,

Mike

 Date: Thu, 21 Oct 2010 23:02:58 +0200
 From: andreas.stef...@strongswan.org
 To: sneedm...@hotmail.com
 CC: users@lists.strongswan.org
 Subject: Re: [strongSwan] (no subject)
 
 Yeah, this is strange indeed. Have Elliptic Curves been enabled in
 libcrypto.so-0.9.8e ? We know of some Linux distributions where this
 hasn't been the case.
 
 Regards
 
 Andreas
 
 On 21.10.2010 20:24, Michael Sneed wrote:
  Hi,
  
  I am having problems getting StrongSwan to use ECP algorithms.  I built
  with:
  
  ./configure --prefix /usr --sysconfdir=/etc --libexecdir=/usr/libexec
  --enable-openssl
  
  But when I try to bring up a connection specifying:
  
  ike=aes128-sha256-ecp256!
  esp=aes128gcm16!
  
  I get:
  
  002 suiteB #1: initiating Main Mode
  002 suiteB #1: ike alg: dh group ECP_256 not present
  003 suiteB #1: empty ISAKMP SA proposal to send (no algorithms for ike
  selection?)
  
  The openssl plugin appears to be loaded, as  ipsec statusall shows:
  
  000 loaded plugins: aes des sha1 sha2 md5 random x509 pubkey pkcs1 pgp
  dnskey pem openssl hmac gmp xauth attr resolve
  
  But the algorithms don't show up in ipsec listalgs:
  
  000   encryption: BLOWFISH_CBC 3DES_CBC AES_CBC CAMELLIA_CBC
  000   integrity:  HMAC_MD5 HMAC_SHA1 HMAC_SHA2_256 HMAC_SHA2_384
  HMAC_SHA2_512
  000   dh-group:   MODP_1024 MODP_1536 MODP_2048 MODP_3072 MODP_4096
  MODP_6144 MODP_8192 MODP_1024_160 MODP_2048_224 MODP_2048_256
  
  My  kernel is 2.6.18 and I am using libcrypto.so.0.9.8e .
  
  What am I doing wrong?
  
  Regards,
  
  Mike
 
 ==
 Andreas Steffen andreas.stef...@strongswan.org
 strongSwan - the Linux 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

[strongSwan] (no subject)

[Michael Sneed]

Hi,

I am having problems getting StrongSwan to use ECP algorithms.  I built with:

./configure --prefix /usr --sysconfdir=/etc --libexecdir=/usr/libexec 
--enable-openssl

But when I try to bring up a connection specifying:

ike=aes128-sha256-ecp256!
esp=aes128gcm16!

I get:

002 suiteB #1: initiating Main Mode
002 suiteB #1: ike alg: dh group ECP_256 not present
003 suiteB #1: empty ISAKMP SA proposal to send (no algorithms for ike 
selection?)

The openssl plugin appears to be loaded, as  ipsec statusall shows:

000 loaded plugins: aes des sha1 sha2 md5 random x509 pubkey pkcs1 pgp dnskey 
pem openssl hmac gmp xauth attr resolve 

But the algorithms don't show up in ipsec listalgs:

000   encryption: BLOWFISH_CBC 3DES_CBC AES_CBC CAMELLIA_CBC
000   integrity:  HMAC_MD5 HMAC_SHA1 HMAC_SHA2_256 HMAC_SHA2_384 HMAC_SHA2_512
000   dh-group:   MODP_1024 MODP_1536 MODP_2048 MODP_3072 MODP_4096 MODP_6144 
MODP_8192 MODP_1024_160 MODP_2048_224 MODP_2048_256

My  kernel is 2.6.18 and I am using libcrypto.so.0.9.8e .

What am I doing wrong?

Regards,

Mike








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

Re: [strongSwan] (no subject)

[Andreas Steffen]

Yeah, this is strange indeed. Have Elliptic Curves been enabled in
libcrypto.so-0.9.8e ? We know of some Linux distributions where this
hasn't been the case.

Regards

Andreas

On 21.10.2010 20:24, Michael Sneed wrote:
 Hi,
 
 I am having problems getting StrongSwan to use ECP algorithms.  I built
 with:
 
 ./configure --prefix /usr --sysconfdir=/etc --libexecdir=/usr/libexec
 --enable-openssl
 
 But when I try to bring up a connection specifying:
 
 ike=aes128-sha256-ecp256!
 esp=aes128gcm16!
 
 I get:
 
 002 suiteB #1: initiating Main Mode
 002 suiteB #1: ike alg: dh group ECP_256 not present
 003 suiteB #1: empty ISAKMP SA proposal to send (no algorithms for ike
 selection?)
 
 The openssl plugin appears to be loaded, as  ipsec statusall shows:
 
 000 loaded plugins: aes des sha1 sha2 md5 random x509 pubkey pkcs1 pgp
 dnskey pem openssl hmac gmp xauth attr resolve
 
 But the algorithms don't show up in ipsec listalgs:
 
 000   encryption: BLOWFISH_CBC 3DES_CBC AES_CBC CAMELLIA_CBC
 000   integrity:  HMAC_MD5 HMAC_SHA1 HMAC_SHA2_256 HMAC_SHA2_384
 HMAC_SHA2_512
 000   dh-group:   MODP_1024 MODP_1536 MODP_2048 MODP_3072 MODP_4096
 MODP_6144 MODP_8192 MODP_1024_160 MODP_2048_224 MODP_2048_256
 
 My  kernel is 2.6.18 and I am using libcrypto.so.0.9.8e .
 
 What am I doing wrong?
 
 Regards,
 
 Mike

==
Andreas Steffen andreas.stef...@strongswan.org
strongSwan - the Linux 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

[strongSwan] (no subject)

[pdaum]

I am experiencing a problem connecting a Funkwerk EC VPN25 router (VPN Access 
25 version V.7.4 Rev. 1 (Patch 11) with StrongSwan (Linux strongSwan 
U4.3.2/K2.6.32-22-generic) gateway.

The (StrongSwan) gateway S has a fixed IP address, the router R has a 
dynamic one, provided by DynDNS. After an ipsec update has been issued on S, 
S has the current address of R and the establishment of a VPN connection works 
in both directions, i.e. S as well as R can bring up a connection. 

If the IP address of R changes (e.g. after re-establishment of the connection), 
S does not get aware of the new address. Accordingly, S cannot initiate a 
connection, as expected. However, R can still connect to S as the IP address of 
the latter has not changed. Unfortunately, R's connection request is refused by 
S with the error message no connection has been authorized with policy=PUBKEY 
(full log below). It seems that the first package of R does not give any 
indication of R's identity and is subsequently refused by S.

The strange thing is, that I have 2 other locations with Funkwerk routers (same 
config, same software version, albeit another model) where the scenario 
described above works perfectly. 

I am now looking for a reason. As the two working locations are connected 
through another ISP (Colt), I am wondering if there is something special with 
the internet connection at the troubled location(green.ch). Could a too small 
MTU cause problems? Also, R is not directly connected to the internet, having a 
Zyxel ADSL modem between (as bridge).

Any ideas how to analyse (and eventually solve) the problem are appreciated.

Best regards
Peter

Log of failed connection attempt (S):

Jun 13 16:11:50 router pluto[899]: | 
Jun 13 16:11:50 router pluto[899]: | *received 124 bytes from 
xxx.yyy.98.213:610 on eth0:1
Jun 13 16:11:50 router pluto[899]: |   18 f2 ee 24  6b d2 49 c9  00 00 00 00  
00 00 00 00
Jun 13 16:11:50 router pluto[899]: |   01 10 02 00  00 00 00 00  00 00 00 7c  
0d 00 00 38
Jun 13 16:11:50 router pluto[899]: |   00 00 00 01  00 00 00 01  00 00 00 2c  
00 01 00 01
Jun 13 16:11:50 router pluto[899]: |   00 00 00 24  00 01 00 00  80 01 00 07  
80 0e 00 80
Jun 13 16:11:50 router pluto[899]: |   80 02 00 02  80 03 00 03  80 04 00 05  
80 0b 00 01
Jun 13 16:11:50 router pluto[899]: |   80 0c 03 84  0d 00 00 14  00 48 e2 27  
0b ea 83 95
Jun 13 16:11:50 router pluto[899]: |   ed 77 8d 34  3c c2 a0 76  00 00 00 14  
af ca d7 13
Jun 13 16:11:50 router pluto[899]: |   68 a1 f1 c9  6b 86 96 fc  77 57 01 00
Jun 13 16:11:50 router pluto[899]: | **parse ISAKMP Message:
Jun 13 16:11:50 router pluto[899]: |initiator cookie:
Jun 13 16:11:50 router pluto[899]: |   18 f2 ee 24  6b d2 49 c9
Jun 13 16:11:50 router pluto[899]: |responder cookie:
Jun 13 16:11:50 router pluto[899]: |   00 00 00 00  00 00 00 00
Jun 13 16:11:50 router pluto[899]: |next payload type: ISAKMP_NEXT_SA
Jun 13 16:11:50 router pluto[899]: |ISAKMP version: ISAKMP Version 1.0
Jun 13 16:11:50 router pluto[899]: |exchange type: ISAKMP_XCHG_IDPROT
Jun 13 16:11:50 router pluto[899]: |flags: none
Jun 13 16:11:50 router pluto[899]: |message ID:  00 00 00 00
Jun 13 16:11:50 router pluto[899]: |length: 124
Jun 13 16:11:50 router pluto[899]: | ***parse ISAKMP Security Association 
Payload:
Jun 13 16:11:50 router pluto[899]: |next payload type: ISAKMP_NEXT_VID
Jun 13 16:11:50 router pluto[899]: |length: 56
Jun 13 16:11:50 router pluto[899]: |DOI: ISAKMP_DOI_IPSEC
Jun 13 16:11:50 router pluto[899]: | ***parse ISAKMP Vendor ID Payload:
Jun 13 16:11:50 router pluto[899]: |next payload type: ISAKMP_NEXT_VID
Jun 13 16:11:50 router pluto[899]: |length: 20
Jun 13 16:11:50 router pluto[899]: | ***parse ISAKMP Vendor ID Payload:
Jun 13 16:11:50 router pluto[899]: |next payload type: ISAKMP_NEXT_NONE
Jun 13 16:11:50 router pluto[899]: |length: 20
Jun 13 16:11:50 router pluto[899]: packet from xxx.yyy.98.213:610: ignoring 
Vendor ID payload [0048e2270bea8395ed778d343cc2a076]
Jun 13 16:11:50 router pluto[899]: packet from xxx.yyy.98.213:610: received 
Vendor ID payload [Dead Peer Detection]
Jun 13 16:11:50 router pluto[899]: | parse IPsec DOI SIT:
Jun 13 16:11:50 router pluto[899]: |IPsec DOI SIT: SIT_IDENTITY_ONLY
Jun 13 16:11:50 router pluto[899]: | parse ISAKMP Proposal Payload:
Jun 13 16:11:50 router pluto[899]: |next payload type: ISAKMP_NEXT_NONE
Jun 13 16:11:50 router pluto[899]: |length: 44
Jun 13 16:11:50 router pluto[899]: |proposal number: 0
Jun 13 16:11:50 router pluto[899]: |protocol ID: PROTO_ISAKMP
Jun 13 16:11:50 router pluto[899]: |SPI size: 0
Jun 13 16:11:50 router pluto[899]: |number of transforms: 1
Jun 13 16:11:50 router pluto[899]: | *parse ISAKMP Transform Payload 
(ISAKMP):
Jun 13 16:11:50 router pluto[899]: |next payload type: ISAKMP_NEXT_NONE
Jun 13 16:11:50 router pluto[899]: |length: 36
Jun 13 16:11:50 router pluto[899]: |transform number: 0

Re: [strongSwan] (no subject)

[Andreas Steffen]

Hello Peter,

have you tried to set

  right=r.dyndns.org
  rightallowany=yes

or more concise

  right=%r.dyndns.org

which will resolve the hostname r.dyndns.org during an ipsec update
allowing S to initiate the connection but will also accept any
changed IP address R as a responder. The rightallowany parameter
was introduced a couple of years ago to just cover this DynDNS
scenario.

Regards

Andreas

On 06/14/2010 10:20 PM, pd...@gmx.de wrote:
 I am experiencing a problem connecting a Funkwerk EC VPN25 router
 (VPN Access 25 version V.7.4 Rev. 1 (Patch 11) with StrongSwan (Linux
 strongSwan U4.3.2/K2.6.32-22-generic) gateway.
 
 The (StrongSwan) gateway S has a fixed IP address, the router R
 has a dynamic one, provided by DynDNS. After an ipsec update has
 been issued on S, S has the current address of R and the
 establishment of a VPN connection works in both directions, i.e. S as
 well as R can bring up a connection.
 
 If the IP address of R changes (e.g. after re-establishment of the
 connection), S does not get aware of the new address. Accordingly, S
 cannot initiate a connection, as expected. However, R can still
 connect to S as the IP address of the latter has not changed.
 Unfortunately, R's connection request is refused by S with the error
 message no connection has been authorized with policy=PUBKEY (full
 log below). It seems that the first package of R does not give any
 indication of R's identity and is subsequently refused by S.
 
 The strange thing is, that I have 2 other locations with Funkwerk
 routers (same config, same software version, albeit another model)
 where the scenario described above works perfectly.
 
 I am now looking for a reason. As the two working locations are
 connected through another ISP (Colt), I am wondering if there is
 something special with the internet connection at the troubled
 location(green.ch). Could a too small MTU cause problems? Also, R is
 not directly connected to the internet, having a Zyxel ADSL modem
 between (as bridge).
 
 Any ideas how to analyse (and eventually solve) the problem are
 appreciated.
 
 Best regards Peter
 
==
Andreas Steffen andreas.stef...@strongswan.org
strongSwan - the Linux VPN Solution!www.strongswan.org
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===[ITA-HSR]==



smime.p7s
Description: S/MIME Cryptographic Signature
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] (no subject)

[Jan Luca Naumann]

Hi, 

I have opened the ports in the LANKOM. 

Viele Grüße Jan

Von: Andreas Steffen [andreas.stef...@strongswan.org]
Gesendet: Samstag, 28. November 2009 14:58
An: Jan Luca Naumann
Cc: users@lists.strongswan.org
Betreff: Re: [strongSwan] Problems with conneting to stongSwan server from Win 7

Hi Jan,

if the strongSwan server is a passive responder behind a
NAT router it is not sufficient to just open ports 500
and 4500 on the LANCOM router. You must also activate
port forwarding which forwards ports 500/4500 of the
LANCOM router to ports 500/4500 of the strongSwan gateway.

Best regards

Andreas

BTW - nat_traversal=yes is not required with IKEv2
  since NAT traversal is always activated by default
  and cannot be disabled.

Jan Luca wrote:
 Hello,

 I have install a strongSwan server with this ipsec.conf:

 # /etc/ipsec.conf - strongSwan IPsec configuration file

 config setup
plutostart=no
nat_traversal=yes

 conn test
left=%any
leftcert=Name of cert of strongSwan
leftsubnet=192.168.5.0/24
right=%any
rightsourceip=192.168.254.1
rightid=Cert Details
auto=add
keyexchange=ikev2

 ipsec.secrets:

 : RSA Name of the key pass

 The server is after a NAT of a LANCOM 1821 (LANCOM 1821 Wireless ADSL
 (Ann.B) 3.36.0026 / 18.05.2004). I open the ports 500 and 4500.

 So now I try to connect to the server with a Win 7 client, but it don't get
 a connection (server not found). What do I wrong?

 Viele Grüße
 Jan

==
Andreas Steffen andreas.stef...@strongswan.org
strongSwan - the Linux 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

Re: [strongSwan] (no subject)

[Andreas Steffen]

Hi Keith,

the problem is on the other side because the peer is not
responding. Do you have any logs from the peer side?

Andreas

Keith Smith wrote:
 Hey folks,
  
 I'm a complete newbie who has inherited this IpSec solution from my
 predecessor.
 I have two working tunnels and one which fails.
 It failed after my colleague restarted ISECP on the firewall/vpn box on
 Gentoo.
  
 The error I get from ipsec status is
 
 000 bir-ams:
 xx.xx.xx.xx/24===xx.xx.xx.xx.---xx.xx.xx.xx...xx.xx.xx.xx---xx.xx.xx.xx===
 xx.xx.xx.xx/16; erouted HOLD; eroute owner: #0
 000 bir-ams:   ike_life: 28800s; ipsec_life: 1800s; rekey_margin: 180s;
 rekey_fuzz: 33%; keyingtries: 0
 000 bir-ams:   policy: PSK+ENCRYPT+TUNNEL+UP; prio: 24,16; interface:
 eth1;
 000 bir-ams:   newest ISAKMP SA: #0; newest IPsec SA: #0;
 000 bir-ams:   IKE algorithms wanted: 5_000-2-5, 5_000-2-2, 5_000-1-5,
 5_000-1-2,
 000 bir-ams:   IKE algorithms found:  5_192-2_160-5, 5_192-2_160-2,
 5_192-1_128-5, 5_192-1_128-2,
 000 bir-ams:   ESP algorithms wanted: 3_000-1, 3_000-2,
 000 bir-ams:   ESP algorithms loaded: 3_192-1_128, 3_192-2_160,
  
 the line IKE newest is missing if I compare with a working tunnel
  
 My firewall log shoes me that 
  max number of retransmissions (2) reached STATE_MAIN_I1.  No response (or
 no acceptable response) to our first IKE message
  
 So I know it's failing at an early stage of negotiation.
 Please help.
 are there any debugging options I can use that will give me more data so I
 can tell exactly where the failure occurs.
  
 Thanks in advance

==
Andreas Steffen andreas.stef...@strongswan.org
strongSwan - the Linux 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

[strongSwan] (no subject)

[Yutaka Ibuki]

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