Re: [strongSwan] Export XFRM StrongSwan / IPSec routes to Quagga (OSPF)

2020-10-25 Thread Noel Kuntze
Hello Tom,

That is the right wiki page.
What I forgot to mention though is that with interfaces, you can then talk your 
routing protocol over it.
It does not give you information about the subnets though for which IPsec 
policies are installed.

What is the goal of this in the end?

Kind regards

Noel

Am 26.10.20 um 01:33 schrieb TomK:
> Hey Noel,
> 
> Thanks.  That would certainly make it automatic with either BIRD or Quagga.
> 
> I'll have a look at the pages again to see what it takes to create these.  
> Thinking this is still the right page for VTI and XFRM information?
> 
> https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN
> 
> Cheers,
> TK
> 
> On 10/25/2020 4:59 PM, Noel Kuntze wrote:
>> Hi Tom,
>>
>> The routes in table 220 are only used to tell the kernel which source IP to 
>> use for sending packets to a remote network.
>> They aren't part of XFRM and only tangentially pertain IPsec.
>> Also, routes are only added if they are required, so those routes in table 
>> 220 are not necessarily complete.
>>
>> A better solution for your use case would be to use route based IPsec by 
>> using dedicated VTIs or XFRM interfaces and running OSPF/BGP/whatever over 
>> those virtual links.
>>
>> Kind regards
>>
>> Noel
>>
>> Am 25.10.20 um 19:05 schrieb TomK:
>>> Hey All,
>>>
>>> I'm interested in finding out how to import routes from StrongSwan IPSec 
>>> installed XFRM tables (220) into Quagga (OSPF, 254)?
>>>
>>> The XFRM policy based rules are saved in table 220 while Quagga (OSPF) 
>>> saves the routes in table 254.  I have an IPSec StrongSwan on-prem GW 
>>> paired up with one of the Cloud providers.  The connection is established 
>>> fine however I can't ping the remote VLAN's from any other device on the 
>>> on-prem network except from the on-prem GW itself.
>>>
>>> I would like to make OSPF aware of table 220 so it can import the rules.  
>>> Or at least find another way to export the rules in table 220 and into 
>>> table 254.  Either import from or export to would work but I haven't been 
>>> able to find articles on the web addressing this issue.
>>>
>>> Is this possible?
>>>
>>
> 
> 



signature.asc
Description: OpenPGP digital signature


Re: [strongSwan] Export XFRM StrongSwan / IPSec routes to Quagga (OSPF)

2020-10-25 Thread TomK

Hey All,

I've configured the VTI's and routing is now fully working between the 9 
VLAN's.


XFRM, as far as I can tell, isn't as well documented.  I might try this 
later on o see if OpenWRT supprots it.


Thx,

On 10/25/2020 9:48 PM, TomK wrote:

Hey Noel,

I have four VLAN's on the Azure side.  I need all these VLAN's visible 
to my on-prem VLAN's, 5 on-prem VLAN's in total.  The on-prem GW can see 
those Azure VLAN's.  The mapping works well.


However, the on-prem StrongSwan GW running on my Raspberry Pi 2 
(OpenWRT) isn't redistributing the Azure VLAN's at the moment since they 
are sitting in table 220 where OSPF can't see them.


 From the Azure side, I can ping the on-prem GW just fine, including the 
ability to ssh to the on-prem OpenWRT GW from Azure.  However, I can't 
ping any of the other on-prem VLAN's from the Azure side, of course. Not 
until OSPF sees the Azure VLAN's I'm thinking.


This is mostly a POC so I have plenty of room to experiment. This is the 
goal.


Cheers,
TK


On 10/25/2020 8:51 PM, Noel Kuntze wrote:

Hello Tom,

That is the right wiki page.
What I forgot to mention though is that with interfaces, you can then 
talk your routing protocol over it.
It does not give you information about the subnets though for which 
IPsec policies are installed.


What is the goal of this in the end?

Kind regards

Noel

Am 26.10.20 um 01:33 schrieb TomK:

Hey Noel,

Thanks.  That would certainly make it automatic with either BIRD or 
Quagga.


I'll have a look at the pages again to see what it takes to create 
these.  Thinking this is still the right page for VTI and XFRM 
information?


https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN

Cheers,
TK

On 10/25/2020 4:59 PM, Noel Kuntze wrote:

Hi Tom,

The routes in table 220 are only used to tell the kernel which 
source IP to use for sending packets to a remote network.

They aren't part of XFRM and only tangentially pertain IPsec.
Also, routes are only added if they are required, so those routes in 
table 220 are not necessarily complete.


A better solution for your use case would be to use route based 
IPsec by using dedicated VTIs or XFRM interfaces and running 
OSPF/BGP/whatever over those virtual links.


Kind regards

Noel

Am 25.10.20 um 19:05 schrieb TomK:

Hey All,

I'm interested in finding out how to import routes from StrongSwan 
IPSec installed XFRM tables (220) into Quagga (OSPF, 254)?


The XFRM policy based rules are saved in table 220 while Quagga 
(OSPF) saves the routes in table 254.  I have an IPSec StrongSwan 
on-prem GW paired up with one of the Cloud providers.  The 
connection is established fine however I can't ping the remote 
VLAN's from any other device on the on-prem network except from the 
on-prem GW itself.


I would like to make OSPF aware of table 220 so it can import the 
rules.  Or at least find another way to export the rules in table 
220 and into table 254.  Either import from or export to would work 
but I haven't been able to find articles on the web addressing this 
issue.


Is this possible?














--
Thx,
TK.


Re: [strongSwan] kernel traps with auto=route, and "install_routes=no" - how to view traps installed and the routes if any installed by Strongswan-Charon

2020-10-25 Thread Noel Kuntze
Hello Rajiv,

> 1. What exactly are these "kernel traps installed? Can we view what traps are 
> installed?

They're just IPsec policies without a state.

> 3. So are these routes in table-220 correlated and mapped to the kernel-traps?

No. The routes are only added if the source IP needs to be changed from the one
indicated by the main routing table for the packets to the remote network to be 
protected by IPsec.

> Now in later Strongswan versions its been recommended to use 
> "install_routes=NO" 

That's wrong. It's only recommended if you don't want or need to change the 
source IP when tunnels go up.

> a) does charon rely ONLY on the "default route" in the main-routing table now?

From the IntroductionToStrongswan[1] article:

> To avoid conflicts with these routes (especially if virtual IPs are used), 
> the kernel-netlink plugin manually parses the
> host's routing tables to determine a suitable source address when sending IKE 
> packets. On hosts with a (very) high number
> of routes this is quite inefficient. In that case, setting 
> charon.plugins.kernel-netlink.fwmark in strongswan.conf is
> recommended as it will allow using a more efficient source address lookup.

Answers to your other questions can be drawn from the quote.

Kind regards

Noel

[1] 
https://wiki.strongswan.org/projects/strongswan/wiki/IntroductionTostrongSwan#Routing

Am 23.10.20 um 23:21 schrieb Rajiv Kulkarni:
> 
> Hi
> 
> Its mentioned that when we set "auto=route" in a connection entry/record for 
> a ipsec tunnel, the "kernel traps are installed"
> 
> In layman's terms and understanding:
> 1. What exactly are these "kernel traps installed? Can we view what traps are 
> installed?
> 2. By default "install_routes" is YES, so the routes are added in table 220 
> which has a higher priority order above the main-routing table
> 3. So are these routes in table-220 correlated and mapped to the kernel-traps?
> 
> For e,g with table-220 (install_routes=yes the default option enabled), the 
> following are the sample examples of the routes installed
> 
> 
> For a full-tunnel (localsubnet<>any) spokegw to hubgw
> ---
> 
> root@OpenWrt:/etc# ip route show table 220
> default via 2.2.2.1 dev eth0  proto static  src 192.168.2.253
> 192.168.2.0/24  dev eth2  scope link
> root@OpenWrt:/etc#
> 
> 
> 
> 
> For a site to site tunnel
> ---
> root@openwrt# ip route show table 220
> 44.44.44.0/24  dev eth0  scope link
> 172.31.38.0/24  via 44.44.44.254 dev eth0  proto 
> static  src 192.168.26.254
> 
> 
> 
> 
> On a Remote-Access VPN Client (split-tunnel)
> ---
> root@linuxgw2:~/dump3# ip route show table 220
> 192.168.6.0/24  via 100.100.100.2 dev eth1 proto 
> static src 10.1.104.100
> root@linuxgw2:~/dump3#
> 
> On a Remote-Access VPN Client (full-tunnel: local<>any)
> ---
> 
> root@OpenWrt:/etc# ip route show table 220
> default via 95.1.1.1 dev pppoe-wan  proto static  src 10.1.5.10
> 192.168.10.0/24  dev eth2  scope link
> root@OpenWrt:/etc#
> 
> 
> 
> ===
> 
> 
> 
> 
> 
> Now in later Strongswan versions its been recommended to use 
> "install_routes=NO" 
> 
> So again here too as a kind request, in layman's perspective/view and 
> understanding
> 1. What happens to the routes that used to be installed earlier in table 220?
> 
> 2. What effect ,this "non-use of table 220" has on the "kernel-traps" 
> installedagain in this scenario...what kind of kernel-traps are 
> installed? Are they different from when table 220 was enabled...??? Can a 
> user view these traps?
> 
> 3. With the "install_routes=NO":
> a) does charon rely ONLY on the "default route" in the main-routing table now?
> 
> b) Does the config and use of IP-Policy-Routes (with use of IP-Rules and 
> other routing tables defined by user) continue to work in this case and does 
> charon also refer to the policy-routes if configured
> 
> we have these above doubts when we are thinking of moving to 
> "install_routes=no" regime and just use the main-routing table and/or the 
> custom IP-Policy-Routes/IP-Rules (for both IPv4 and IPv6 Tunnels ). 
> Especially when we want to go in for some critical "IP4-Over-IPv6 IPSec 
> Tunnels" scenarios (part of transition to IPv6 networks)
> 
> 
> regards
> Rajiv
> 
> 
> 



signature.asc
Description: OpenPGP digital signature


Re: [strongSwan] Export XFRM StrongSwan / IPSec routes to Quagga (OSPF)

2020-10-25 Thread TomK

Hey Noel,

I have four VLAN's on the Azure side.  I need all these VLAN's visible 
to my on-prem VLAN's, 5 on-prem VLAN's in total.  The on-prem GW can see 
those Azure VLAN's.  The mapping works well.


However, the on-prem StrongSwan GW running on my Raspberry Pi 2 
(OpenWRT) isn't redistributing the Azure VLAN's at the moment since they 
are sitting in table 220 where OSPF can't see them.


From the Azure side, I can ping the on-prem GW just fine, including the 
ability to ssh to the on-prem OpenWRT GW from Azure.  However, I can't 
ping any of the other on-prem VLAN's from the Azure side, of course. Not 
until OSPF sees the Azure VLAN's I'm thinking.


This is mostly a POC so I have plenty of room to experiment. This is the 
goal.


Cheers,
TK


On 10/25/2020 8:51 PM, Noel Kuntze wrote:

Hello Tom,

That is the right wiki page.
What I forgot to mention though is that with interfaces, you can then talk your 
routing protocol over it.
It does not give you information about the subnets though for which IPsec 
policies are installed.

What is the goal of this in the end?

Kind regards

Noel

Am 26.10.20 um 01:33 schrieb TomK:

Hey Noel,

Thanks.  That would certainly make it automatic with either BIRD or Quagga.

I'll have a look at the pages again to see what it takes to create these.  
Thinking this is still the right page for VTI and XFRM information?

https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN

Cheers,
TK

On 10/25/2020 4:59 PM, Noel Kuntze wrote:

Hi Tom,

The routes in table 220 are only used to tell the kernel which source IP to use 
for sending packets to a remote network.
They aren't part of XFRM and only tangentially pertain IPsec.
Also, routes are only added if they are required, so those routes in table 220 
are not necessarily complete.

A better solution for your use case would be to use route based IPsec by using 
dedicated VTIs or XFRM interfaces and running OSPF/BGP/whatever over those 
virtual links.

Kind regards

Noel

Am 25.10.20 um 19:05 schrieb TomK:

Hey All,

I'm interested in finding out how to import routes from StrongSwan IPSec 
installed XFRM tables (220) into Quagga (OSPF, 254)?

The XFRM policy based rules are saved in table 220 while Quagga (OSPF) saves 
the routes in table 254.  I have an IPSec StrongSwan on-prem GW paired up with 
one of the Cloud providers.  The connection is established fine however I can't 
ping the remote VLAN's from any other device on the on-prem network except from 
the on-prem GW itself.

I would like to make OSPF aware of table 220 so it can import the rules.  Or at 
least find another way to export the rules in table 220 and into table 254.  
Either import from or export to would work but I haven't been able to find 
articles on the web addressing this issue.

Is this possible?











--
Thx,
TK.


Re: [strongSwan] private key not found

2020-10-25 Thread Noel Kuntze
Hi Christoph,

Specify the keys using connections..local.pubkeys and 
connections..remote.pubkeys.

Afterwards, check the output and the log file (best if you enable debug logging 
like shown on the HelpRequests page)
to see if the public keys were loaded and the private keys, too.

Kind regards

Noel

Am 25.10.20 um 21:11 schrieb Christoph Harder:
> Hello everyone,
> 
> I wish to create an IPSEC v2 connection and use two authentication rounds, 
> both with assymetric key pairs (one round using ECDSA followed by one round 
> using BLISS).
> Since BLISS is rather new I would like the second round as safe-guard in case 
> the near future shows any fatal flaws in BLISS.
> However at the moment I receive the follwoing message when I try to initiate 
> a connection.
> 
> [IKE] no private key found for 'xyz_ecdsa'
> 
> The private keys are stored as /bliss/xyz_bliss.pem and /ecdsa/xyz_ecdsa.pem 
> and the matching (same file name) public keys are stored in /pubkeys.
> When I load the keys, e.g. using swanctl --load-creds the keys are listed and 
> no error message shows up.
> 
> In the swanctl.conf the authentication rounds are defined like this (with 
> matching remote authentication rounds):
> local-1 {
>   id = xyz_ecdsa
>   auth = pubkey
>   round = 1
> }
> local-2 {
>   id = xyz_bliss
>   auth = pubkey
>   round = 2
> }
> 
> The private keys don't have a passphrase and are not listed in the secrets 
> section.
> 
> The private key file /ecdsa/xyz_ecdsa.pem looks like this:
> -BEGIN EC PRIVATE KEY-
> ...
> -END EC PRIVATE KEY-
> 
> and the public key file /pubkey/xyz_ecdsa.pem looks like this:
> -BEGIN PUBLIC KEY-
> ...
> -END PUBLIC KEY-
> 
> The keys have been generated using the pki tool.
> 
> Can you give me any hints on what I might be doing wrong?
> Are two rounds even supported when using auth = pubkey in both rounds?
> Do I need to tell strongswan somehow to associate the key files with the id?
> 
> Best regards,
> Christoph
> 



signature.asc
Description: OpenPGP digital signature


Re: [strongSwan] Export XFRM StrongSwan / IPSec routes to Quagga (OSPF)

2020-10-25 Thread Noel Kuntze
Hi Tom,

The routes in table 220 are only used to tell the kernel which source IP to use 
for sending packets to a remote network.
They aren't part of XFRM and only tangentially pertain IPsec.
Also, routes are only added if they are required, so those routes in table 220 
are not necessarily complete.

A better solution for your use case would be to use route based IPsec by using 
dedicated VTIs or XFRM interfaces and running OSPF/BGP/whatever over those 
virtual links.

Kind regards

Noel

Am 25.10.20 um 19:05 schrieb TomK:
> Hey All,
> 
> I'm interested in finding out how to import routes from StrongSwan IPSec 
> installed XFRM tables (220) into Quagga (OSPF, 254)?
> 
> The XFRM policy based rules are saved in table 220 while Quagga (OSPF) saves 
> the routes in table 254.  I have an IPSec StrongSwan on-prem GW paired up 
> with one of the Cloud providers.  The connection is established fine however 
> I can't ping the remote VLAN's from any other device on the on-prem network 
> except from the on-prem GW itself.
> 
> I would like to make OSPF aware of table 220 so it can import the rules.  Or 
> at least find another way to export the rules in table 220 and into table 
> 254.  Either import from or export to would work but I haven't been able to 
> find articles on the web addressing this issue.
> 
> Is this possible?
> 



signature.asc
Description: OpenPGP digital signature


Re: [strongSwan] Export XFRM StrongSwan / IPSec routes to Quagga (OSPF)

2020-10-25 Thread TomK

Hey Noel,

Thanks.  That would certainly make it automatic with either BIRD or 
Quagga.


I'll have a look at the pages again to see what it takes to create 
these.  Thinking this is still the right page for VTI and XFRM information?


https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN

Cheers,
TK

On 10/25/2020 4:59 PM, Noel Kuntze wrote:

Hi Tom,

The routes in table 220 are only used to tell the kernel which source IP to use 
for sending packets to a remote network.
They aren't part of XFRM and only tangentially pertain IPsec.
Also, routes are only added if they are required, so those routes in table 220 
are not necessarily complete.

A better solution for your use case would be to use route based IPsec by using 
dedicated VTIs or XFRM interfaces and running OSPF/BGP/whatever over those 
virtual links.

Kind regards

Noel

Am 25.10.20 um 19:05 schrieb TomK:

Hey All,

I'm interested in finding out how to import routes from StrongSwan IPSec 
installed XFRM tables (220) into Quagga (OSPF, 254)?

The XFRM policy based rules are saved in table 220 while Quagga (OSPF) saves 
the routes in table 254.  I have an IPSec StrongSwan on-prem GW paired up with 
one of the Cloud providers.  The connection is established fine however I can't 
ping the remote VLAN's from any other device on the on-prem network except from 
the on-prem GW itself.

I would like to make OSPF aware of table 220 so it can import the rules.  Or at 
least find another way to export the rules in table 220 and into table 254.  
Either import from or export to would work but I haven't been able to find 
articles on the web addressing this issue.

Is this possible?






--
Thx,
TK.


Re: [strongSwan] Export XFRM StrongSwan / IPSec routes to Quagga (OSPF)

2020-10-25 Thread TomK
That's certainly an option I've reviewed.  Whatever the option, would 
like to keep customization to nothing, if possible.


Cheers,
TK

On 10/25/2020 3:03 PM, Volodymyr Litovka wrote:


Hi,

if it's option, you can consider Bird, which can import from specified 
table - https://bird.network.cz/?get_doc=20=bird-6.html#ss6.6 :


|kernel table /number/|

Select which kernel table should this particular instance of the
Kernel protocol work with. Available only on systems supporting
multiple routing tables.


On 25.10.2020 20:05, TomK wrote:

Hey All,

I'm interested in finding out how to import routes from StrongSwan 
IPSec installed XFRM tables (220) into Quagga (OSPF, 254)?


The XFRM policy based rules are saved in table 220 while Quagga 
(OSPF) saves the routes in table 254.  I have an IPSec StrongSwan 
on-prem GW paired up with one of the Cloud providers.  The connection 
is established fine however I can't ping the remote VLAN's from any 
other device on the on-prem network except from the on-prem GW itself.


I would like to make OSPF aware of table 220 so it can import the 
rules.  Or at least find another way to export the rules in table 220 
and into table 254.  Either import from or export to would work but I 
haven't been able to find articles on the web addressing this issue.


Is this possible?


--
Volodymyr Litovka
   "Vision without Execution is Hallucination." -- Thomas Edison



--
Thx,
TK.


[strongSwan] private key not found

2020-10-25 Thread Christoph Harder
Hello everyone,

I wish to create an IPSEC v2 connection and use two authentication rounds, both 
with assymetric key pairs (one round using ECDSA followed by one round using 
BLISS).
Since BLISS is rather new I would like the second round as safe-guard in case 
the near future shows any fatal flaws in BLISS.
However at the moment I receive the follwoing message when I try to initiate a 
connection.

[IKE] no private key found for 'xyz_ecdsa'

The private keys are stored as /bliss/xyz_bliss.pem and /ecdsa/xyz_ecdsa.pem 
and the matching (same file name) public keys are stored in /pubkeys.
When I load the keys, e.g. using swanctl --load-creds the keys are listed and 
no error message shows up.

In the swanctl.conf the authentication rounds are defined like this (with 
matching remote authentication rounds):
local-1 {
id = xyz_ecdsa
auth = pubkey
round = 1
}
local-2 {
id = xyz_bliss
auth = pubkey
round = 2
}

The private keys don't have a passphrase and are not listed in the secrets 
section.

The private key file /ecdsa/xyz_ecdsa.pem looks like this:
-BEGIN EC PRIVATE KEY-
...
-END EC PRIVATE KEY-

and the public key file /pubkey/xyz_ecdsa.pem looks like this:
-BEGIN PUBLIC KEY-
...
-END PUBLIC KEY-

The keys have been generated using the pki tool.

Can you give me any hints on what I might be doing wrong?
Are two rounds even supported when using auth = pubkey in both rounds?
Do I need to tell strongswan somehow to associate the key files with the id?

Best regards,
Christoph


0xA362479F3F0ADC06.asc
Description: application/pgp-keys


Re: [strongSwan] Export XFRM StrongSwan / IPSec routes to Quagga (OSPF)

2020-10-25 Thread Volodymyr Litovka

Hi,

if it's option, you can consider Bird, which can import from specified
table - https://bird.network.cz/?get_doc=20=bird-6.html#ss6.6 :

|kernel table /number/|

   Select which kernel table should this particular instance of the
   Kernel protocol work with. Available only on systems supporting
   multiple routing tables.


On 25.10.2020 20:05, TomK wrote:

Hey All,

I'm interested in finding out how to import routes from StrongSwan
IPSec installed XFRM tables (220) into Quagga (OSPF, 254)?

The XFRM policy based rules are saved in table 220 while Quagga (OSPF)
saves the routes in table 254.  I have an IPSec StrongSwan on-prem GW
paired up with one of the Cloud providers.  The connection is
established fine however I can't ping the remote VLAN's from any other
device on the on-prem network except from the on-prem GW itself.

I would like to make OSPF aware of table 220 so it can import the
rules.  Or at least find another way to export the rules in table 220
and into table 254.  Either import from or export to would work but I
haven't been able to find articles on the web addressing this issue.

Is this possible?


--
Volodymyr Litovka
  "Vision without Execution is Hallucination." -- Thomas Edison



[strongSwan] Export XFRM StrongSwan / IPSec routes to Quagga (OSPF)

2020-10-25 Thread TomK

Hey All,

I'm interested in finding out how to import routes from StrongSwan IPSec 
installed XFRM tables (220) into Quagga (OSPF, 254)?


The XFRM policy based rules are saved in table 220 while Quagga (OSPF) 
saves the routes in table 254.  I have an IPSec StrongSwan on-prem GW 
paired up with one of the Cloud providers.  The connection is 
established fine however I can't ping the remote VLAN's from any other 
device on the on-prem network except from the on-prem GW itself.


I would like to make OSPF aware of table 220 so it can import the rules. 
 Or at least find another way to export the rules in table 220 and into 
table 254.  Either import from or export to would work but I haven't 
been able to find articles on the web addressing this issue.


Is this possible?

--
Thx,
TK.