subject:"\[strongSwan\] Not Able to Connect"

Re: [strongSwan] Not Able to Connect

2018-03-29 Thread Andreas Steffen

Hi,

if you want static virtual IPs then you can use one of the following two
mechanism:


https://www.strongswan.org/testing/testresults/ikev2/dhcp-static-client-id/

or

  https://www.strongswan.org/testing/testresults/ikev2/dhcp-static-mac/

Just have a look at the console log how the DHCP server has to
be configured.

Regards

Andreas

On 29.03.2018 20:12, Info wrote:
> 
> On 03/29/2018 10:21 AM, Andreas Steffen wrote:
>> Hi,
>>
>> yes you can fully integrate a remote host into a LAN by using the
>> farp and dhcp plugins on the VPN gateway so that the gateway
>> acts as an ARP proxy for the remote clients. Have a look at the
>> following example scenario based on swanctl:
>>
>>   https://www.strongswan.org/testing/testresults/swanctl/dhcp-dynamic/
>>
>> In swanctl.conf
>>
>>
>> https://www.strongswan.org/testing/testresults/swanctl/dhcp-dynamic/moon.swanctl.conf
>>
>> use pools = dhcp and in strongswan.conf
>>
>>
>> https://www.strongswan.org/testing/testresults/swanctl/dhcp-dynamic/moon.strongswan.conf
>>
>> define the DCHP server to be used.
>>
>> Regards
>>
>> Andreas
> Thanks Andreas.  You likely know (but for the benefit of others), things
> are done differently in RHEL.  For the plugins normally loaded by
> /etc/strongswan/strongswan.conf, in the case of RHEL there's just a call to:
> charon {
>     load_modular = yes
>     plugins {
>     include strongswan.d/charon/*.conf
>     }
> }
> 
> ... and in that directory there's a .conf for each plugin.  Given the
> charon.log, all required plugins are already being loaded without my
> intervention (at least for charon, Idk about swanctl), including farp
> and dhcp.  Since I no longer use the stroke plugin I set in its .conf
> file load = no.  And in dhcp.conf I set  server = 192.168.1.10 which
> will be the LAN DHCP server.
> 
> Thing is since I run servers I've always used static IPs, so I'll have
> to figure out DHCP predictable assignment.  But with the transition to
> IPV6 I will be using DHCP exclusively. (for the love of all that's holy)
> 
> 
> 
> 
> 

-- 
==
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] Not Able to Connect

2018-03-29 Thread Info

On 03/29/2018 10:21 AM, Andreas Steffen wrote:
> Hi,
>
> yes you can fully integrate a remote host into a LAN by using the
> farp and dhcp plugins on the VPN gateway so that the gateway
> acts as an ARP proxy for the remote clients. Have a look at the
> following example scenario based on swanctl:
>
>   https://www.strongswan.org/testing/testresults/swanctl/dhcp-dynamic/
>
> In swanctl.conf
>
>
> https://www.strongswan.org/testing/testresults/swanctl/dhcp-dynamic/moon.swanctl.conf
>
> use pools = dhcp and in strongswan.conf
>
>
> https://www.strongswan.org/testing/testresults/swanctl/dhcp-dynamic/moon.strongswan.conf
>
> define the DCHP server to be used.
>
> Regards
>
> Andreas
Thanks Andreas.  You likely know (but for the benefit of others), things
are done differently in RHEL.  For the plugins normally loaded by
/etc/strongswan/strongswan.conf, in the case of RHEL there's just a call to:
charon {
    load_modular = yes
    plugins {
    include strongswan.d/charon/*.conf
    }
}

... and in that directory there's a .conf for each plugin.  Given the
charon.log, all required plugins are already being loaded without my
intervention (at least for charon, Idk about swanctl), including farp
and dhcp.  Since I no longer use the stroke plugin I set in its .conf
file load = no.  And in dhcp.conf I set  server = 192.168.1.10 which
will be the LAN DHCP server.

Thing is since I run servers I've always used static IPs, so I'll have
to figure out DHCP predictable assignment.  But with the transition to
IPV6 I will be using DHCP exclusively. (for the love of all that's holy)

Re: [strongSwan] Not Able to Connect

2018-03-29 Thread Andreas Steffen

Hi,

yes you can fully integrate a remote host into a LAN by using the
farp and dhcp plugins on the VPN gateway so that the gateway
acts as an ARP proxy for the remote clients. Have a look at the
following example scenario based on swanctl:

  https://www.strongswan.org/testing/testresults/swanctl/dhcp-dynamic/

In swanctl.conf


https://www.strongswan.org/testing/testresults/swanctl/dhcp-dynamic/moon.swanctl.conf

use pools = dhcp and in strongswan.conf


https://www.strongswan.org/testing/testresults/swanctl/dhcp-dynamic/moon.strongswan.conf

define the DCHP server to be used.

Regards

Andreas

On 29.03.2018 18:57, Info wrote:
> True.  Although I infer that 'pools' might be address pools (as with
> DHCP), I can find no evidence of this.  And I now notice the 'pools'
> definition further down.
> 
> But I'd like this VPN to be 'transparent'.  IOW I'd like my remote
> machines and LAN members to use the same IP as they do in the LAN.  If
> possible I'd like to avoid virtual IPs.  Is there any way to do this?
> 
> And I gather that in the IPSec gateway for the LAN, I can define
> different definitions for different remote machines, but I can't work
> out how this would be structured with swanctl.  I'd actually prefer to
> keep the same definition for all remote initiators, but things may not
> always work out like we want.
> 
> Side question:  I'm also in the process of transitioning the LAN to
> IPV6.  As my ISP will not foreseeably have IPV6 (Frontier Comm)  I'll
> need to use a tunnel broker.  Will this be a problem with Strongswan,
> and can the Android app do IPV6?
> 
> 
> On 03/28/2018 02:35 PM, Andreas Steffen wrote:
>> The connection setup gets now very far but finally fails because
>> the pools defined by
>>
>>  pools = primary-pool-ipv4, primary-pool-ipv6
>>
>> don't seem be defined (have you added a pools section in swanctl.conf?)
>> and therefore no virtual IP can be allocated to the initiator
>>
>> Wed, 2018-03-28 08:31 15[IKE] 
>>   peer requested virtual IP %any
>>   no virtual IP found for %any requested by 'C=US, O=Quantum
>> CN=aries.darkmatter.org'
>>   peer requested virtual IP %any6
>>   no virtual IP found for %any6 requested by 'C=US, O=Quantum
>> CN=aries.darkmatter.org'
>>   no virtual IP found, sending INTERNAL_ADDRESS_FAILURE
>>
>> Regards
>>
>> Andreas
>>
>> On 28.03.2018 17:37, Info wrote:
>>> I have no way of interpreting the syntax of these proposals as there's
>>> no definitive description.  Maybe '-' separates different options in a
>>> category and ',' separates categories?  But it also doesn't explain
>>> "classic and combined-mode algos" nor not to mix them.  I can't know
>>> these things by instinct.
>>>
>>> Something else is wrong with the example.  I copied it -exactly- (except
>>> I used your esp_proposals), and the error log is attached.
>>>
>>>
>>>
>>> On 03/28/2018 02:21 AM, Andreas Steffen wrote:
 Hi,

 as your log explicitly says:

> Tue, 2018-03-27 15:13 15[CFG] classic and combined-mode (AEAD)
> encryption algorithms can't be contained in the same IKE proposal
 Thus instead of

 esp_proposals =
> aes192gcm16-aes128gcm16-aes192-ecp256,aes192-sha256-modp3072,default
 you must define

 esp_proposals =
   aes192gcm16-aes128gcm16-ecp256,aes192-sha256-ecp256-modp3072,default

 Regards

 Andreas

> 

-- 
==
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] Not Able to Connect

2018-03-29 Thread Info

True.  Although I infer that 'pools' might be address pools (as with
DHCP), I can find no evidence of this.  And I now notice the 'pools'
definition further down.

But I'd like this VPN to be 'transparent'.  IOW I'd like my remote
machines and LAN members to use the same IP as they do in the LAN.  If
possible I'd like to avoid virtual IPs.  Is there any way to do this?

And I gather that in the IPSec gateway for the LAN, I can define
different definitions for different remote machines, but I can't work
out how this would be structured with swanctl.  I'd actually prefer to
keep the same definition for all remote initiators, but things may not
always work out like we want.

Side question:  I'm also in the process of transitioning the LAN to
IPV6.  As my ISP will not foreseeably have IPV6 (Frontier Comm)  I'll
need to use a tunnel broker.  Will this be a problem with Strongswan,
and can the Android app do IPV6?

On 03/28/2018 02:35 PM, Andreas Steffen wrote:
> The connection setup gets now very far but finally fails because
> the pools defined by
>
>  pools = primary-pool-ipv4, primary-pool-ipv6
>
> don't seem be defined (have you added a pools section in swanctl.conf?)
> and therefore no virtual IP can be allocated to the initiator
>
> Wed, 2018-03-28 08:31 15[IKE] 
>   peer requested virtual IP %any
>   no virtual IP found for %any requested by 'C=US, O=Quantum
> CN=aries.darkmatter.org'
>   peer requested virtual IP %any6
>   no virtual IP found for %any6 requested by 'C=US, O=Quantum
> CN=aries.darkmatter.org'
>   no virtual IP found, sending INTERNAL_ADDRESS_FAILURE
>
> Regards
>
> Andreas
>
> On 28.03.2018 17:37, Info wrote:
>> I have no way of interpreting the syntax of these proposals as there's
>> no definitive description.  Maybe '-' separates different options in a
>> category and ',' separates categories?  But it also doesn't explain
>> "classic and combined-mode algos" nor not to mix them.  I can't know
>> these things by instinct.
>>
>> Something else is wrong with the example.  I copied it -exactly- (except
>> I used your esp_proposals), and the error log is attached.
>>
>>
>>
>> On 03/28/2018 02:21 AM, Andreas Steffen wrote:
>>> Hi,
>>>
>>> as your log explicitly says:
>>>
 Tue, 2018-03-27 15:13 15[CFG] classic and combined-mode (AEAD)
 encryption algorithms can't be contained in the same IKE proposal
>>> Thus instead of
>>>
>>> esp_proposals =
 aes192gcm16-aes128gcm16-aes192-ecp256,aes192-sha256-modp3072,default
>>> you must define
>>>
>>> esp_proposals =
>>>   aes192gcm16-aes128gcm16-ecp256,aes192-sha256-ecp256-modp3072,default
>>>
>>> Regards
>>>
>>> Andreas
>>>

Re: [strongSwan] Not Able to Connect

2018-03-28 Thread Andreas Steffen

The connection setup gets now very far but finally fails because
the pools defined by

 pools = primary-pool-ipv4, primary-pool-ipv6

don't seem be defined (have you added a pools section in swanctl.conf?)
and therefore no virtual IP can be allocated to the initiator

Wed, 2018-03-28 08:31 15[IKE] 
  peer requested virtual IP %any
  no virtual IP found for %any requested by 'C=US, O=Quantum
CN=aries.darkmatter.org'
  peer requested virtual IP %any6
  no virtual IP found for %any6 requested by 'C=US, O=Quantum
CN=aries.darkmatter.org'
  no virtual IP found, sending INTERNAL_ADDRESS_FAILURE

Regards

Andreas

On 28.03.2018 17:37, Info wrote:
> I have no way of interpreting the syntax of these proposals as there's
> no definitive description.  Maybe '-' separates different options in a
> category and ',' separates categories?  But it also doesn't explain
> "classic and combined-mode algos" nor not to mix them.  I can't know
> these things by instinct.
> 
> Something else is wrong with the example.  I copied it -exactly- (except
> I used your esp_proposals), and the error log is attached.
> 
> 
> 
> On 03/28/2018 02:21 AM, Andreas Steffen wrote:
>> Hi,
>>
>> as your log explicitly says:
>>
>>> Tue, 2018-03-27 15:13 15[CFG] classic and combined-mode (AEAD)
>>> encryption algorithms can't be contained in the same IKE proposal
>> Thus instead of
>>
>> esp_proposals =
>>> aes192gcm16-aes128gcm16-aes192-ecp256,aes192-sha256-modp3072,default
>> you must define
>>
>> esp_proposals =
>>   aes192gcm16-aes128gcm16-ecp256,aes192-sha256-ecp256-modp3072,default
>>
>> Regards
>>
>> Andreas
>>
> 

-- 
==
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] Not Able to Connect

2018-03-28 Thread Andreas Steffen

Hi,

as your log explicitly says:

> Tue, 2018-03-27 15:13 15[CFG] classic and combined-mode (AEAD)
> encryption algorithms can't be contained in the same IKE proposal

Thus instead of

esp_proposals =
> aes192gcm16-aes128gcm16-aes192-ecp256,aes192-sha256-modp3072,default

you must define

esp_proposals =
  aes192gcm16-aes128gcm16-ecp256,aes192-sha256-ecp256-modp3072,default

Regards

Andreas

On 28.03.2018 01:00, Info wrote:
> So using "Usable Examples", exactly as prescribed:
> 
> connections {
> 
> # Roadwarrior Responder: 
> https://wiki.strongswan.org/projects/strongswan/wiki/UsableExamples
> 
>     ikev2-pubkey {
>     version = 2
>     proposals =
> aes192gcm16-aes128gcm16-aes192-prfsha256-ecp256-ecp521,aes192-sha256-modp3072,default
>     rekey_time = 0s
>     pools = primary-pool-ipv4, primary-pool-ipv6
>     fragmentation = yes
>     dpd_delay = 30s
>     # dpd_timeout doesn't do anything for IKEv2. The general
> IKEv2 packet timeouts are used.
>     local-1 {
>     certs = cygnus-Cert.pem
>     id = cygnus.darkmatter.org
>     }
>     remote-1 {
>     # defaults are fine.
>     }
>     children {
>     ikev2-pubkey {
>     local_ts = 0.0.0.0/0,::/0
>     rekey_time = 0s
>     dpd_action = clear
>     esp_proposals =
> aes192gcm16-aes128gcm16-aes192-ecp256,aes192-sha256-modp3072,default
>     }
>     }
>     }
> }
> 
> # systemctl restart strongswan-swanctl
> 
> {Fail}
> 
> # journalctl
> 
> loading connection 'ikev2-pubkey' failed: invalid value for: proposals,
> config discarded
> 
> # cat /var/log/charon.log
> 
> Tue, 2018-03-27 15:13 15[CFG] classic and combined-mode (AEAD)
> encryption algorithms can't be contained in the same IKE proposal
> 
> So the docs are wrong.
> 
> From https://wiki.strongswan.org/projects/strongswan/wiki/Swanctlconf
> 
> connections..proposals
> 
> 
>   default
> A proposal is a set of algorithms. For non-AEAD algorithms, this
> includes for IKE an encryption algorithm, an integrity algorithm, a
> pseudo random function and a Diffie-Hellman group. For AEAD algorithms,
> instead of encryption and integrity algorithms, a combined algorithm is
> used.
> In IKEv2, multiple algorithms of the same kind can be specified in a
> single proposal, from which one gets selected. In IKEv1, only one
> algorithm per kind is allowed per proposal, more algorithms get
> implicitly stripped. Use multiple proposals to offer different
> algorithms combinations in IKEv1.
> Algorithm keywords get separated using dashes. Multiple proposals may be
> separated by commas. The special value /default/ forms a default
> proposal of supported algorithms considered safe, and is usually a good
> choice for interoperability.
> 
> 
> Ok I do not see what the goddamn problem is with this prescribed config,
> but let's comment out proposals.
> 
> connections {
> 
> # Roadwarrior Responder: 
> https://wiki.strongswan.org/projects/strongswan/wiki/UsableExamples
> 
>     ikev2-pubkey {
>     version = 2
>     #   proposals =
> aes192gcm16-aes128gcm16-aes192-prfsha256-ecp256-ecp521,aes192-sha256-modp3072,default
>     rekey_time = 0s
>     pools = primary-pool-ipv4, primary-pool-ipv6
>     fragmentation = yes
>     dpd_delay = 30s
>     # dpd_timeout doesn't do anything for IKEv2. The general
> IKEv2 packet timeouts are used.
>     local-1 {
>     certs = zeta-Cert.pem
>     id = zeta.darkmtter.org
>     }
>     remote-1 {
>     # defaults are fine.
>     }
>     children {
>     ikev2-pubkey {
>     local_ts = 0.0.0.0/0,::/0
>     rekey_time = 0s
>     dpd_action = clear
>     esp_proposals =
> aes192gcm16-aes128gcm16-aes192-ecp256,aes192-sha256-modp3072,default
>     }
>     }
>     }
> }
> 
> # systemctl restart strongswan-swanctl
> 
> {Fail}
> 
> # journalctl
> 
> Mar 27 15:20:30 zeta.darkmtter.org swanctl[64348]: loading connection
> 'ikev2-pubkey' failed: invalid value for: esp_proposals, config discarded
> 
> # cat /var/log/charon.log
> 
> Tue, 2018-03-27 15:20 16[CFG] classic and combined-mode (AEAD)
> encryption algorithms can't be contained in the same ESP proposal
> 
> Well this is bad.
> 
> From https://wiki.strongswan.org/projects/strongswan/wiki/Swanctlconf
> 
> connections..children..ah_proposals
> 
>   
> AH proposals to offer for the CHILD_SA. A proposal is a set of
> algorithms. For AH, this includes an integrit

Re: [strongSwan] Not Able to Connect

2018-03-27 Thread Info

So using "Usable Examples", exactly as prescribed:

connections {

# Roadwarrior Responder: 
https://wiki.strongswan.org/projects/strongswan/wiki/UsableExamples

    ikev2-pubkey {
    version = 2
    proposals =
aes192gcm16-aes128gcm16-aes192-prfsha256-ecp256-ecp521,aes192-sha256-modp3072,default
    rekey_time = 0s
    pools = primary-pool-ipv4, primary-pool-ipv6
    fragmentation = yes
    dpd_delay = 30s
    # dpd_timeout doesn't do anything for IKEv2. The general
IKEv2 packet timeouts are used.
    local-1 {
    certs = cygnus-Cert.pem
    id = cygnus.darkmatter.org
    }
    remote-1 {
    # defaults are fine.
    }
    children {
    ikev2-pubkey {
    local_ts = 0.0.0.0/0,::/0
    rekey_time = 0s
    dpd_action = clear
    esp_proposals =
aes192gcm16-aes128gcm16-aes192-ecp256,aes192-sha256-modp3072,default
    }
    }
    }
}

# systemctl restart strongswan-swanctl

{Fail}

# journalctl

loading connection 'ikev2-pubkey' failed: invalid value for: proposals,
config discarded

# cat /var/log/charon.log

Tue, 2018-03-27 15:13 15[CFG] classic and combined-mode (AEAD)
encryption algorithms can't be contained in the same IKE proposal

So the docs are wrong.

>From https://wiki.strongswan.org/projects/strongswan/wiki/Swanctlconf

connections..proposals


default
A proposal is a set of algorithms. For non-AEAD algorithms, this
includes for IKE an encryption algorithm, an integrity algorithm, a
pseudo random function and a Diffie-Hellman group. For AEAD algorithms,
instead of encryption and integrity algorithms, a combined algorithm is
used.
In IKEv2, multiple algorithms of the same kind can be specified in a
single proposal, from which one gets selected. In IKEv1, only one
algorithm per kind is allowed per proposal, more algorithms get
implicitly stripped. Use multiple proposals to offer different
algorithms combinations in IKEv1.
Algorithm keywords get separated using dashes. Multiple proposals may be
separated by commas. The special value /default/ forms a default
proposal of supported algorithms considered safe, and is usually a good
choice for interoperability.


Ok I do not see what the goddamn problem is with this prescribed config,
but let's comment out proposals.

connections {

# Roadwarrior Responder: 
https://wiki.strongswan.org/projects/strongswan/wiki/UsableExamples

    ikev2-pubkey {
    version = 2
    #   proposals =
aes192gcm16-aes128gcm16-aes192-prfsha256-ecp256-ecp521,aes192-sha256-modp3072,default
    rekey_time = 0s
    pools = primary-pool-ipv4, primary-pool-ipv6
    fragmentation = yes
    dpd_delay = 30s
    # dpd_timeout doesn't do anything for IKEv2. The general
IKEv2 packet timeouts are used.
    local-1 {
    certs = zeta-Cert.pem
    id = zeta.darkmtter.org
    }
    remote-1 {
    # defaults are fine.
    }
    children {
    ikev2-pubkey {
    local_ts = 0.0.0.0/0,::/0
    rekey_time = 0s
    dpd_action = clear
    esp_proposals =
aes192gcm16-aes128gcm16-aes192-ecp256,aes192-sha256-modp3072,default
    }
    }
    }
}

# systemctl restart strongswan-swanctl

{Fail}

# journalctl

Mar 27 15:20:30 zeta.darkmtter.org swanctl[64348]: loading connection
'ikev2-pubkey' failed: invalid value for: esp_proposals, config discarded

# cat /var/log/charon.log

Tue, 2018-03-27 15:20 16[CFG] classic and combined-mode (AEAD)
encryption algorithms can't be contained in the same ESP proposal

Well this is bad.

>From https://wiki.strongswan.org/projects/strongswan/wiki/Swanctlconf

connections..children..ah_proposals


AH proposals to offer for the CHILD_SA. A proposal is a set of
algorithms. For AH, this includes an integrity algorithm and an optional
Diffie-Hellman group. If a DH group is specified, CHILD_SA/Quick Mode
rekeying and initial negotiation uses a separate Diffie-Hellman exchange
using the specified group (refer to /esp_proposals/ for details).
In IKEv2, multiple algorithms of the same kind can be specified in a
single proposal, from which one gets selected. In IKEv1, only one
algorithm per kind is allowed per proposal, more algorithms get
implicitly stripped. Use multiple proposals to offer different
algorithms combinations in IKEv1.
Algorithm keywords get separated using dashes. Multiple proposals may be
separated by commas. The special value /default/ forms a default
proposal of supported

Re: [strongSwan] Not Able to Connect

2018-03-27 Thread Info

This config is supposed to work for the remote initiators to the IPSec
gateway, but I get the error I'd fought for a month.  So it does not
work.  I say again:  It does not work.

I did have a config where I could connect from the remote phone to the
IPSec gateway, but pings went out the LTE data route rather than through
the VPN, and so of course couldn't find the internal LAN.  So that does
not work.

This is one of the three "usable" swanctl configs I've tried, none of
which work for varying and inexplicable reasons.  They are not actually
"usable" configs, at least the ones specifically for IKE2 and certs. 
Now I am out of usable configs.  Why these usable configs do not work
has got to be an error which I am in no position and do not have the
tools to decrypt.  But I'm not crapping out to PSK or ipsec.conf or L2TP
like everyone else has.

There is no perspective anywhere on the mechanisms of action these
settings are supposed to do.  For some reason "remote_addrs" is
mandatory yet it is not in the usable config?  "/As responder, the
initiator source address must match at least to one of the specified
addresses, subnets or ranges./"  And so how do I set an address in this
range in the Android app?  There is no way.  Not to mention that if
"remote_addrs" is required, why is it not in the usable example?

And there are a hundred other questions which could be resolved and save
us all alot of time, if just a little perspective were given on how
these things are supposed to work, rather than a blurb here, correction
there, interspersed with ill-covered temper.  If you don't want to do
this or resent it Noel, just don't.  Either someone else will step in or
the project will die.  But don't just slap-dash it and take out your
frustrations.  Maybe this is the approach because it just makes most go
away, feeling ashamed.

I get it and accept it Noel, that you are far far smarter than I am at
this.  And I have never tried to tell you the things I'm smart at.  In
IRC (as here) you would lead me up to a point, then go cryptic like I've
almost reached success that I shouldn't have.  I am diligent, although I
can't always put my whole mind to this as I must actually make a living
while I'm doing this.  You do too, but you are not the one trying to
translate ancient Sanskrit scattered in a thousand fragments, with an
encrypted Rosetta Stone.

On 03/27/2018 12:23 PM, Noel Kuntze wrote:
> Of course not, you didn't do what I wrote.
>
> You need two conns.
> One for your host-to-host scenario and one for the initiators from the 
> internet. What you previously had worked for the host-to-host scenario.
>
> On 27.03.2018 21:20, Info wrote:
>> Back to this from the very beginning.
>>
>> Tue, 2018-03-27 12:18 15[CFG] added vici connection: ikev2-pubkey
>> Tue, 2018-03-27 12:18 08[CFG] vici client 1 disconnected
>> Tue, 2018-03-27 12:18 11[NET] <1> received packet: from 172.58.44.91[43260] 
>> to 192.168.1.16[500] (704 bytes)
>> Tue, 2018-03-27 12:18 11[ENC] <1> parsed IKE_SA_INIT request 0 [ SA KE No 
>> N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
>> Tue, 2018-03-27 12:18 11[CFG] <1> looking for an ike config for 
>> 192.168.1.16...172.58.44.91
>> Tue, 2018-03-27 12:18 11[IKE] <1> no IKE config found for 
>> 192.168.1.16...172.58.44.91, sending NO_PROPOSAL_CHOSEN
>> Tue, 2018-03-27 12:18 11[ENC] <1> generating IKE_SA_INIT response 0 [ 
>> N(NO_PROP) ]
>> Tue, 2018-03-27 12:18 11[NET] <1> sending packet: from 192.168.1.16[500] to 
>> 172.58.44.91[43260] (36 bytes)
>> Tue, 2018-03-27 12:18 11[IKE] <1> IKE_SA (unnamed)[1] state change: CREATED 
>> => DESTROYING
>>
>> connections {
>>
>> # Roadwarrior Responder:  
>> https://wiki.strongswan.org/projects/strongswan/wiki/UsableExamples
>>
>>     ikev2-pubkey {
>>     version = 2
>>     remote_addrs = 192.168.1.0/24
>>     rekey_time = 0s
>>     fragmentation = yes
>>     dpd_delay = 30s
>>     # dpd_timeout doesn't do anything for IKEv2. The general 
>> IKEv2 packet timeouts are used.
>>     local-1 {
>>     certs = cygnus-Cert.pem
>>     id = cygnus.darkmatter.org
>>     }
>>     remote-1 {
>>     # defaults are fine.
>>     }
>>     children {
>>     ikev2-pubkey {
>>     local_ts = 0.0.0.0/0 #,::/0
>>     rekey_time = 0s
>>     dpd_action = clear
>>     }
>>     }
>>     }
>> }
>>
>>
>> On 03/27/2018 12:07 PM, Noel Kuntze wrote:
>>> Use "certs", not "cert". It's a typo.
>>>
>>> On 27.03.2018 21:05, Info wrote:
 Back to the old:

 Mar 27 11:54:16 cygnus.darkmatter.org charon-systemd[64014]: loaded ANY 
 private key
 Mar 27 11:54:16 cygnus.darkmatter.org swanctl[64031]: no authorities 
 found, 0 unloaded

Re: [strongSwan] Not Able to Connect

2018-03-27 Thread Noel Kuntze

Of course not, you didn't do what I wrote.

You need two conns.
One for your host-to-host scenario and one for the initiators from the 
internet. What you previously had worked for the host-to-host scenario.

On 27.03.2018 21:20, Info wrote:
>
> Back to this from the very beginning.
>
> Tue, 2018-03-27 12:18 15[CFG] added vici connection: ikev2-pubkey
> Tue, 2018-03-27 12:18 08[CFG] vici client 1 disconnected
> Tue, 2018-03-27 12:18 11[NET] <1> received packet: from 172.58.44.91[43260] 
> to 192.168.1.16[500] (704 bytes)
> Tue, 2018-03-27 12:18 11[ENC] <1> parsed IKE_SA_INIT request 0 [ SA KE No 
> N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
> Tue, 2018-03-27 12:18 11[CFG] <1> looking for an ike config for 
> 192.168.1.16...172.58.44.91
> Tue, 2018-03-27 12:18 11[IKE] <1> no IKE config found for 
> 192.168.1.16...172.58.44.91, sending NO_PROPOSAL_CHOSEN
> Tue, 2018-03-27 12:18 11[ENC] <1> generating IKE_SA_INIT response 0 [ 
> N(NO_PROP) ]
> Tue, 2018-03-27 12:18 11[NET] <1> sending packet: from 192.168.1.16[500] to 
> 172.58.44.91[43260] (36 bytes)
> Tue, 2018-03-27 12:18 11[IKE] <1> IKE_SA (unnamed)[1] state change: CREATED 
> => DESTROYING
>
> connections {
>
> # Roadwarrior Responder:  
> https://wiki.strongswan.org/projects/strongswan/wiki/UsableExamples
>
>     ikev2-pubkey {
>     version = 2
>     remote_addrs = 192.168.1.0/24
>     rekey_time = 0s
>     fragmentation = yes
>     dpd_delay = 30s
>     # dpd_timeout doesn't do anything for IKEv2. The general 
> IKEv2 packet timeouts are used.
>     local-1 {
>     certs = cygnus-Cert.pem
>     id = cygnus.darkmatter.org
>     }
>     remote-1 {
>     # defaults are fine.
>     }
>     children {
>     ikev2-pubkey {
>     local_ts = 0.0.0.0/0 #,::/0
>     rekey_time = 0s
>     dpd_action = clear
>     }
>     }
>     }
> }
>
>
> On 03/27/2018 12:07 PM, Noel Kuntze wrote:
>> Use "certs", not "cert". It's a typo.
>>
>> On 27.03.2018 21:05, Info wrote:
>>> Back to the old:
>>>
>>> Mar 27 11:54:16 cygnus.darkmatter.org charon-systemd[64014]: loaded ANY 
>>> private key
>>> Mar 27 11:54:16 cygnus.darkmatter.org swanctl[64031]: no authorities found, 
>>> 0 unloaded
>>> Mar 27 11:54:16 cygnus.darkmatter.org swanctl[64031]: no pools found, 0 
>>> unloaded
>>> Mar 27 11:54:16 cygnus.darkmatter.org swanctl[64031]: loading connection 
>>> 'ikev2-pubkey' failed: unknown option: cert, config discarded
>>> Mar 27 11:54:16 cygnus.darkmatter.org swanctl[64031]: loaded 0 of 1 
>>> connections, 1 failed to load, 0 unloaded
>>> Mar 27 11:54:16 cygnus.darkmatter.org systemd[1]: 
>>> strongswan-swanctl.service: control process exited, code=exited status=22
>>>
>>> Daemon won't start.  And in fact in
>>> https://wiki.strongswan.org/projects/strongswan/wiki/Swanctlconf
>>> ... there is no cert directive, to go anywhere.  When I comment out cert 
>>> the daemon starts._
>>>
>>>
>>> _
>>>
>>> _swanctl.conf_
>>>
>>> connections {
>>>
>>> # Roadwarrior Responder:  
>>> https://wiki.strongswan.org/projects/strongswan/wiki/UsableExamples
>>>
>>>     ikev2-pubkey {
>>>     version = 2
>>>     remote_addrs = 192.168.111.0/24
>>>     rekey_time = 0s
>>>     fragmentation = yes
>>>     dpd_delay = 30s
>>>     # dpd_timeout doesn't do anything for IKEv2. The general 
>>> IKEv2 packet timeouts are used.
>>>     local-1 {
>>>     cert = zeta-Cert.pem
>>>     id = zeta.darkmatter.org
>>>     }
>>>     remote-1 {
>>>     # defaults are fine.
>>>     }
>>>     children {
>>>     ikev2-pubkey {
>>>     local_ts = 0.0.0.0/0 #,::/0
>>>     rekey_time = 0s
>>>     dpd_action = clear
>>>     }
>>>     }
>>>     }
>>> }
>>>
>>>
>>> On 03/27/2018 11:38 AM, Noel Kuntze wrote:
 Also: You need a second conn that is fitting to what the initiators from 
 the Internet want:
 - Tunnel Mode
 - A virtual IP
 - Access to the Internet

 Take the IKEv2 related parts of the roadwarrior configurations from the 
 UsableExamples page. And make sure you get the structure right this time.

 On 27.03.2018 20:32, Info wrote:
> Nothing has worked.  So starting over again, with another new config, pro 
> forma .
>
> Running CentOS 7.4 with IPSec gateway as OpenStack VM, DNATted to and 
> SNATted from by LAN gate

Re: [strongSwan] Not Able to Connect

2018-03-27 Thread Info

Back to this from the very beginning.

Tue, 2018-03-27 12:18 15[CFG] added vici connection: ikev2-pubkey
Tue, 2018-03-27 12:18 08[CFG] vici client 1 disconnected
Tue, 2018-03-27 12:18 11[NET] <1> received packet: from
172.58.44.91[43260] to 192.168.1.16[500] (704 bytes)
Tue, 2018-03-27 12:18 11[ENC] <1> parsed IKE_SA_INIT request 0 [ SA KE
No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
Tue, 2018-03-27 12:18 11[CFG] <1> looking for an ike config for
192.168.1.16...172.58.44.91
Tue, 2018-03-27 12:18 11[IKE] <1> no IKE config found for
192.168.1.16...172.58.44.91, sending NO_PROPOSAL_CHOSEN
Tue, 2018-03-27 12:18 11[ENC] <1> generating IKE_SA_INIT response 0 [
N(NO_PROP) ]
Tue, 2018-03-27 12:18 11[NET] <1> sending packet: from 192.168.1.16[500]
to 172.58.44.91[43260] (36 bytes)
Tue, 2018-03-27 12:18 11[IKE] <1> IKE_SA (unnamed)[1] state change:
CREATED => DESTROYING

connections {

# Roadwarrior Responder: 
https://wiki.strongswan.org/projects/strongswan/wiki/UsableExamples

    ikev2-pubkey {
    version = 2
    remote_addrs = 192.168.1.0/24
    rekey_time = 0s
    fragmentation = yes
    dpd_delay = 30s
    # dpd_timeout doesn't do anything for IKEv2. The general
IKEv2 packet timeouts are used.
    local-1 {
    certs = cygnus-Cert.pem
    id = cygnus.darkmatter.org
    }
    remote-1 {
    # defaults are fine.
    }
    children {
    ikev2-pubkey {
    local_ts = 0.0.0.0/0 #,::/0
    rekey_time = 0s
    dpd_action = clear
    }
    }
    }
}


On 03/27/2018 12:07 PM, Noel Kuntze wrote:
> Use "certs", not "cert". It's a typo.
>
> On 27.03.2018 21:05, Info wrote:
>> Back to the old:
>>
>> Mar 27 11:54:16 cygnus.darkmatter.org charon-systemd[64014]: loaded ANY 
>> private key
>> Mar 27 11:54:16 cygnus.darkmatter.org swanctl[64031]: no authorities found, 
>> 0 unloaded
>> Mar 27 11:54:16 cygnus.darkmatter.org swanctl[64031]: no pools found, 0 
>> unloaded
>> Mar 27 11:54:16 cygnus.darkmatter.org swanctl[64031]: loading connection 
>> 'ikev2-pubkey' failed: unknown option: cert, config discarded
>> Mar 27 11:54:16 cygnus.darkmatter.org swanctl[64031]: loaded 0 of 1 
>> connections, 1 failed to load, 0 unloaded
>> Mar 27 11:54:16 cygnus.darkmatter.org systemd[1]: 
>> strongswan-swanctl.service: control process exited, code=exited status=22
>>
>> Daemon won't start.  And in fact in
>> https://wiki.strongswan.org/projects/strongswan/wiki/Swanctlconf
>> ... there is no cert directive, to go anywhere.  When I comment out cert the 
>> daemon starts._
>>
>>
>> _
>>
>> _swanctl.conf_
>>
>> connections {
>>
>> # Roadwarrior Responder:  
>> https://wiki.strongswan.org/projects/strongswan/wiki/UsableExamples
>>
>>     ikev2-pubkey {
>>     version = 2
>>     remote_addrs = 192.168.111.0/24
>>     rekey_time = 0s
>>     fragmentation = yes
>>     dpd_delay = 30s
>>     # dpd_timeout doesn't do anything for IKEv2. The general 
>> IKEv2 packet timeouts are used.
>>     local-1 {
>>     cert = zeta-Cert.pem
>>     id = zeta.darkmatter.org
>>     }
>>     remote-1 {
>>     # defaults are fine.
>>     }
>>     children {
>>     ikev2-pubkey {
>>     local_ts = 0.0.0.0/0 #,::/0
>>     rekey_time = 0s
>>     dpd_action = clear
>>     }
>>     }
>>     }
>> }
>>
>>
>> On 03/27/2018 11:38 AM, Noel Kuntze wrote:
>>> Also: You need a second conn that is fitting to what the initiators from 
>>> the Internet want:
>>> - Tunnel Mode
>>> - A virtual IP
>>> - Access to the Internet
>>>
>>> Take the IKEv2 related parts of the roadwarrior configurations from the 
>>> UsableExamples page. And make sure you get the structure right this time.
>>>
>>> On 27.03.2018 20:32, Info wrote:
 Nothing has worked.  So starting over again, with another new config, pro 
 forma .

 Running CentOS 7.4 with IPSec gateway as OpenStack VM, DNATted to and 
 SNATted from by LAN gateway.  Certs only, SELinux permissive, firewall 
 down.

 The remote Android Strongswan app (initiator) is set:
 Server: quantum-equities.com                VPN Type IKEv2 certificate
 User certificate:  aries                            User Identity:  Default
 CA cert: Select automatically                  Profile name: cygnus
 Adv. Server ID:  cygnus.darkmatter.org   Send cert requests
 C

Re: [strongSwan] Not Able to Connect

2018-03-27 Thread Noel Kuntze

Use "certs", not "cert". It's a typo.

On 27.03.2018 21:05, Info wrote:
>
> Back to the old:
>
> Mar 27 11:54:16 cygnus.darkmatter.org charon-systemd[64014]: loaded ANY 
> private key
> Mar 27 11:54:16 cygnus.darkmatter.org swanctl[64031]: no authorities found, 0 
> unloaded
> Mar 27 11:54:16 cygnus.darkmatter.org swanctl[64031]: no pools found, 0 
> unloaded
> Mar 27 11:54:16 cygnus.darkmatter.org swanctl[64031]: loading connection 
> 'ikev2-pubkey' failed: unknown option: cert, config discarded
> Mar 27 11:54:16 cygnus.darkmatter.org swanctl[64031]: loaded 0 of 1 
> connections, 1 failed to load, 0 unloaded
> Mar 27 11:54:16 cygnus.darkmatter.org systemd[1]: strongswan-swanctl.service: 
> control process exited, code=exited status=22
>
> Daemon won't start.  And in fact in
> https://wiki.strongswan.org/projects/strongswan/wiki/Swanctlconf
> ... there is no cert directive, to go anywhere.  When I comment out cert the 
> daemon starts._
>
>
> _
>
> _swanctl.conf_
>
> connections {
>
> # Roadwarrior Responder:  
> https://wiki.strongswan.org/projects/strongswan/wiki/UsableExamples
>
>     ikev2-pubkey {
>     version = 2
>     remote_addrs = 192.168.111.0/24
>     rekey_time = 0s
>     fragmentation = yes
>     dpd_delay = 30s
>     # dpd_timeout doesn't do anything for IKEv2. The general 
> IKEv2 packet timeouts are used.
>     local-1 {
>     cert = zeta-Cert.pem
>     id = zeta.darkmatter.org
>     }
>     remote-1 {
>     # defaults are fine.
>     }
>     children {
>     ikev2-pubkey {
>     local_ts = 0.0.0.0/0 #,::/0
>     rekey_time = 0s
>     dpd_action = clear
>     }
>     }
>     }
> }
>
>
> On 03/27/2018 11:38 AM, Noel Kuntze wrote:
>> Also: You need a second conn that is fitting to what the initiators from the 
>> Internet want:
>> - Tunnel Mode
>> - A virtual IP
>> - Access to the Internet
>>
>> Take the IKEv2 related parts of the roadwarrior configurations from the 
>> UsableExamples page. And make sure you get the structure right this time.
>>
>> On 27.03.2018 20:32, Info wrote:
>>> Nothing has worked.  So starting over again, with another new config, pro 
>>> forma .
>>>
>>> Running CentOS 7.4 with IPSec gateway as OpenStack VM, DNATted to and 
>>> SNATted from by LAN gateway.  Certs only, SELinux permissive, firewall down.
>>>
>>> The remote Android Strongswan app (initiator) is set:
>>> Server: quantum-equities.com                VPN Type IKEv2 certificate
>>> User certificate:  aries                            User Identity:  Default
>>> CA cert: Select automatically                  Profile name: cygnus
>>> Adv. Server ID:  cygnus.darkmatter.org   Send cert requests
>>> Custom subnets: 192.168.1.0/24
>>>
>>>
>>> _strongswan.conf:_
>>> charon {
>>>     load_modular = yes
>>>     plugins {
>>>     include strongswan.d/charon/*.conf
>>>     }
>>> }
>>> include strongswan.d/*.conf
>>>
>>> _charon.conf_
>>>
>>>    # Needed to avoid in journalctl "fragmented IKE message is too large"
>>>     max_packet = 3
>>>
>>>     filelog {
>>>     /var/log/charon.log {
>>>     time_format = %a, %Y-%m-%d %R
>>>     ike_name = yes
>>>     append = no
>>>     default = 2
>>>     flush_line = yes
>>>
>>>     mgr = 0
>>>     net = 1
>>>     enc = 1
>>>     asn = 1
>>>     job = 1
>>>     knl = 1
>>>     }
>>>     }
>>> }
>>>
>>>
>>> _swanctl.conf_
>>>
>>> connections {
>>>
>>>     ikev2-pubkey {
>>>     remote_addrs = %any
>>>     local {
>>>     }
>>>     remote {
>>>     }
>>>
>>>     children {
>>>     remote_ts = 192.168.1.0/24
>>>     local_ts = 192.168.1.0/24
>>>     local_addrs = 192.168.1.16
>>>     remote_addrs = 192.168.1.5
>>>     mode = transport
>>>     }
>>>     }
>>> }
>>>
>>> # swanctl -L
>>> ikev2-pubkey: IKEv1/2, no reauthentication, rekeying every 14400s
>>>   local:  %any
>>>   remote: %any
>>>   local unspecified authentication:
>>>   remote unspecified authentication:
>>> # swanctl -l
>>> #
>>>
>>> # ip route show table all
>>> default via 192.168.1.1 dev eth0
>>> 169.254.0.0/16 dev eth0 scope link metric 1002
>>> 192.168.111.0/24 dev eth0 proto kernel scope link src 192.168.1.16
>>> broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1
>>> local 127.0.0.0/8 dev lo table local proto

Re: [strongSwan] Not Able to Connect

2018-03-27 Thread Info

Back to the old:

Mar 27 11:54:16 cygnus.darkmatter.org charon-systemd[64014]: loaded ANY
private key
Mar 27 11:54:16 cygnus.darkmatter.org swanctl[64031]: no authorities
found, 0 unloaded
Mar 27 11:54:16 cygnus.darkmatter.org swanctl[64031]: no pools found, 0
unloaded
Mar 27 11:54:16 cygnus.darkmatter.org swanctl[64031]: loading connection
'ikev2-pubkey' failed: unknown option: cert, config discarded
Mar 27 11:54:16 cygnus.darkmatter.org swanctl[64031]: loaded 0 of 1
connections, 1 failed to load, 0 unloaded
Mar 27 11:54:16 cygnus.darkmatter.org systemd[1]:
strongswan-swanctl.service: control process exited, code=exited status=22

Daemon won't start.  And in fact in
https://wiki.strongswan.org/projects/strongswan/wiki/Swanctlconf
... there is no cert directive, to go anywhere.  When I comment out cert
the daemon starts._


_

_swanctl.conf_

connections {

# Roadwarrior Responder: 
https://wiki.strongswan.org/projects/strongswan/wiki/UsableExamples

    ikev2-pubkey {
    version = 2
    remote_addrs = 192.168.111.0/24
    rekey_time = 0s
    fragmentation = yes
    dpd_delay = 30s
    # dpd_timeout doesn't do anything for IKEv2. The general
IKEv2 packet timeouts are used.
    local-1 {
    cert = zeta-Cert.pem
    id = zeta.darkmatter.org
    }
    remote-1 {
    # defaults are fine.
    }
    children {
    ikev2-pubkey {
    local_ts = 0.0.0.0/0 #,::/0
    rekey_time = 0s
    dpd_action = clear
    }
    }
    }
}


On 03/27/2018 11:38 AM, Noel Kuntze wrote:
> Also: You need a second conn that is fitting to what the initiators from the 
> Internet want:
> - Tunnel Mode
> - A virtual IP
> - Access to the Internet
>
> Take the IKEv2 related parts of the roadwarrior configurations from the 
> UsableExamples page. And make sure you get the structure right this time.
>
> On 27.03.2018 20:32, Info wrote:
>> Nothing has worked.  So starting over again, with another new config, pro 
>> forma .
>>
>> Running CentOS 7.4 with IPSec gateway as OpenStack VM, DNATted to and 
>> SNATted from by LAN gateway.  Certs only, SELinux permissive, firewall down.
>>
>> The remote Android Strongswan app (initiator) is set:
>> Server: quantum-equities.com                VPN Type IKEv2 certificate
>> User certificate:  aries                            User Identity:  Default
>> CA cert: Select automatically                  Profile name: cygnus
>> Adv. Server ID:  cygnus.darkmatter.org   Send cert requests
>> Custom subnets: 192.168.1.0/24
>>
>>
>> _strongswan.conf:_
>> charon {
>>     load_modular = yes
>>     plugins {
>>     include strongswan.d/charon/*.conf
>>     }
>> }
>> include strongswan.d/*.conf
>>
>> _charon.conf_
>>
>>    # Needed to avoid in journalctl "fragmented IKE message is too large"
>>     max_packet = 3
>>
>>     filelog {
>>     /var/log/charon.log {
>>     time_format = %a, %Y-%m-%d %R
>>     ike_name = yes
>>     append = no
>>     default = 2
>>     flush_line = yes
>>
>>     mgr = 0
>>     net = 1
>>     enc = 1
>>     asn = 1
>>     job = 1
>>     knl = 1
>>     }
>>     }
>> }
>>
>>
>> _swanctl.conf_
>>
>> connections {
>>
>>     ikev2-pubkey {
>>     remote_addrs = %any
>>     local {
>>     }
>>     remote {
>>     }
>>
>>     children {
>>     remote_ts = 192.168.1.0/24
>>     local_ts = 192.168.1.0/24
>>     local_addrs = 192.168.1.16
>>     remote_addrs = 192.168.1.5
>>     mode = transport
>>     }
>>     }
>> }
>>
>> # swanctl -L
>> ikev2-pubkey: IKEv1/2, no reauthentication, rekeying every 14400s
>>   local:  %any
>>   remote: %any
>>   local unspecified authentication:
>>   remote unspecified authentication:
>> # swanctl -l
>> #
>>
>> # ip route show table all
>> default via 192.168.1.1 dev eth0
>> 169.254.0.0/16 dev eth0 scope link metric 1002
>> 192.168.111.0/24 dev eth0 proto kernel scope link src 192.168.1.16
>> broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1
>> local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
>> local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
>> broadcast 127.255.255.255 dev lo table local proto kernel scope link src 
>> 127.0.0.1
>> broadcast 192.168.1.0 dev eth0 table local proto kernel scope link src 
>> 192.

Re: [strongSwan] Not Able to Connect

2018-03-27 Thread Noel Kuntze

Also: You need a second conn that is fitting to what the initiators from the 
Internet want:
- Tunnel Mode
- A virtual IP
- Access to the Internet

Take the IKEv2 related parts of the roadwarrior configurations from the 
UsableExamples page. And make sure you get the structure right this time.

On 27.03.2018 20:32, Info wrote:
>
> Nothing has worked.  So starting over again, with another new config, pro 
> forma .
>
> Running CentOS 7.4 with IPSec gateway as OpenStack VM, DNATted to and SNATted 
> from by LAN gateway.  Certs only, SELinux permissive, firewall down.
>
> The remote Android Strongswan app (initiator) is set:
> Server: quantum-equities.com                VPN Type IKEv2 certificate
> User certificate:  aries                            User Identity:  Default
> CA cert: Select automatically                  Profile name: cygnus
> Adv. Server ID:  cygnus.darkmatter.org   Send cert requests
> Custom subnets: 192.168.1.0/24
>
>
> _strongswan.conf:_
> charon {
>     load_modular = yes
>     plugins {
>     include strongswan.d/charon/*.conf
>     }
> }
> include strongswan.d/*.conf
>
> _charon.conf_
>
>    # Needed to avoid in journalctl "fragmented IKE message is too large"
>     max_packet = 3
>
>     filelog {
>     /var/log/charon.log {
>     time_format = %a, %Y-%m-%d %R
>     ike_name = yes
>     append = no
>     default = 2
>     flush_line = yes
>
>     mgr = 0
>     net = 1
>     enc = 1
>     asn = 1
>     job = 1
>     knl = 1
>     }
>     }
> }
>
>
> _swanctl.conf_
>
> connections {
>
>     ikev2-pubkey {
>     remote_addrs = %any
>     local {
>     }
>     remote {
>     }
>
>     children {
>     remote_ts = 192.168.1.0/24
>     local_ts = 192.168.1.0/24
>     local_addrs = 192.168.1.16
>     remote_addrs = 192.168.1.5
>     mode = transport
>     }
>     }
> }
>
> # swanctl -L
> ikev2-pubkey: IKEv1/2, no reauthentication, rekeying every 14400s
>   local:  %any
>   remote: %any
>   local unspecified authentication:
>   remote unspecified authentication:
> # swanctl -l
> #
>
> # ip route show table all
> default via 192.168.1.1 dev eth0
> 169.254.0.0/16 dev eth0 scope link metric 1002
> 192.168.111.0/24 dev eth0 proto kernel scope link src 192.168.1.16
> broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1
> local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
> local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
> broadcast 127.255.255.255 dev lo table local proto kernel scope link src 
> 127.0.0.1
> broadcast 192.168.1.0 dev eth0 table local proto kernel scope link src 
> 192.168.1.16
> local 192.168.1.16 dev eth0 table local proto kernel scope host src 
> 192.168.1.16
> broadcast 192.168.1.255 dev eth0 table local proto kernel scope link src 
> 192.168.1.16
> unreachable ::/96 dev lo metric 1024 error -113
> unreachable :::0.0.0.0/96 dev lo metric 1024 error -113
> unreachable 2002:a00::/24 dev lo metric 1024 error -113
> unreachable 2002:7f00::/24 dev lo metric 1024 error -113
> unreachable 2002:a9fe::/32 dev lo metric 1024 error -113
> unreachable 2002:ac10::/28 dev lo metric 1024 error -113
> unreachable 2002:c0a8::/32 dev lo metric 1024 error -113
> unreachable 2002:e000::/19 dev lo metric 1024 error -113
> unreachable 3ffe:::/32 dev lo metric 1024 error -113
> fe80::/64 dev eth0 proto kernel metric 256
> local ::1 dev lo table local proto kernel metric 0
> local fe80::5054:ff:fec0:9330 dev lo table local proto kernel metric 0
> ff00::/8 dev eth0 table local metric 256
>
>
> #  ip address
> 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
>     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>     inet 127.0.0.1/8 scope host lo
>    valid_lft forever preferred_lft forever
>     inet6 ::1/128 scope host
>    valid_lft forever preferred_lft forever
> 2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
>     link/ether 52:54:00:c0:93:30 brd ff:ff:ff:ff:ff:ff
>     inet 192.168.1.16/24 brd 192.168.1.255 scope global eth0
>    valid_lft forever preferred_lft forever
>     inet6 fe80::5054:ff:fec0:9330/64 scope link
>    valid_lft forever preferred_lft forever
>
>
> # iptables-save
> # Generated by iptables-save v1.4.21 on Tue Mar 27 11:19:49 2018
> *nat
> :PREROUTING ACCEPT [21:3556]
> :INPUT ACCEPT [21:3556]
> :OUTPUT ACCEPT [25:1200]
> :POSTROUTING ACCEPT [25:1200]
> COMMIT
> # Completed on Tue Mar 27 11:19:49 2018
> # Generated by iptables-save v1.4.21 on Tue Mar 27 11:19:49 2018
> *mangle
> :PREROUTING ACCEPT [195:20990

Re: [strongSwan] Not Able to Connect

2018-03-27 Thread Noel Kuntze

As I previously iterated, you need to set remote_addrs on the ikev2-pubkey 
config to your subnet. You put it in the wrong section and also didn't put the 
subnet in it.


On 27.03.2018 20:32, Info wrote:
>
> Nothing has worked.  So starting over again, with another new config, pro 
> forma .
>
> Running CentOS 7.4 with IPSec gateway as OpenStack VM, DNATted to and SNATted 
> from by LAN gateway.  Certs only, SELinux permissive, firewall down.
>
> The remote Android Strongswan app (initiator) is set:
> Server: quantum-equities.com                VPN Type IKEv2 certificate
> User certificate:  aries                            User Identity:  Default
> CA cert: Select automatically                  Profile name: cygnus
> Adv. Server ID:  cygnus.darkmatter.org   Send cert requests
> Custom subnets: 192.168.1.0/24
>
>
> _strongswan.conf:_
> charon {
>     load_modular = yes
>     plugins {
>     include strongswan.d/charon/*.conf
>     }
> }
> include strongswan.d/*.conf
>
> _charon.conf_
>
>    # Needed to avoid in journalctl "fragmented IKE message is too large"
>     max_packet = 3
>
>     filelog {
>     /var/log/charon.log {
>     time_format = %a, %Y-%m-%d %R
>     ike_name = yes
>     append = no
>     default = 2
>     flush_line = yes
>
>     mgr = 0
>     net = 1
>     enc = 1
>     asn = 1
>     job = 1
>     knl = 1
>     }
>     }
> }
>
>
> _swanctl.conf_
>
> connections {
>
>     ikev2-pubkey {
>     remote_addrs = %any
>     local {
>     }
>     remote {
>     }
>
>     children {
>     remote_ts = 192.168.1.0/24
>     local_ts = 192.168.1.0/24
>     local_addrs = 192.168.1.16
>     remote_addrs = 192.168.1.5
>     mode = transport
>     }
>     }
> }
>
> # swanctl -L
> ikev2-pubkey: IKEv1/2, no reauthentication, rekeying every 14400s
>   local:  %any
>   remote: %any
>   local unspecified authentication:
>   remote unspecified authentication:
> # swanctl -l
> #
>
> # ip route show table all
> default via 192.168.1.1 dev eth0
> 169.254.0.0/16 dev eth0 scope link metric 1002
> 192.168.111.0/24 dev eth0 proto kernel scope link src 192.168.1.16
> broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1
> local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
> local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
> broadcast 127.255.255.255 dev lo table local proto kernel scope link src 
> 127.0.0.1
> broadcast 192.168.1.0 dev eth0 table local proto kernel scope link src 
> 192.168.1.16
> local 192.168.1.16 dev eth0 table local proto kernel scope host src 
> 192.168.1.16
> broadcast 192.168.1.255 dev eth0 table local proto kernel scope link src 
> 192.168.1.16
> unreachable ::/96 dev lo metric 1024 error -113
> unreachable :::0.0.0.0/96 dev lo metric 1024 error -113
> unreachable 2002:a00::/24 dev lo metric 1024 error -113
> unreachable 2002:7f00::/24 dev lo metric 1024 error -113
> unreachable 2002:a9fe::/32 dev lo metric 1024 error -113
> unreachable 2002:ac10::/28 dev lo metric 1024 error -113
> unreachable 2002:c0a8::/32 dev lo metric 1024 error -113
> unreachable 2002:e000::/19 dev lo metric 1024 error -113
> unreachable 3ffe:::/32 dev lo metric 1024 error -113
> fe80::/64 dev eth0 proto kernel metric 256
> local ::1 dev lo table local proto kernel metric 0
> local fe80::5054:ff:fec0:9330 dev lo table local proto kernel metric 0
> ff00::/8 dev eth0 table local metric 256
>
>
> #  ip address
> 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
>     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>     inet 127.0.0.1/8 scope host lo
>    valid_lft forever preferred_lft forever
>     inet6 ::1/128 scope host
>    valid_lft forever preferred_lft forever
> 2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
>     link/ether 52:54:00:c0:93:30 brd ff:ff:ff:ff:ff:ff
>     inet 192.168.1.16/24 brd 192.168.1.255 scope global eth0
>    valid_lft forever preferred_lft forever
>     inet6 fe80::5054:ff:fec0:9330/64 scope link
>    valid_lft forever preferred_lft forever
>
>
> # iptables-save
> # Generated by iptables-save v1.4.21 on Tue Mar 27 11:19:49 2018
> *nat
> :PREROUTING ACCEPT [21:3556]
> :INPUT ACCEPT [21:3556]
> :OUTPUT ACCEPT [25:1200]
> :POSTROUTING ACCEPT [25:1200]
> COMMIT
> # Completed on Tue Mar 27 11:19:49 2018
> # Generated by iptables-save v1.4.21 on Tue Mar 27 11:19:49 2018
> *mangle
> :PREROUTING ACCEPT [195:20990]
> :INPUT ACCEPT [195:20990]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [143:13859]
> :POSTROUTING ACCEPT [142:13775]
> COMMI

[strongSwan] Not Able to Connect

2018-03-27 Thread Info

Nothing has worked.  So starting over again, with another new config,
pro forma
.

Running CentOS 7.4 with IPSec gateway as OpenStack VM, DNATted to and
SNATted from by LAN gateway.  Certs only, SELinux permissive, firewall down.

The remote Android Strongswan app (initiator) is set:
Server: quantum-equities.com                VPN Type IKEv2 certificate
User certificate:  aries                            User Identity:  Default
CA cert: Select automatically                  Profile name: cygnus
Adv. Server ID:  cygnus.darkmatter.org   Send cert requests
Custom subnets: 192.168.1.0/24


_strongswan.conf:_
charon {
    load_modular = yes
    plugins {
    include strongswan.d/charon/*.conf
    }
}
include strongswan.d/*.conf

_charon.conf_

   # Needed to avoid in journalctl "fragmented IKE message is too large"
    max_packet = 3

    filelog {
    /var/log/charon.log {
    time_format = %a, %Y-%m-%d %R
    ike_name = yes
    append = no
    default = 2
    flush_line = yes

    mgr = 0
    net = 1
    enc = 1
    asn = 1
    job = 1
    knl = 1
    }
    }
}


_swanctl.conf_

connections {

    ikev2-pubkey {
    remote_addrs = %any
    local {
    }
    remote {
    }

    children {
    remote_ts = 192.168.1.0/24
    local_ts = 192.168.1.0/24
    local_addrs = 192.168.1.16
    remote_addrs = 192.168.1.5
    mode = transport
    }
    }
}

# swanctl -L
ikev2-pubkey: IKEv1/2, no reauthentication, rekeying every 14400s
  local:  %any
  remote: %any
  local unspecified authentication:
  remote unspecified authentication:
# swanctl -l
#

# ip route show table all
default via 192.168.1.1 dev eth0
169.254.0.0/16 dev eth0 scope link metric 1002
192.168.111.0/24 dev eth0 proto kernel scope link src 192.168.1.16
broadcast 127.0.0.0 dev lo table local proto kernel scope link src
127.0.0.1
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo table local proto kernel scope link src
127.0.0.1
broadcast 192.168.1.0 dev eth0 table local proto kernel scope link src
192.168.1.16
local 192.168.1.16 dev eth0 table local proto kernel scope host src
192.168.1.16
broadcast 192.168.1.255 dev eth0 table local proto kernel scope link src
192.168.1.16
unreachable ::/96 dev lo metric 1024 error -113
unreachable :::0.0.0.0/96 dev lo metric 1024 error -113
unreachable 2002:a00::/24 dev lo metric 1024 error -113
unreachable 2002:7f00::/24 dev lo metric 1024 error -113
unreachable 2002:a9fe::/32 dev lo metric 1024 error -113
unreachable 2002:ac10::/28 dev lo metric 1024 error -113
unreachable 2002:c0a8::/32 dev lo metric 1024 error -113
unreachable 2002:e000::/19 dev lo metric 1024 error -113
unreachable 3ffe:::/32 dev lo metric 1024 error -113
fe80::/64 dev eth0 proto kernel metric 256
local ::1 dev lo table local proto kernel metric 0
local fe80::5054:ff:fec0:9330 dev lo table local proto kernel metric 0
ff00::/8 dev eth0 table local metric 256


#  ip address
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN qlen
1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc pfifo_fast
state UP qlen 1000
    link/ether 52:54:00:c0:93:30 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.16/24 brd 192.168.1.255 scope global eth0
   valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fec0:9330/64 scope link
   valid_lft forever preferred_lft forever


# iptables-save
# Generated by iptables-save v1.4.21 on Tue Mar 27 11:19:49 2018
*nat
:PREROUTING ACCEPT [21:3556]
:INPUT ACCEPT [21:3556]
:OUTPUT ACCEPT [25:1200]
:POSTROUTING ACCEPT [25:1200]
COMMIT
# Completed on Tue Mar 27 11:19:49 2018
# Generated by iptables-save v1.4.21 on Tue Mar 27 11:19:49 2018
*mangle
:PREROUTING ACCEPT [195:20990]
:INPUT ACCEPT [195:20990]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [143:13859]
:POSTROUTING ACCEPT [142:13775]
COMMIT
# Completed on Tue Mar 27 11:19:49 2018
# Generated by iptables-save v1.4.21 on Tue Mar 27 11:19:49 2018
*raw
:PREROUTING ACCEPT [195:20990]
:OUTPUT ACCEPT [142:13775]
COMMIT
# Completed on Tue Mar 27 11:19:49 2018
# Generated by iptables-save v1.4.21 on Tue Mar 27 11:19:49 2018
*filter
:INPUT ACCEPT [195:20990]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [142:13775]
COMMIT
# Completed on Tue Mar 27 11:19:49 2018



charon.tar.bz2
Description: application/bzip

Re: [strongSwan] Not Able to Connect

Re: [strongSwan] Not Able to Connect

Re: [strongSwan] Not Able to Connect

Re: [strongSwan] Not Able to Connect

Re: [strongSwan] Not Able to Connect

Re: [strongSwan] Not Able to Connect

Re: [strongSwan] Not Able to Connect

Re: [strongSwan] Not Able to Connect

Re: [strongSwan] Not Able to Connect

Re: [strongSwan] Not Able to Connect

Re: [strongSwan] Not Able to Connect

Re: [strongSwan] Not Able to Connect

Re: [strongSwan] Not Able to Connect

Re: [strongSwan] Not Able to Connect

[strongSwan] Not Able to Connect

15 matches

Site Navigation

Mail list logo

Footer information