Re: [strongSwan] Remote site dies for no reason?

[Noel Kuntze]

Hello Réne,

Yes, that is correct.

Kind regards
Noel


On 21.10.22 07:47, Rene Maurer wrote:

Hi Noel


Does this mean that dpddelay and dpdtimeout obsolete?


Sorry, I did not understand the documentation at the first attempt, I think, I 
understand now. It is only about the retransmissions. I try to set the global 
timeouts sharper.

But the log in the original posting indicates that the remote station is no 
longer responding or am I wrong?

Kind regards
René


On 21.10.2022 Rene Maurer wrote:

Hi Noel

Thank you very much.


With IKEv2 the global ikev2 timeouts are used.
See https://docs.strongswan.org/docs/6.0/config/retransmission.htm


Ok. Does this mean that dpddelay and dpdtimeout obsolete?
What about dpdaction=restart, will this remain in ipsec.conf?

Kind regards
René


On 20.10.22 10:45, Noel Kuntze wrote:
Hi Rene,

With IKEv2 the global ikev2 timeouts are used.
Change charon.retransmit_base, charon.retransmit_jitter, 
charon.retransmit_limit, charon.retransmit_timeout, charon.retransmit_tries as 
required to achieve the desired timeout.
See https://docs.strongswan.org/docs/6.0/config/retransmission.html for details

Kind regards
Noel Kuntze

On 20.10.22 10:45, Rene Maurer wrote:

Hello

We are  using strongSwan U5.4.0/K4.4.107 (embedded device) and making an ipec 
connection to a remote CISCO system.

 From time to time we see the following behavior (tunnel seams to stop working):


Oct 20 09:32:33 EGV charon[656]: 13[KNL] creating rekey job for CHILD_SA 
ESP/0xc5ff03b6/xx.xxx.xxx.xxx
Oct 20 09:32:33 EGV charon[656]: 13[IKE] establishing CHILD_SA one{1}
Oct 20 09:32:33 EGV charon[656]: 13[IKE] establishing CHILD_SA one{1}
Oct 20 09:32:33 EGV charon[656]: 13[ENC] generating CREATE_CHILD_SA request 
24388 [ N(REKEY_SA) SA No KE TSi TSr ]
Oct 20 09:32:33 EGV charon[656]: 13[NET] sending packet: from 
10.162.225.65[4500] to xx.xxx.xxx.xxx[4500] (309 bytes)
Oct 20 09:32:33 EGV charon[656]: 08[NET] received packet: from 
xx.xxx.xxx.xxx[4500] to 10.162.225.65[4500] (297 bytes)
Oct 20 09:32:33 EGV charon[656]: 08[ENC] parsed CREATE_CHILD_SA response 24388 
[ SA No KE TSi TSr ]
Oct 20 09:32:33 EGV charon[656]: 08[IKE] CHILD_SA one{93} established with SPIs 
c70a8723_i a5e30c1d_o and TS 10.162.110.160/29 === 10.0.0.0/8
Oct 20 09:32:33 EGV charon[656]: 08[IKE] CHILD_SA one{93} established with SPIs 
c70a8723_i a5e30c1d_o and TS 10.162.110.160/29 === 10.0.0.0/8
Oct 20 09:32:33 EGV charon[656]: 08[IKE] closing CHILD_SA one{92} with SPIs 
ca335ba8_i (21496 bytes) c5ff03b6_o (21496 bytes) and TS 10.162.110.160/29 === 
10.0.0.0/8
Oct 20 09:32:33 EGV charon[656]: 08[IKE] closing CHILD_SA one{92} with SPIs 
ca335ba8_i (21496 bytes) c5ff03b6_o (21496 bytes) and TS 10.162.110.160/29 === 
10.0.0.0/8
Oct 20 09:32:33 EGV charon[656]: 08[IKE] sending DELETE for ESP CHILD_SA with 
SPI ca335ba8
Oct 20 09:32:33 EGV charon[656]: 08[ENC] generating INFORMATIONAL request 24389 
[ D ]
Oct 20 09:32:33 EGV charon[656]: 08[NET] sending packet: from 
10.162.225.65[4500] to xx.xxx.xxx.xxx[4500] (69 bytes)
Oct 20 09:32:33 EGV charon[656]: 14[NET] received packet: from 
xx.xxx.xxx.xxx[4500] to 10.162.225.65[4500] (69 bytes)
Oct 20 09:32:33 EGV charon[656]: 14[ENC] parsed INFORMATIONAL response 24389 [ 
D ]
Oct 20 09:32:33 EGV charon[656]: 14[IKE] received DELETE for ESP CHILD_SA with 
SPI c5ff03b6
Oct 20 09:32:33 EGV charon[656]: 14[IKE] CHILD_SA closed
Oct 20 09:32:37 EGV charon[656]: 10[IKE] sending DPD request
Oct 20 09:32:37 EGV charon[656]: 10[ENC] generating INFORMATIONAL request 24390 
[ ]
Oct 20 09:32:37 EGV charon[656]: 10[NET] sending packet: from 
10.162.225.65[4500] to xx.xxx.xxx.xxx[4500] (57 bytes)
Oct 20 09:32:37 EGV charon[656]: 16[NET] received packet: from 
xx.xxx.xxx.xxx[4500] to 10.162.225.65[4500] (57 bytes)
Oct 20 09:32:37 EGV charon[656]: 16[ENC] parsed INFORMATIONAL response 24390 [ ]
Oct 20 09:32:38 EGV charon[656]: 14[NET] received packet: from 
xx.xxx.xxx.xxx[4500] to 10.162.225.65[4500] (57 bytes)
Oct 20 09:32:38 EGV charon[656]: 14[ENC] parsed INFORMATIONAL request 7089 [ ]
Oct 20 09:32:38 EGV charon[656]: 14[ENC] generating INFORMATIONAL response 7089 
[ ]
Oct 20 09:32:38 EGV charon[656]: 14[NET] sending packet: from 
10.162.225.65[4500] to xx.xxx.xxx.xxx[4500] (57 bytes)
Oct 20 09:32:40 EGV charon[656]: 08[IKE] sending DPD request
Oct 20 09:32:40 EGV charon[656]: 08[ENC] generating INFORMATIONAL request 24391 
[ ]
Oct 20 09:32:40 EGV charon[656]: 08[NET] sending packet: from 
10.162.225.65[4500] to xx.xxx.xxx.xxx[4500] (57 bytes)
Oct 20 09:32:40 EGV charon[656]: 06[NET] received packet: from 
xx.xxx.xxx.xxx[4500] to 10.162.225.65[4500] (57 bytes)
Oct 20 09:32:40 EGV charon[656]: 06[ENC] parsed INFORMATIONAL response 24391 [ ]
Oct 20 09:32:43 EGV charon[656]: 07[IKE] sending DPD request
Oct 20 09:32:43 EGV charon[656]: 07[ENC] generating INFORMATIONAL request 24392 
[ ]
Oct 20 09:32:43 EGV charon[656]: 07[NET] sending packet

Re: [strongSwan] Remote site dies for no reason?

[Noel Kuntze]

Hi Rene,

With IKEv2 the global ikev2 timeouts are used.
Change charon.retransmit_base, charon.retransmit_jitter, 
charon.retransmit_limit, charon.retransmit_timeout, charon.retransmit_tries as 
required to achieve the desired timeout.
See https://docs.strongswan.org/docs/6.0/config/retransmission.html for details

Kind regards
Noel

On 20.10.22 10:45, Rene Maurer wrote:

Hello

We are  using strongSwan U5.4.0/K4.4.107 (embedded device) and making an ipec 
connection to a remote CISCO system.

 From time to time we see the following behavior (tunnel seams to stop working):


Oct 20 09:32:33 EGV charon[656]: 13[KNL] creating rekey job for CHILD_SA 
ESP/0xc5ff03b6/xx.xxx.xxx.xxx
Oct 20 09:32:33 EGV charon[656]: 13[IKE] establishing CHILD_SA one{1}
Oct 20 09:32:33 EGV charon[656]: 13[IKE] establishing CHILD_SA one{1}
Oct 20 09:32:33 EGV charon[656]: 13[ENC] generating CREATE_CHILD_SA request 
24388 [ N(REKEY_SA) SA No KE TSi TSr ]
Oct 20 09:32:33 EGV charon[656]: 13[NET] sending packet: from 
10.162.225.65[4500] to xx.xxx.xxx.xxx[4500] (309 bytes)
Oct 20 09:32:33 EGV charon[656]: 08[NET] received packet: from 
xx.xxx.xxx.xxx[4500] to 10.162.225.65[4500] (297 bytes)
Oct 20 09:32:33 EGV charon[656]: 08[ENC] parsed CREATE_CHILD_SA response 24388 
[ SA No KE TSi TSr ]
Oct 20 09:32:33 EGV charon[656]: 08[IKE] CHILD_SA one{93} established with SPIs 
c70a8723_i a5e30c1d_o and TS 10.162.110.160/29 === 10.0.0.0/8
Oct 20 09:32:33 EGV charon[656]: 08[IKE] CHILD_SA one{93} established with SPIs 
c70a8723_i a5e30c1d_o and TS 10.162.110.160/29 === 10.0.0.0/8
Oct 20 09:32:33 EGV charon[656]: 08[IKE] closing CHILD_SA one{92} with SPIs 
ca335ba8_i (21496 bytes) c5ff03b6_o (21496 bytes) and TS 10.162.110.160/29 === 
10.0.0.0/8
Oct 20 09:32:33 EGV charon[656]: 08[IKE] closing CHILD_SA one{92} with SPIs 
ca335ba8_i (21496 bytes) c5ff03b6_o (21496 bytes) and TS 10.162.110.160/29 === 
10.0.0.0/8
Oct 20 09:32:33 EGV charon[656]: 08[IKE] sending DELETE for ESP CHILD_SA with 
SPI ca335ba8
Oct 20 09:32:33 EGV charon[656]: 08[ENC] generating INFORMATIONAL request 24389 
[ D ]
Oct 20 09:32:33 EGV charon[656]: 08[NET] sending packet: from 
10.162.225.65[4500] to xx.xxx.xxx.xxx[4500] (69 bytes)
Oct 20 09:32:33 EGV charon[656]: 14[NET] received packet: from 
xx.xxx.xxx.xxx[4500] to 10.162.225.65[4500] (69 bytes)
Oct 20 09:32:33 EGV charon[656]: 14[ENC] parsed INFORMATIONAL response 24389 [ 
D ]
Oct 20 09:32:33 EGV charon[656]: 14[IKE] received DELETE for ESP CHILD_SA with 
SPI c5ff03b6
Oct 20 09:32:33 EGV charon[656]: 14[IKE] CHILD_SA closed
Oct 20 09:32:37 EGV charon[656]: 10[IKE] sending DPD request
Oct 20 09:32:37 EGV charon[656]: 10[ENC] generating INFORMATIONAL request 24390 
[ ]
Oct 20 09:32:37 EGV charon[656]: 10[NET] sending packet: from 
10.162.225.65[4500] to xx.xxx.xxx.xxx[4500] (57 bytes)
Oct 20 09:32:37 EGV charon[656]: 16[NET] received packet: from 
xx.xxx.xxx.xxx[4500] to 10.162.225.65[4500] (57 bytes)
Oct 20 09:32:37 EGV charon[656]: 16[ENC] parsed INFORMATIONAL response 24390 [ ]
Oct 20 09:32:38 EGV charon[656]: 14[NET] received packet: from 
xx.xxx.xxx.xxx[4500] to 10.162.225.65[4500] (57 bytes)
Oct 20 09:32:38 EGV charon[656]: 14[ENC] parsed INFORMATIONAL request 7089 [ ]
Oct 20 09:32:38 EGV charon[656]: 14[ENC] generating INFORMATIONAL response 7089 
[ ]
Oct 20 09:32:38 EGV charon[656]: 14[NET] sending packet: from 
10.162.225.65[4500] to xx.xxx.xxx.xxx[4500] (57 bytes)
Oct 20 09:32:40 EGV charon[656]: 08[IKE] sending DPD request
Oct 20 09:32:40 EGV charon[656]: 08[ENC] generating INFORMATIONAL request 24391 
[ ]
Oct 20 09:32:40 EGV charon[656]: 08[NET] sending packet: from 
10.162.225.65[4500] to xx.xxx.xxx.xxx[4500] (57 bytes)
Oct 20 09:32:40 EGV charon[656]: 06[NET] received packet: from 
xx.xxx.xxx.xxx[4500] to 10.162.225.65[4500] (57 bytes)
Oct 20 09:32:40 EGV charon[656]: 06[ENC] parsed INFORMATIONAL response 24391 [ ]
Oct 20 09:32:43 EGV charon[656]: 07[IKE] sending DPD request
Oct 20 09:32:43 EGV charon[656]: 07[ENC] generating INFORMATIONAL request 24392 
[ ]
Oct 20 09:32:43 EGV charon[656]: 07[NET] sending packet: from 
10.162.225.65[4500] to xx.xxx.xxx.xxx[4500] (57 bytes)
Oct 20 09:32:47 EGV charon[656]: 06[IKE] retransmit 1 of request with message 
ID 24392
Oct 20 09:32:47 EGV charon[656]: 06[NET] sending packet: from 
10.162.225.65[4500] to xx.xxx.xxx.xxx[4500] (57 bytes)
Oct 20 09:32:54 EGV charon[656]: 09[IKE] retransmit 2 of request with message 
ID 24392
Oct 20 09:32:54 EGV charon[656]: 09[NET] sending packet: from 
10.162.225.65[4500] to xx.xxx.xxx.xxx[4500] (57 bytes)
Ping::PingHost, send ping to xx.xxx.xxx.xxx, ret 8
Ping::PingHost, ping reply received
Oct 20 09:33:02 EGV charon[656]: 11[NET] received packet: from 
xx.xxx.xxx.xxx[4500] to 10.162.225.65[4500] (57 bytes)
Oct 20 09:33:02 EGV charon[656]: 11[ENC] parsed INFORMATIONAL request 7090 [ ]
Oct 20 09:33:02 EGV charon[656]: 11[ENC] generating INFORMATIONAL response 7090 

Re: [strongSwan] Strange things when policy routing is in use.

[Noel Kuntze]

Hi Kamil,

Configure debug logging exactly as specfied in Github issue 196[1] and then 
take a look at the log.
It should contain the route strongSwan tries to install.

You can (and if the reason the route can not be installed is valid) disable 
route installation by strongSwan if the routing decision after the new tunnel 
was established would be different. Consider this is (at this point in time) a 
policy based tunnel. The only reason we need routes is to get the right next 
hop (can't remember if it's for the actual routing decision or verification of 
received packets by using the rp_filter (reverse path filter)). The setting to 
disable route installation is charon.install_routes=no in /etc/strongswan.conf 
or related file. On RHEL derivates that's hidden under /etc/strongswan/.

Kind regards
Noel

On 14.10.22 18:56, Kamil Jońca wrote:


I have problem with ipsec an openvpn tunnel.
I have to have source based routing.

assume we have  configuration below, after openvpn tunnel (tun0) is up:
#ip route
--8<---cut here---start->8---
default via 172.20.10.1 dev wlan0
10.0.0.0/16 via 10.8.17.5 dev tun0
[...some other routes, important thing is that there are is some subnets not 
whole 0.0.0.0/0 ...]
--8<---cut here---end--->8---

#ip route show table 1000
--8<---cut here---start->8---
0.0.0.0/1 dev tun0 scope link
128.0.0.0/1 dev tun0 scope link
--8<---cut here---end--->8---
(I tried not to use "default" route in this table, but with "default" result 
was the same)

#ip rule show
--8<---cut here---start->8---
0:  from all lookup local
220:from all lookup 220
1000:   from 10.8.17.6 lookup 1000
32766:  from all lookup main
32767:  from all lookup default
--8<---cut here---end--->8---

then I try to establish ipsec connection:
I got error message like:
--8<---cut here---start->8---
[...]
[IKE] IKE_SA alfa[30] established between 10.8.17.6[]...[]
[IKE] scheduling rekeying in 13679s
[IKE] maximum IKE_SA lifetime 15119s
[CFG] selected proposal: ESP:AES_GCM_16_128/NO_EXT_SEQ
[KNL] received netlink error: Network is unreachable (101)
[KNL] unable to install source route for 192.168.200.244
--8<---cut here---end--->8---

and  192.168.200.244 is attached to tun0 interface instead of wlan0 as I would 
expect

#ip route show table 220
is empty

When I start ipsec connection before openvpn - everything works
also everything works when I resign from using rule 1000 and table
1000. (i.e. source based routing)


Am I doing something wrong?
KJ

Re: [strongSwan] Local network (routing)

[Noel Kuntze]

Hello René,

Yes, if the networks overlapped then that was the right solution.
It was not clear to me that they were just from the email.

Kind regards
Noel

On 10.10.22 22:33, Rene Maurer wrote:

On 10.10.2022 Noel Kuntze wrote:


Please provide the output of `ipsec statusall` as well as `ip x p`.  Also, what 
are your firewall rules (iptables-save, nft list ruleset).



On 10.10.22 15:44, Rene Maurer wrote:



I am looking for a way to access the devices connected to eth0 also locally and not 
only through the tunnel (connections 10.162.110.161 <=> 10.162.110.165 should 
work).

Is that even possible? If so how?


Thanks for your answer Noël.

It was much easier. According to 
https://lists.strongswan.org/pipermail/users/2015-May/008222.html, the key is 
to set up a passthrough connection in ipsec.conf. Very elegant IMHO ;-)

I have added in ipsec.conf:

conn eth0_local
    leftsubnet=10.162.110.160/29
    rightsubnet=10.162.110.160/29
    authby=never
    type=passthrough
    auto=route

This works perfect as far as I can see so far.
I hope this is the recommended way to do it.

Kind regards
René

Re: [strongSwan] Local network (routing)

[Noel Kuntze]

Hi René,

Please provide the output of `ipsec statusall` as well as `ip x p`.  Also, what 
are your firewall rules (iptables-save, nft list ruleset).

Kind regards
Noel

On 10.10.22 15:44, Rene Maurer wrote:

Hi

I am using strongSwan U5.4.0/K4.4.107 (embedded device).

The ipsec tunnel is established over a mobile network and it works fine.

Additionally I have an Ethernet interface eth0 with the address 10.162.110.161. 
eth0 is connected to 10.162.110.165.

I am looking for a way to access the devices connected to eth0 also locally and not 
only through the tunnel (connections 10.162.110.161 <=> 10.162.110.165 should 
work).

Is that even possible? If so how?

I have:
-
# ipsec status
Security Associations (1 up, 0 connecting):
  one[1]: ESTABLISHED 9 seconds ago, 
10.162.225.65[]...91.230.141.233[]
  one{1}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: cb51bd6c_i b9503f34_o
  one{1}:   10.162.110.160/29 === 10.0.0.0/
-
# route -n
Destination Gateway Genmask Flags Metric Ref    Use Iface
0.0.0.0 0.0.0.0 0.0.0.0 U 0  0    0 ppp0
10.162.110.160  0.0.0.0 255.255.255.248 U 100    0    0 eth0
-
ip route show table 220
10.0.0.0/8 via xxx.xxx.xxx.xxx dev ppp0 proto static src 10.162.110.161
--
# ipsec.conf:
conn one
     # we are left
     left=10.162.225.65
     leftid=*
     leftsubnet=10.162.110.160/29
     leftcert=.crt
     leftsendcert=always

     # XXX is right
     right=xxx.xxx.xxx.xxx.
     rightid=
     rightsubnet=10.0.0.0/8
     auto=start
--

Regards
René

Re: [strongSwan] Issues with maintaining IKEv2 tunnels

[noel . kuntze+strongswan-users-ml]

Hi all,

Dpd and nat keepalive only work on IKE layer, not on the CHILD_SAs that you 
want.

Use auto=route, then bring up the tunnel manually once. Auto=route makes 
strongswan install trap policies for the traffic. That should improve 
reliability.

The newest release brought a new value for start_acrion or use with 
swanctl/vici that enables installing of trap policies and starting of the 
tunnel when the daemon starts.

Kind regards
Noel


Am 17. August 2022 13:35:08 UTC schrieb "Dr. Rolf Jansen" 
:
>I know what DPD is. Years ago, I used it with the old racoon of the 
>ipsec-tools then with IKEv1, and in racoon.conf I set the dpd_delay and let it 
>after dpd_maxfail call a script with the pahse1_dead argument.
>
>Some times ago, I read the manual ipsec.conf of strongSwan, and I did not 
>realize that „dpdaction = none (default)“ also deactivates DPD and not only 
>the action. Your reply let me read this part again more carefully, and I will 
>try with dpdaction = 
>
>Now my guess is, that I need to use the action „clear“ on both sides once the 
>mobile connection went down, since it usually does not come back in seconds, 
>most of the times even not in minutes. Then my script would reliably be 
>informed by „ipsec status“ that the connection is down, won’t it?  And it 
>could be brought up again using „ipsec up“ once the G4 router went back 
>online, couldn’t it?
>
>Or may I use the action „hold“? Usually the WAN-IP of the G4 router changes 
>upon down/up cycling. I guess this would confuse the trap policy, which will 
>catch matching traffic, won’t it?   
>
>Thank you very much.
>
>Best regards
>
>Rolf Jansen
>
>> Am 17.08.2022 um 09:56 schrieb Michael Schwartzkopff > >:
>> 
>> On 17.08.22 14:50, Dr. Rolf Jansen wrote:
>>> Hello,
>>> 
>>> The IKEv2 tunnels are established between device controllers in a remote 
>>> pilot plant in Spain, which is connected to the internet by a G4 mobile 
>>> router, and an AWS-EC2 instance in Frankfurt. On both sides strongSwan 
>>> v5.9.6 is installed and the OS is FreeBSD 13.0-RELEASE. Both sides are 
>>> behind NAT and receive their local IP via DHCP. For this reason I added on 
>>> both sides static local alias IPs of another reserved block to the 
>>> respective network adapter.
>>> 
>>> Mobile connections are not as stable as wired ones, and quite frequently we 
>>> suffer connection losses. In the pilot plant are two almost identical 
>>> device controllers, and both establish its own IPsec tunnel to said EC2. 
>>> Usually both are down at the same time. This tells me, that origin of the 
>>> connection loss is external, and out of my control. I want to focus on how 
>>> to reliably bring them up again, once the connection was lost.
>> 
>> 
>> That is exactly why Dead-Peer-Detection was included in IKEv2. Did you try 
>> using DPD?
>> 
>> 
>> 
>>> So, I wrote a script which on the remote sites checks the IPsec status of 
>>> the connection, and calls „ipsec up“, in case it is down. The problem is 
>>> now, that „ipsec status“ seems to think it is up even if the connection is 
>>> broken and according to the logs, charon keeps on for hours happily sending 
>>> keep alive messages to the IP of the AWS-EC2 instance which at the same 
>>> time does send keep alives as well to its peers and everybody does it over 
>>> the already broken connections.
>>> 
>>> I experimented with mobike = YES, but it did not make a difference.
>>> 
>>> 
>>> Questions:
>>> 
>>> Is there a more reliable way than „ipsec status“ for knowing whether a 
>>> IPsec tunnel went down?
>>> 
>>> I am not 100 % sure, but it seems that „ipsec up“ does not always bring a 
>>> broken connection up again, should I call something else?
>>> 
>>> The more drastic solution would be to let the remote site ping the internal 
>>> alias address of the EC2 and in case the connection is broken, simply call 
>>> „service strongswan restart“. However, If I need to refrain to this 
>>> measure, for what reason do we have „ipsec status“ and „ipsec up“ then?
>>> 
>>> Best regards
>>> 
>>> Rolf Jansen
>> 
>> 
>> Mit freundlichen Grüßen,
>> 
>> -- 
>> 
>> [*] sys4 AG
>> https://sys4.de , +49 (89) 30 90 46 64
>> Schleißheimer Straße 26/MG,80333 München
>> Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
>> Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief
>> Aufsichtsratsvorsitzender: Florian Kirstein
>

Sent from mobile

Re: [strongSwan] Linux routing issue

[Noel Kuntze]

Hello Carlos,

Well yes but no:



src 0.0.0.0/0 dst 0.0.0.0/0
dir out priority 39
tmpl src  dst 
    proto esp spi 0xcfef925b reqid 1 mode tunnel
src 0.0.0.0/0 dst 0.0.0.0/0
dir fwd priority 39
tmpl src  dst 
    proto esp reqid 1 mode tunnel
src 0.0.0.0/0 dst 0.0.0.0/0
dir in priority 39
tmpl src  dst 
    proto esp reqid 1 mode tunnel

Those are policies that match all traffic.

Maybe `ip -d x p` shows the marks if any are set.

Kind regards
Noel

Am 24.01.22 um 21:09 schrieb Carlos G Mendioroz:

Noel Kuntze @ 24/1/2022 16:55 -0300 dixit:

Hello Carlos,


 > The mark did take, but the rest (i.e. non secured traffic) is being 
affected, I may have been unclear about the

Please check the routing rules and tables too. E.g. ask the kernel what the 
route would be for an IP address using `ip r get X` and check if it matches 
what you expect it to be.


The "ip route get " shows what I would expect, but not what is being done.
Case in point, I do have a tunnel that terminates traffic to a given IP. To be 
able to serve traffic to that IP, any returning traffic is source routed via a 
rule (say prio 600) that forces the tunnel as default route. But that would 
disconnect my local net from testing to that address, so prio 0 has a lookup on 
local table, which has a route for the local net to the local interface.

When I started the ipsec SA, all traffic was routed by main table, and sent to 
default gateway, not paying attention to other rules it would seem.



 > The state shows it:

Can you check `ip xfrm policy`? That shows you the policies, which are the 
crucial parts. States without policies don't do anything. Policies without 
states drop everything.


AFAIK, policy looks good too:

src 0.0.0.0/0 dst 0.0.0.0/0
dir out priority 39
tmpl src  dst 
    proto esp spi 0xcfef925b reqid 1 mode tunnel
src 0.0.0.0/0 dst 0.0.0.0/0
dir fwd priority 39
tmpl src  dst 
    proto esp reqid 1 mode tunnel
src 0.0.0.0/0 dst 0.0.0.0/0
dir in priority 39
tmpl src  dst 
    proto esp reqid 1 mode tunnel
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0
src ::/0 dst ::/0
socket in priority 0
src ::/0 dst ::/0
socket out priority 0
src ::/0 dst ::/0
socket in priority 0
src ::/0 dst ::/0
socket out priority 0

Note that I have not instantiated an XFRM if yet. I may be missing something 
obvious, but the change of regular traffic behaviour surprised me.

-Carlos



Kind regards
Noel

Am 24.01.22 um 20:49 schrieb Carlos G Mendioroz:

Noel,
thanks for answering. Please see inline:

Noel Kuntze @ 24/1/2022 16:24 -0300 dixit:

Hello Carlos,

Either the mark didn't take, you're using an old version (some had a different 
behaviour in regards to marks and how routes are set when marks are set on the 
connection configuration).


I'm using 5.8.2 as distributed by Ubuntu 20.04 LTS.
The mark did take, but the rest (i.e. non secured traffic) is being affected, I 
may have been unclear about the issue.

The state shows it:

src  dst 
proto esp spi 0xcf54acd4 reqid 1 mode tunnel
replay-window 0 flag af-unspec
mark 0x20/0x
auth-trunc hmac(sha256) 0xd5... 128
enc cbc(aes) 0x1a...
encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
anti-replay context: seq 0x0, oseq 0x0, bitmap 0x
src  
proto esp spi 0xc1a5cd59 reqid 1 mode tunnel
replay-window 32 flag af-unspec
auth-trunc hmac(sha256) 0xbe... 128
enc cbc(aes) 0xd9...
encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
anti-replay context: seq 0x22, oseq 0x0, bitmap 0x



If you do not require the setting of source IP addresses for the remote 
subnets, just disable installing of routes, and use XFRM interfaces so you can 
use routes to direct traffic instead of dealing with the XFRM policies.


I'm trying to understand, not to have a working config. For now, at least :)

-Carlos



Kind regards
Noel

Am 24.01.22 um 12:44 schrieb Carlos G Mendioroz:

Hi,
trying to set up a VPN on a lab system with many interfaces
(Ubuntu 20.04, 2 uplinks, IPv6 tunnel, vlans, openvpn and IPIP tunnel).

It's been a while since I used strongswan, but it was easy to set up using 
ipsec command and ipsec.conf policies. ipsec route table (220) played fine with 
my own rules I use mainly to source route to Internet uplinks.

Now I want to setup a routed VPN (AWS transit gateway on the other end) and as 
soon as link comes up, all my traffic gets routed by main table.
(I changed policy to any any and at first did not specifiy mark, and it even 
disconnected from the local net, not nice on a headless server)
Now with mark it still makes all the traffic ignore rule priorities.

Any pointer to what to check ?
TIA,










OpenPGP_signature
Desc

Re: [strongSwan] Overriding DF on XFRM interfaces

[Noel Kuntze]

Hello John,

I am not aware of if the kernel tracks the assigned TCP MSS of the connections 
it knows of.
Conntrack does not have that information. So it's a good question why exactly 
that happens.

Can you double check if there is not maybe something like a local proxy running 
that could
be the cause of that? Also, what is the currently set MTU on the interface?
Does it coincide with the MSS (taking the TCP overhead into account)?

I agree that it is likely extremely fragile. A good way would be a userspace 
proxy, like squid.
Squid knows about conntrack, so can transparently proxy connections, even 
without tproxy (speaking from memories).

Kind regards
Noel


Am 03.12.21 um 15:35 schrieb John Marrett:

I am working on a VPN solution connecting some appliances on two
different networks. I’m using an x86 openwrt router with strongswan
5.9.2 and kernel 5.4.154. The systems I am connecting exhibit
non-compliant TCP MSS behaviour. They are, for unknown reasons,
ignoring the MSS from their peers and sending oversized packets. They
also ignore ICMP unreachable messages indicating path MTU, I have
confirmed that the ICMP unreachable messages are not blocked and they
have been captured directly on the system sending the problematic
traffic. I do not have control over the appliances and need to solve
the issues at the network level.

I'm using a modern IKEv2 / XFRM based configuration for this VPN. I
would like to ignore the DF bit and fragment traffic passing through
the VPN tunnel. This fragmentation could occur before or after
encapsulation, it's not significant to me.

If I was using a GRE tunnel I could use the ignore-df configuration
[1], however there doesn't appear to be an equivalent with an xfrm
interface.

I have managed to "solve" my problem, though I do not understand the
solution or how it works. If I create the following iptables rule to
adjust the MSS on traffic traversing the xfrm interface:

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -o xfrm0
-j TCPMSS --set-mss 1240
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -i xfrm0
-j TCPMSS --set-mss 1240

Then, in addition to the expected modification of the mss field, my
TCP traffic will be fragmented, ignoring the DF bit.

Here's an excerpt of traffic in ingress to the router:

09:23:56.103022 IP 10.1.34.10.5060 > 10.1.61.20.25578: Flags [P.], seq
883:1906, ack 1760, win 260, length 1023
09:23:56.119864 IP 10.1.61.20.25578 > 10.1.34.10.5060: Flags [.], ack
1906, win 501, length 0
09:24:01.448960 IP 10.1.34.10.5060 > 10.1.61.20.25578: Flags [P.], seq
1906:3271, ack 1760, win 260, length 1365
09:24:01.467771 IP 10.1.61.20.25578 > 10.1.34.10.5060: Flags [.], ack
3148, win 501, length 0
09:24:01.467810 IP 10.1.61.20.25578 > 10.1.34.10.5060: Flags [.], ack
3271, win 501, length 0

And egress on the xfrm interface (In addition to being sent over a VPN
connect the traffic is also being NATed by the VPN router):

09:23:56.103150 IP 10.2.30.1.5060 > 10.2.2.6.25578: Flags [P.], seq
881:1902, ack 1750, win 260, length 1021
09:23:56.119828 IP 10.2.2.6.25578 > 10.2.30.1.5060: Flags [.], ack
1902, win 501, length 0
09:24:01.449067 IP 10.2.30.1.5060 > 10.2.2.6.25578: Flags [.], seq
1902:3142, ack 1750, win 260, length 1240
09:24:01.449135 IP 10.2.30.1.5060 > 10.2.2.6.25578: Flags [P.], seq
3142:3265, ack 1750, win 260, length 123
09:24:01.467724 IP 10.2.2.6.25578 > 10.2.30.1.5060: Flags [.], ack
3142, win 501, length 0
09:24:01.467725 IP 10.2.2.6.25578 > 10.2.30.1.5060: Flags [.], ack
3265, win 501, length 0

The packet with length 1365 has been split into a packet of 1240 bytes
and a second of 123.

Without these rules I see the expected behaviour, the packets are
dropped and ICMP unreachable messages are sent indicating the path
MTU.

Is anyone able to explain why, in addition to adjusting the MSS, this
mangle configuration is allowing fragmentation ignoring the DF bit?
While the solution is working as I need it to, I'm concerned that it
may be extremely fragile.

Is there a better way to solve this problem?

Thanks in advance for any help you can offer,

-JohnF

[1] https://man7.org/linux/man-pages/man8/ip-tunnel.8.html


OpenPGP_signature
Description: OpenPGP digital signature

Re: [strongSwan] Let's Encrypt CA Expiry & related StrongSWAN trouble

[Noel Kuntze]

Hi,

Have you tried ipsec stroke rereadsecrets? (Btw, better switch to swanctl)

Kind regards
Noel

Am 06.10.21 um 16:54 schrieb Philip Veale:

So about a week about, one of the CAs in the chain Let'sEncrypt use (DST Root 
CA X3) expired. This shouldn't have been a problem for most clients, as it was 
cross signed with a CA that had not expired (ISRG Root X1) which most modern 
clients and devices should trust, though some older ones may not which was 
(AIUI) why they kept the DST Root CA X3 in there too.

I use a Let'sEncrypt certificate with StrongSWAN and for years it has mostly 
just worked (mostly being, certbot very usefully renewed the certificate 
dutifully every so many days, but it didn't get ipsec to re-read this so I'd 
have to manually punt it about 4 times a year. I could have fixed that but 
never bothered, anyway, I digress...)

Recently I found the StrongSWAN client on my Android 10 phone wouldn't connect, 
and at first I thought I just needed to punt it again to re-read the cert, but 
then I realised it was reporting it had expired even after I'd manually run 
certbot. And thus I discovered that something that the Android Client is 
looking at doesn't trust the cert the server was offering as one CA was expired 
even though another was still valid. This I don't entirely understand as the 
Let'sEncrypt people seem pretty adamant it should all still work.

I don't entirely understand why new certificates issued today are still being 
signed with a cert that expired last week, though.

Anyway, moving on. I figured the best way to solve this was to request a cert 
from LE that was only signed by ISRG Root X1 and NOT by DST Root CA X3 as well, 
which is not the default behaviour but can be achieved by passing a switch to 
certbot to ask it to do it that way.

My system was running Debian Switch and I wanted to continue to use certbot, 
and I didn't want to pollute the system with certbot's suggested tool snap, 
which imports a little bit of Ubuntu stuff.

Looking at repositories' versions of the certbot package, it was clear I had to 
upgrade from Stretch to Bullseye, via Buster in between.

So, done that, everything all up to date, got new cert, all should be well now, 
except it fails, client and server both reporting basically the same thing;

Oct  6 15:20:30 VPN-Server charon: 10[IKE] no private key found for 
'vpn.my-hostname.net '
Oct  6 15:20:30 VPN-Server charon: 10[ENC] generating IKE_AUTH response 1 [ 
N(AUTH_FAILED) ]

I've not modified ipsec.secrets, it's still intact and contains the correct 
reference to the privkey.pem file, which pans out as running the below command 
brings up the expected result;

# ipsec listcerts

List of X.509 End Entity Certificates

   subject:  "CN=vpn.my-hostname.net "
   issuer:   "C=US, O=Let's Encrypt, CN=R3"
   validity:  not before Oct 06 14:03:36 2021, ok
              not after  Jan 04 13:03:35 2022, ok (expires in 89 days)
   serial:    [redacted]
   altNames: vpn.my-hostname.net 
   flags:     serverAuth clientAuth
   OCSP URIs: http://r3.o.lencr.org 
   certificatePolicies:
              2.23.140.1.2.1
              1.3.6.1.4.1.44947.1.1.1
              CPS: http://cps.letsencrypt.org 
[other lines trimmed]


all looks correct to me. All certs present and correct by my reckoning, config 
unaltered from previous working state before certificate trouble started within 
the last week.

I say unaltered, I've obviously gone up TWO Debian release versions which might 
have some bearing on it, but I can't see how and the logs and pointing the 
finger at a certificate issue which seems more likely.

Only other thing I can thing of is at some point in the past I had manually imported a 
cacert from Let'sEncrypt onto the system such that "ipsec listcacerts" produced 
some output, they are gone now so this produces nothing.

Not sure how they'd be needed, though


Can anyone spot or think of what I've missed, or has anyone else been through 
similar recently due to what's happened with Let'sEncrypt ?


OpenPGP_signature
Description: OpenPGP digital signature

Re: [strongSwan] swanctl.conf - How to create unique CHILD_SA(s) for different local_ts and remote_ts ?

[Noel Kuntze]

Hi Arvind,


What am I doing wrong ?


You're not reading logs. That's what you're doing wrong.
Please follow the HelpRequests[1] article on the wiki.

Kind regards
Noel

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


Am 01.10.21 um 18:10 schrieb Arvind Agaranallur Ganesan:

Hello Folks,

I am trying to create a unique CHILD_SA for a combination of local_ts and 
remote_ts combination - here is my configuration file -

=
connections {
     transport {
         remote_addrs = 10.168.0.7
         version = 2
         proposals = default

         local {
             id = "transport"
             auth = psk
         }
         remote {
             id = "transport"
             auth = psk
         }

         children {
             transport-tcp {
                 local_ts = 192.168.0.1/32 
                 remote_ts = 192.168.0.2/32 
                 mode = transport
                 start_action = start
             }
                transport-tcp-2 {
                 local_ts = 192.168.0.3/32 
                 remote_ts = 192.168.0.4/32 
                 mode = transport
                 start_action = start
             }
         }
     }
}
secrets {
     ike-1 {
         secret = "x"
     }
}
=

I can see the CHILD_SA only for 192.168.0.1/32  == 192.168.0.2/32 
 but not the other CHILD_SA for 192.168.0.3/32 
 == 192.168.0.4/32 . What am I doing 
wrong ?



OpenPGP_signature
Description: OpenPGP digital signature

Re: [strongSwan] IPSec route based VPN - VTI interface TX Errors NoRoute

[Noel Kuntze]

Hello Tiago,

It's more meant as a practical example on how to configure this and to look for 
anomalies in your setup.

Kind regards
Noel

Am 03.09.21 um 22:54 schrieb Tiago Stoco:

Hi Noel,

I will replicate the example below in my lab in the hopes to better understand 
the concepts behind an IPSec VPN tunnel.

Tiago Stoco.

--
*From:* Noel Kuntze
*Sent:* Friday, September 3, 2021 4:44 PM
*To:* Tiago Stoco; Noel Kuntze; Tobias Brunner; users@lists.strongswan.org
*Subject:* Re: [strongSwan] IPSec route based VPN - VTI interface TX Errors 
NoRoute

https://www.strongswan.org/testing/testresults/route-based/net2net-vti/index.html 
<https://www.strongswan.org/testing/testresults/route-based/net2net-vti/index.html>

Am 03.09.21 um 21:17 schrieb Tiago Stoco:
> Hi Noel,
>
> Let me add a bit of context before presenting the changes and its 
implications.
>
> [root@arch-linux ~]# ip -c addr
> 2: ens18:  mtu 1500 qdisc fq_codel state UP 
group default qlen 1000
>    link/ether aa:e4:30:3e:84:dbbrd ff:ff:ff:ff:ff:ff
>    altname enp0s18
>    inet 192.168.45.30/24 scope global ens18
>   valid_lft forever preferred_lft forever
>    inet6 fe80::a8e4:30ff:fe3e:84db/64 scope link
>   valid_lft forever preferred_lft forever
> 7: ip_vti1@NONE:  mtu 1436 qdisc noqueue state 
UNKNOWN group default qlen 1000
>    link/ipip 192.168.45.30peer 192.168.45.10
>    inet 10.10.10.2peer 10.10.10.1/32 scope global ip_vti1
>   valid_lft forever preferred_lft forever
>    inet6 fe80::5efe:c0a8:2d1e/64 scope link
>   valid_lft forever preferred_lft forever
>
>
> *ens18 - *is the WAN interface.
> *ip_vti1 - *is the VTI interface.
>
>
> Before enabling XFRM as you have proposed for |ens18|​ it was as follows 
>
> net.ipv4.conf.ens18.rp_filter = 2
> net.ipv4.conf.ens18.disable_policy = 1
> net.ipv4.conf.ens18.disable_xfrm = 0
>
> I am changing |ens18|​ and |ip_vti1|​ as follows 
>
> [root@arch-linux ~]# ./07.ipsec-check-int-sysctl.sh ip_vti1
> net.ipv4.conf.ip_vti1.disable_policy = 1
> net.ipv4.conf.ip_vti1.rp_filter = 0
> net.ipv4.conf.ip_vti1.disable_xfrm = 1
> net.ipv4.ip_forward = 1
>
> [root@arch-linux ~]# ./07.ipsec-check-int-sysctl.sh ens18
> net.ipv4.conf.ens18.disable_policy = 1
> net.ipv4.conf.ens18.rp_filter = 2
> net.ipv4.conf.ens18.disable_xfrm = 0
> net.ipv4.ip_forward = 1
>
> Also, I have changed the ikey and okey for the VTI to create a distinction 
between traffic ingressing and egressing the interface.
>
> [root@arch-linux ~]# ip -d link show dev ip_vti1
> 7: ip_vti1@NONE:  mtu 1436 qdisc noqueue state 
UNKNOWN mode DEFAULT group default qlen 1000
>    link/ipip 192.168.45.30 peer 192.168.45.10 promiscuity 0 minmtu 0 maxmtu 0
>    vti remote 192.168.45.10 local 192.168.45.30 ikey 0.0.0.32 okey 0.0.0.42 
addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65
> 535
>
> [root@arch-linux ~]# cat /etc/swanctl/swanctl.conf | grep mark
>    mark_in = 32
>    mark_out = 42
>
>
> Let's run a ping from remote(10.10.10.1 pfSense) to local(10.10.10.2 Arch 
Linux) and capture the packets in the VTI interface and filter OUTPUT chain.
>
> No.   Time Source   Destination
> 87 43.788630 10.10.10.1 > 10.10.10.2 ICMP 84 Echo (ping) request  id=0xb421, 
seq=43/11008, ttl=64 (reply in 88)
> 88 43.788641 10.10.10.2 > 10.10.10.1 ICMP 84 Echo (ping) reply  id=0xb421, 
seq=43/11008, ttl=64 (request in 87)
>
> The request arrives to the ip_vti1 interface and a reply is generated.
>
> No.   Time    Source  Destination
> 144 60.693330 10.10.10.2 > 10.10.10.1 ICMP 116 Echo (ping) reply  id=0xb421, 
seq=43/11008, ttl=64
>
> The reply is sent to the OUTPUT chain without encapsulation or encryption. It 
is like if the replies are not being

Re: [strongSwan] IPSec route based VPN - VTI interface TX Errors NoRoute

[Noel Kuntze]

I can see the packets destined to the 10.10.10.2 ( Arch Linux ) being marked 
but the replies are not.

[root@arch-linux ~]# lmangle
Chain PREROUTING (policy ACCEPT 572 packets, 44220 bytes)
num   pkts bytes target prot opt in out source   
destination
1   66  5544 MARK   all  --  any    any 10.10.10.1   
10.10.10.2   MARK set 0x20
2    0 0 MARK   all  --  any    any 10.10.10.2   10.10.10.1 
  MARK set 0x2a
3 181K   18M NFLOG  all  --  any    any anywhere 
10.10.10.0/30    nflog-group 5


By the way, a couple of emails ago I have mentioned that when the packet is 
captured by NFLOG you can see the MARK. Here's one example where you can see 
the mark in the field NFULA_MARK.

Frame 1: 144 bytes on wire (1152 bits), 144 bytes captured (1152 bits)
Linux Netfilter NFLOG
    Family: IPv4 (2)
    Version: 0
    Resource id: 5
    TLV Type: NFULA_PACKET_HDR (1), Length: 8
    TLV Type: NFULA_PREFIX (10), Length: 5
    TLV Type: NFULA_IFINDEX_INDEV (4), Length: 8
    TLV Type: NFULA_MARK (2), Length: 8
        Length: 8
        .000   0010 = Type: NFULA_MARK (2)
        Value: 0020
    TLV Type: NFULA_HWTYPE (15), Length: 6
    TLV Type: NFULA_HWLEN (17), Length: 6
    TLV Type: NFULA_HWHEADER (16), Length: 4
    TLV Type: NFULA_PAYLOAD (9), Length: 88
Internet Protocol Version 4, Src: 10.10.10.1, Dst: 10.10.10.2

I appreciate the help and clarification provided up to this point. Let me know 
if you have any more suggestions and I can happily test it.

Tiago Stoco.

--
*From:* Noel Kuntze
*Sent:* Thursday, September 2, 2021 6:08 PM
*To:* Tiago Stoco; Noel Kuntze; Tobias Brunner; users@lists.strongswan.org
*Subject:* Re: [strongSwan] IPSec route based VPN - VTI interface TX Errors 
NoRoute

Hello Tiago,

Thank you.

 > net.ipv4.conf.ens18.disable_xfrm = 1

There's your problem.
Set it to 0 (default value).

Kind regards
Noel

Am 02.09.21 um 20:41 schrieb Tiago Stoco:
> Hi Noel,
>
> So you're running openwrt on an Arch Linux kernel?
>
> No, I am running a pure Arch Linux virtual machine. Although, I have another 
VM with OpenWRT in my lab. Originally OpenWRT was being used but because NFLOG was 
not working and I needed packets flowing through the iptables captured to further 
troubleshoot an Arch box was spun up.
>
> Please pastebin the output of `sysctl net | grep disable`.
>
>
> [root@arch-linux ~]# ./07.ipsec-check-int-sysctl.sh ip_vti1
> net.ipv4.conf.ip_vti1.disable_policy = 1
> net.ipv4.conf.ip_vti1.rp_filter = 0
> net.ipv4.ip_forward = 1
>
> and as you requested 
>
> [root@arch-linux ~]# sysctl net | grep disable
> net.core.high_order_alloc_disable = 0
> net.ipv4.conf.all.disable_policy = 0
> net.ipv4.conf.all.disable_xfrm = 0
> net.ipv4.conf.default.disable_policy = 0
> net.ipv4.conf.default.disable_xfrm = 0
> net.ipv4.conf.ens18.disable_policy = 1
> net.ipv4.conf.ens18.disable_xfrm = 1
> net.ipv4.conf.ip_vti0.disable_policy = 0
> net.ipv4.conf.ip_vti0.disable_xfrm = 0
> net.ipv4.conf.ip_vti1.disable_policy = 1
> net.ipv4.conf.ip_vti1.disable_xfrm = 0
> net.ipv4.conf.lo.disable_policy = 1
> net.ipv4.conf.lo.disable_xfrm = 1
> net.ipv6.conf.all.disable_ipv6 = 0
> net.ipv6.conf.all.disable_policy = 0
> net.ipv6.conf.default.disable_ipv6 = 0
> net.ipv6.conf.default.disable_policy = 0
> net.ipv6.conf.ens18.disable_ipv6 = 0
> net.ipv6.conf.ens18.disable_policy = 0
> net.ipv6.conf.ip_vti1.disable_ipv6 = 0
> net.ipv6.conf.ip_vti1

Re: [strongSwan] IPSec route based VPN - VTI interface TX Errors NoRoute

[Noel Kuntze]

Hello Tiago,

> Linux 5.13.12-arch1-1

So you're running openwrt on an Arch Linux kernel?

> According to my understanding, the reply should be marked, dealt with the 
IPSec stack, and tunneled to the peer since it is on the VTI interface. Please 
correct me if I am wrong.

Please pastebin the output of `sysctl net | grep disable`.

Kind regards
Noel

Am 02.09.21 um 08:18 schrieb Tiago Stoco:

Hi Noel,

I have disabled the forecast plugin and MARK rules aren't being added to 
iptables anymore.

The following plugins are disabled at the moment :

[root@arch-linux ~]# cat /etc/strongswan.conf
...
bypass-lan {
   load = no
   }
   connmark {
   load = no
   }
   forecast {
   load = no
   }
...

When a capture is run on the VTI device I can see the pings from the pfSense 
arriving and the reply 

No.   Time  Source     Destination
5 2.050455 10.10.10.1 > 10.10.10.2 ICMP 84 Echo (ping) request  id=0xc4f5, 
seq=2/512, ttl=64 (reply in 6)
6 2.050467 10.10.10.2 > 10.10.10.1 ICMP 84 Echo (ping) reply    id=0xc4f5, 
seq=2/512, ttl=64 (request in 5)

Strange is the fact that I see the replies in the filter OUTPUT chain not 
encapsulated nor encrypted 

No.   Time  Source     Destination
11 9.653361 10.10.10.2 > 10.10.10.1 ICMP 116 Echo (ping) reply    id=0x80f2, 
seq=2/512, ttl=64

According to my understanding, the reply should be marked, dealt with the IPSec 
stack, and tunneled to the peer since it is on the VTI interface. Please 
correct me if I am wrong.

In regards to using an XFRM, the problem is that OpenWRT does not support XFRM 
devices. A newer release will support but the current is not available yet.

[root@arch-linux ~]# ipsec statusall
Status of IKE charon daemon (strongSwan 5.9.3, Linux 5.13.12-arch1-1, x86_64):
 uptime: 9 hours, since Sep 01 21:37:46 2021
 malloc: sbrk 3137536, mmap 0, used 1156720, free 1980816
 worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 
4
 loaded plugins: charon ldap pkcs11 aes des rc2 sha2 sha3 sha1 md5 mgf1 random 
nonce x509 revocation constraints pubkey p
kcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp curve25519 
agent chapoly xcbc cmac hmac ntru drbg newho
pe bliss curl sqlite attr kernel-netlink resolve socket-default farp stroke 
vici updown eap-identity eap-sim eap-aka eap-a
ka-3gpp2 eap-simaka-pseudonym eap-simaka-reauth eap-md5 eap-gtc eap-mschapv2 
eap-dynamic eap-radius eap-tls eap-ttls eap-p
eap xauth-generic xauth-eap xauth-pam xauth-noauth dhcp radattr unity counters
Listening IP addresses:
 192.168.45.30
 10.10.10.2
Connections:
   ipseclab:  192.168.45.30...192.168.45.10  IKEv2, dpddelay=10s
   ipseclab:   local:  [ipsec-lab-openwrt] uses pre-shared key authentication
   ipseclab:   remote: [ipsec-lab-pfsense] uses pre-shared key authentication
   con1:   child:  10.10.10.0/30 === 10.10.10.0/30 TUNNEL, dpdaction=restart
Security Associations (1 up, 0 connecting):
   ipseclab[4]: ESTABLISHED 2 hours ago, 
192.168.45.30[ipsec-lab-openwrt]...192.168.45.10[ipsec-lab-pfsense]
   ipseclab[4]: IKEv2 SPIs: 8b7b5c0ccf5b_i 9673036f29862401_r*, rekeying in 
4 hours
   ipseclab[4]: IKE proposal: 
AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
   con1{12}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: cef2dc29_i ccb51306_o
   con1{12}:  AES_GCM_16_256/MODP_2048, 0 bytes_i, 0 bytes_o, rekeying in 
14 minutes
   con1{12}:   10.10.10.0/30 === 10.10.10.0/30

Many Thanks !!

--
*From:* Noel Kuntze
*Sent:* Wednesday, September 1, 2021 1:23 AM
*To:* Tiago Stoco; Noel Kuntze; Tobias Brunner; users@lists.strongswan.org
*Subject:* Re: [strongSwan] IPSec route based VPN - VTI interface TX Errors 
NoRoute

Hi Tiago,

Try disabling the forecast plugin too, please.

With VTIs, you shouldn't need to manually mark the packets.

Btw, if you use an XFRM interface instead, you won't have as many pr

Re: [strongSwan] strongswan no shared key found

[Noel Kuntze]

Hello Chasing,

Make sure the configuration and the secrets is actually loaded (swanctl -q).
Is server_publicip == serveraddr?

Kind regards
Noel

Am 20.08.21 um 02:02 schrieb Chasing Vega:

Hi

I have a server which is public and accepts IPsec and am trying to connect to 
it through strong

My configuration for strongswan is

connections {
     my-vpn {
         remote_addrs = server_publicip
         version = 1
         proposals = aes256-sha-modp1024
         reauth_time = 1440m
         local {
             auth = psk
             id = loc
         }
         remote {
             # id field here is inferred from the remote address
             auth = psk
             id = sec
         }
         children {
             my-vpn-1 {
                 local_ts = local_public_ip
                 remote_ts = server_public_ip
                 mode = transport
                 esp_proposals = aes256-sha-modp1024
                 rekey_time = 60m
                 start_action = trap
                 dpd_action = restart
             }
         }
     }

}
secrets {
    ike-my-vpn-1 {
        id-1 = loc
        id-2 = sec
        secret = "This is a strong password"
    }
}

When I try to run strongswan I get

[IKE] initiating Main Mode IKE_SA my-vpn[49] to serveraddr
[ENC] generating ID_PROT request 0 [ SA V V V V V ]
[NET] sending packet: from locip[500] to serveraddr[500] (184 bytes)
[NET] received packet: from serveraddr[500] to locip[500] (108 bytes)
[ENC] parsed ID_PROT response 0 [ SA V ]
[IKE] received NAT-T (RFC 3947) vendor ID
[CFG] selected proposal: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
[ENC] generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
[NET] sending packet: from locip[500] to serveraddr[500] (244 bytes)
[NET] received packet: from serveraddr[500] to locip[500] (304 bytes)
[ENC] parsed ID_PROT response 0 [ KE No V V V V NAT-D NAT-D ]
[IKE] received Cisco Unity vendor ID
[IKE] received DPD vendor ID
[ENC] received unknown vendor ID: 
5d:4b:ac:66:6b:54:71:15:4b:07:98:9c:05:7e:be:f2
[IKE] received XAuth vendor ID
[IKE] no shared key found for 'loc'[locip] - 'sec'[serveraddr]
[IKE] no shared key found for locip - serveraddr
[ENC] generating INFORMATIONAL_V1 request 1109914452 [ N(INVAL_KE) ]
[NET] sending packet: from locip[500] to serveraddr[500] (56 bytes)


Does anyone have suggestion?




OpenPGP_signature
Description: OpenPGP digital signature

Re: [strongSwan] Questions for setting up host-host configuration.

[Noel Kuntze]

Hello Jason,

You're entirely on your own there.
The project does not support such old versions in any capacity.

Kind regards
Noel

Am 21.08.21 um 09:54 schrieb Jason Choi:

I used StrongSwan-4.2.17 and tried to set up host-host configuration following the 
explanation from https://www.strongswan.org/docs/readme4.htm 
.

My configuration is like this.

    [ 192.168.1.207 ] = [192.168.1.206]

  ss_client       ss_server

<< Configuration on host ss_client >>

/etc/ipsec.d/cacerts/strongswanCert.pem

/etc/ipsec.d/certs/ss_client.pem

/etc/ipsec.d/private/ss_client.key

/etc/ipsec.secrets:

: RSA ss_client.key

/etc/ipsec.conf

conn  host-host

   left=%defaultroute

   leftcert=ss_client.pem

   right=192.168.1.206

   rightid="C=US, O=Home, CN=ss_server.research-this-that.com"

   auto=start

<< Configuration on host ss_server >>

/etc/ipsec.d/cacerts/strongswanCert.pem

/etc/ipsec.d/certs/ss_server.pem

/etc/ipsec.d/private/ss_server.key

/etc/ipsec.secrets:

: RSA ss_server.key

/etc/ipsec.conf

conn  host-host

   left=%defaultroute

   leftcert=ss_server.pem

   right=192.168.1.207

   rightid="C=US, O=Home, CN=ss_client.research-this-that.com"

   auto=start

And this is a message when I run ipsec statusall from each host.

Would someone can give me any idea what was wrong?

Or if you need more information from my settings and configuration, please let 
me know.

<< ipsec statusall from ss_client >>

# ipsec statusall

000 interface lo/lo ::1:500

000 interface lo/lo 127.0.0.1:500

000 interface eth0/eth0 192.168.1.207:500

000 interface virbr0/virbr0 192.168.122.1:500

000 %myid = (none)

000 debug none

000

000 "host-host": 192.168.1.207[C=US, O=Home, 
CN=ss_client.research-this-that.com]---192.168.1.1...192.168.1.206[C=US, O=Home, 
CN=ss_server.research-this-that.com]; unrouted; eroute owner: #0

000 "host-host":   CAs: 'C=US, O=Home, 
CN=ss_server.research-this-that.com'...'%any'

000 "host-host":   ike_life: 10800s; ipsec_life: 3600s; rekey_margin: 540s; 
rekey_fuzz: 100%; keyingtries: 3

000 "host-host":   policy: RSASIG+ENCRYPT+TUNNEL+PFS+UP; prio: 32,32; 
interface: eth0;

000 "host-host":   newest ISAKMP SA: #0; newest IPsec SA: #0;

000 "host-host":   IKE algorithms wanted: 7_128-2-14,

000 "host-host":   IKE algorithms found:  7_128-2_160-14,

000 "host-host":   ESP algorithms wanted: 12_128-2, 3_000-1,

000 "host-host":   ESP algorithms loaded: 12_128-2_160, 3_192-1_128,

000

000 #1: "host-host" STATE_MAIN_I1 (sent MI1, expecting MR1); EVENT_RETRANSMIT 
in 30s

000 #1: pending Phase 2 for "host-host" replacing #0

000

<< ipsec statusall from ss_server >>

# ipsec statusall

000 interface lo/lo ::1:500

000 interface lo/lo 127.0.0.1:500

000 interface eth0/eth0 192.168.1.206:500

000 interface virbr0/virbr0 192.168.122.1:500

000 %myid = (none)

000 debug none

000

000 "host-host": 192.168.1.206[C=US, O=Home, 
CN=ss_server.research-this-that.com]---192.168.1.1...192.168.0.1[C=US, O=Home, 
CN=ss_client.research-this-that.com]; unrouted; eroute owner: #0

000 "host-host":   CAs: 'C=US, O=Home, 
CN=ss_server.research-this-that.com'...'%any'

000 "host-host":   ike_life: 10800s; ipsec_life: 3600s; rekey_margin: 540s; 
rekey_fuzz: 100%; keyingtries: 3

000 "host-host":   policy: RSASIG+ENCRYPT+TUNNEL+PFS+UP; prio: 32,32; 
interface: eth0;

000 "host-host":   newest ISAKMP SA: #0; newest IPsec SA: #0;

000 "host-host":   IKE algorithms wanted: 7_128-2-14,

000 "host-host":   IKE algorithms found:  7_128-2_160-14,

000 "host-host":   ESP algorithms wanted: 12_128-2, 3_000-1,

000 "host-host":   ESP algorithms loaded: 12_128-2_160, 3_192-1_128,

000

000 #1: "host-host" STATE_MAIN_I1 (sent MI1, expecting MR1); EVENT_RETRANSMIT 
in 1s

000 #1: pending Phase 2 for "host-host" replacing #0

000

Windows の メール  から送信





OpenPGP_signature
Description: OpenPGP digital signature

Re: [strongSwan] Problem on Vodafone in India

[Noel Kuntze]

Hello John,

There must be more going on.
strongSwan configuration does not influence DNS resolution in any way.

Kind regards
Noel

Am 29.08.21 um 15:38 schrieb John Serink:

Hello:

We are running the following on a Teltonika RUT-950 router:
root@CORS144:~# ipsec --version
Linux strongSwan U5.6.2/K3.18.44
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil, Switzerland
See 'ipsec --copyright' for copyright information.

I am not sure if this is a strongswan issue or not.
IPv6 is disabled on the router:
root@CORS144:/# cat /proc/sys/net/ipv6/conf/default/disable_ipv6
1
root@CORS144:/# cat /proc/sys/net/ipv6/conf/all/disable_ipv6
1

We use 2 cell providers in India, Airtel and Vodafone. Airtel works as 
expected, no issues.
Vodafone has a strange problem.
1. It can take upto 3 minutes for a connection to come up, so strongswan fails 
as the name
lookup fails for our IPSec responder,

2. When the connection finally does come up, from another ssh console I can 
ping our IPSec
responder but watching the log, using logread -f, I see strongswan trying to 
connect to the
IPSec responder using an IPV6 address.

Why is it doing that? We have disabled IPV6 but nslookup is returning an IPv4 
and IPV6 address
for the responder.

We never have this issue with airtel.
But it gets more interesting:
3. If I setup the ipsec.conf (/etc/config/strongwan) as:

right   TheFullyQualifiedDomainName

and then I do this:

nslookup TheFullyQualifiedDomainName

I will get an IPv4 and IPv6 address and strongswan will use the IPv6 
address.there is no
vpn setup on the IPv6 address of the destination responder.
4. If I setup ipsec.conf (/etc/config/strongswan) like this:

right   A.B.C.D

and then I do this:

nslookup TheFullyQualifiedDomainName

I will get only the IPv4 address A.B.C.D and strongswan will use this for the 
connection and
it works.

But if we use airtel, it works either way.

Can anyone make sense of this?

So, my question is:
Does this seem like a strongswan issue or an RUT-950 system issue?

We have a work around which is to use the IP address of the responder as item 4 
which is a
non-ideal solution if we change ISPs at the control centreas then I'd have 
to manually go
through 280 routers so I'd like to stay with the FQDN if possible.

Cheers,
john





OpenPGP_signature
Description: OpenPGP digital signature

Re: [strongSwan] IPSec route based VPN - VTI interface TX Errors NoRoute

[Noel Kuntze]

/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
   con1{53}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: cb169570_i c35823e7_o
   con1{53}:  AES_GCM_16_256, 0 bytes_i, 0 bytes_o, rekeying in 51 minutes
   con1{53}:   10.10.10.0/30 === 10.10.10.0/30

I will add to the thread later but NFLOG is able to capture MARKS in the 
packets. The packets captured by NFLOG has a special section with quite useful 
information.
...
Linux Netfilter NFLOG
     Family: IPv4 (2)
     Version: 0
     Resource id: 7
     TLV Type: NFULA_PACKET_HDR (1), Length: 8
...

Once again, thanks for the help.

Tiago Stoco.

--
*From:* Noel Kuntze
*Sent:* Tuesday, August 31, 2021 2:20 PM
*To:* Tiago Stoco; Tobias Brunner; users@lists.strongswan.org
*Subject:* Re: [strongSwan] IPSec route based VPN - VTI interface TX Errors 
NoRoute

Hello Tiago,

> And, I have moved the route for the VTI to table 220 because it seems to be 
the right way to config routed based IPSec VPN.
>
> [root@arch-linux ~]# ip rule
> 0:  from all lookup local
> 220:    from all lookup 220
> 32766:  from all lookup main
> 32767:  from all lookup default

Don't do that.
220 is managed by strongSwan. Keep them in the main table.

> -A PREROUTING -d 10.10.10.0/30 -c 2352 230776 -j MARK --set-xmark 
0x2a/0x
> -A OUTPUT -d 10.10.10.0/30 -c 3605 336028 -j MARK --set-xmark 0x2a/0x

Disable the connmark plugin.


> I have added a few more NFLOG captures into my iptables and I am a bit 
confused with the results.
>
> A tcpdump capture in the VTI interface with a ping from the remote ( pfSense 
- 10.10.10.1 ) shows :
>
> No   Time  Source    Destination
>
> 1 0.00 10.10.10.1 10.10.10.2 ICMP 84 Echo (ping) request  id=0x9877, 
seq=471/55041, ttl=64 (reply in 2)
> 2 0.38 10.10.10.2 > 10.10.10.1 ICMP 84 Echo (ping) reply    id=0x9877, 
seq=471/55041, ttl=64 (request in 1)
>
> I do not see the IPSec MARK in these packets.

They are only visible in the output of the TRACE target. I suspect they are 
note copied into the buffer passed to the applications.

>
> Also, the NAT chain is not having packets passing through it.
>
> [root@arch-linux ~]# snat
> -P PREROUTING ACCEPT -c 0 0
> -P INPUT ACCEPT -c 0 0
> -P OUTPUT ACCEPT -c 0 0
> -P POSTROUTING ACCEPT -c 0 0
> -A PREROUTING -c 0 0 -j NFLOG --nflog-group 9
>
> That is odd cause I am not able to manipulate the packets.
>
> I will run a ping from the local Linux (10.10.10.2) and see how the packets 
are flowing through the iptables chains and will update in another email.
>

The *nat table is only consulted for the first packet of a connection.

Kind regards
Noel


Am 31.08.21 um 17:22 schrieb Tiago Stoco:
> Hi Tobias,
>
> First of all, THANKS for replying and clarifying some settings.
>
> I have completely disabled the bypass-lan plugin since I do not have a use 
for it right now.
>
> [root@arch-linux ~]# cat /etc/strongswan.conf
> ...
>     plugins {
>     include strongswan.d/charon/*.conf
>     bypass-lan {
>     load = no
>     }
> ...
>
> And, I have moved the route for the VTI to table 220 because it seems to be 
the right way to config routed based IPSec VPN.
>
> [root@arch-linux ~]# ip rule
> 0:  from all lookup local
> 220:    from all lookup 220
> 32766:  from all lookup main
> 32767:  from all lookup default
>
> [root@arch-linux ~]# ip r s t 220
> 10.10.10.0/30 via 10.10.10.2 dev ip_vti1 src 10.10.10.2
>
> [root@arch-linux ~]# ip route
> default via 192.168.45.1 dev ens18
> 192.168.45.0/24 dev ens18 proto kernel scope link src 192.168.45.30
>
> I am going to add some more details of my configs because the TX Errors 
NoRoute are still present.
>
> 7: ip_vti1@NONE:  mtu 1436 qdisc noqueue state 
UNKNOWN group default qlen 1000
>     link/ipip 192.168.45.30pe

Re: [strongSwan] IPSec route based VPN - VTI interface TX Errors NoRoute

[Noel Kuntze]

Hello Tiago,


And, I have moved the route for the VTI to table 220 because it seems to be the 
right way to config routed based IPSec VPN.

[root@arch-linux ~]# ip rule
0:  from all lookup local
220:from all lookup 220
32766:  from all lookup main
32767:  from all lookup default


Don't do that.
220 is managed by strongSwan. Keep them in the main table.


-A PREROUTING -d 10.10.10.0/30 -c 2352 230776 -j MARK --set-xmark 
0x2a/0x
-A OUTPUT -d 10.10.10.0/30 -c 3605 336028 -j MARK --set-xmark 0x2a/0x


Disable the connmark plugin.



I have added a few more NFLOG captures into my iptables and I am a bit confused 
with the results.

A tcpdump capture in the VTI interface with a ping from the remote ( pfSense - 
10.10.10.1 ) shows :

No   Time  SourceDestination

1 0.00 10.10.10.1 10.10.10.2 ICMP 84 Echo (ping) request  id=0x9877, 
seq=471/55041, ttl=64 (reply in 2)
2 0.38 10.10.10.2 > 10.10.10.1 ICMP 84 Echo (ping) replyid=0x9877, 
seq=471/55041, ttl=64 (request in 1)

I do not see the IPSec MARK in these packets.


They are only visible in the output of the TRACE target. I suspect they are 
note copied into the buffer passed to the applications.



Also, the NAT chain is not having packets passing through it.

[root@arch-linux ~]# snat
-P PREROUTING ACCEPT -c 0 0
-P INPUT ACCEPT -c 0 0
-P OUTPUT ACCEPT -c 0 0
-P POSTROUTING ACCEPT -c 0 0
-A PREROUTING -c 0 0 -j NFLOG --nflog-group 9

That is odd cause I am not able to manipulate the packets.

I will run a ping from the local Linux (10.10.10.2) and see how the packets are 
flowing through the iptables chains and will update in another email.



The *nat table is only consulted for the first packet of a connection.

Kind regards
Noel


Am 31.08.21 um 17:22 schrieb Tiago Stoco:

Hi Tobias,

First of all, THANKS for replying and clarifying some settings.

I have completely disabled the bypass-lan plugin since I do not have a use for 
it right now.

[root@arch-linux ~]# cat /etc/strongswan.conf
...
    plugins {
    include strongswan.d/charon/*.conf
    bypass-lan {
    load = no
    }
...

And, I have moved the route for the VTI to table 220 because it seems to be the 
right way to config routed based IPSec VPN.

[root@arch-linux ~]# ip rule
0:  from all lookup local
220:    from all lookup 220
32766:  from all lookup main
32767:  from all lookup default

[root@arch-linux ~]# ip r s t 220
10.10.10.0/30 via 10.10.10.2 dev ip_vti1 src 10.10.10.2

[root@arch-linux ~]# ip route
default via 192.168.45.1 dev ens18
192.168.45.0/24 dev ens18 proto kernel scope link src 192.168.45.30

I am going to add some more details of my configs because the TX Errors NoRoute 
are still present.

7: ip_vti1@NONE:  mtu 1436 qdisc noqueue state 
UNKNOWN group default qlen 1000
    link/ipip 192.168.45.30peer 192.168.45.10promiscuity 0 minmtu 0 maxmtu 0
    vti remote 192.168.45.10 local 192.168.45.30 ikey 0.0.0.42 okey 0.0.0.42 
numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
    inet 10.10.10.2peer 10.10.10.1/32 scope global ip_vti1
   valid_lft forever preferred_lft forever
    inet6 fe80::5efe:c0a8:2d1e/64 scope link
   valid_lft forever preferred_lft forever

I can also see that the IPSec added some rules to MARK packets in my iptables.

-A PREROUTING -d 10.10.10.0/30 -c 2352 230776 -j MARK --set-xmark 
0x2a/0x
-A OUTPUT -d 10.10.10.0/30 -c 3605 336028 -j MARK --set-xmark 0x2a/0x

The counters confirms that the packets are being marked. I am not sure if I 
should keep the MARK in iptables or remove it allowing routing decisions to 
send the packets to the VTI device that will MARK the packets but according to 
my understanding it should not matter.

[root@arch-linux ~]# ip xfrm policy
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
src ::/0 dst ::/0
    socket in priority 0 ptype main
src ::/0 dst ::/0
    socket out priority 0 ptype main
src ::/0 dst ::/0
    socket in priority 0 ptype main
src ::/0 dst ::/0
    socket out priority 0 ptype main

Above are the policies installed. Again, because it is a routed base VPN seems 
correct.

[root@arch-linux ~]# ip xfrm state
src 192.168.45.30 dst 192.168.45.10
    proto esp spi 0xc2239b57 reqid 1 mode tunnel
    replay-window 0 flag af-unspec
    mark 0x2a/0x
    aead rfc4106(gcm(aes)) 
0x264acee3119a4e523af2fbf5905b50c5acc1f7be9079ff23ffa2c6473a9c507fe1ae936b 128
    anti-replay context: seq 0x0, oseq 0x0, bitmap 0x
src 192.168.45.10 dst 192.168.45.30
    proto esp spi 0xc661b9e5 reqid 1 mode tunnel
    replay-window 32 flag af-unspec
    aead rfc4106(gcm(aes)) 

Re: [strongSwan] "ipsec purgecrls" vs VICI clear-creds

[Noel Kuntze]

Hello Philip,

The answer is implicite.
It answered the following question:

> If a CRL is a credential, does clear-creds duplicate the "ipsec purgcrls" 
command, making the separate command redundant?

A CRL is not a credential, so calling clear-creds does not inherently duplicate 
it, given the description from the help message.

The description in README.md in the vici plugin directory is the following (for 
the interesting things):


### flush-certs() ###

Flushes the certificate cache. The optional type argument allows to flush
only certificates of a given type, e.g. all cached CRLs.

    {
        type = 
    } => {
        success = 
        errmsg = 
    }

### clear-creds() ###

Clear all loaded certificate, private key and shared key credentials. This
affects only credentials loaded over vici, but additionally flushes the
credential cache.

    {} => {
        success = 
        errmsg = 
    }

The description of "flush-certs" indicates it flushes the certificate cache, 
and can be told ot only flush certain types of certificates.
It implies CRLs were a type of certificate (they're actually not, they're a 
signed list of certificates. They don't certify any identity.).

The description of "clear-creds" indicates that it flushes all loaded 
certificates, private keys, and shared key credentials.
Given the implication of the description of "flush-certs", this pertains CRLs, 
too.

But let's look at the code.

There are the clear-creds and flush-certs requests that are usable via VICI. 
Sending these requests make the daemon execute the following code respectively 
(see first parameter to CALLBACK for the name of the function that is 
declared)[1]:

CALLBACK(clear_creds, vici_message_t*,
    private_vici_cred_t *this, char *name, u_int id, vici_message_t *message)
{
    this->creds->clear(this->creds);
    this->authority->clear_ca_certs(this->authority);
    lib->credmgr->flush_cache(lib->credmgr, CERT_ANY);

    return create_reply(NULL);
}

CALLBACK(flush_certs, vici_message_t*,
    private_vici_cred_t *this, char *name, u_int id, vici_message_t *message)
{
    certificate_type_t type = CERT_ANY;
    x509_flag_t flag = X509_NONE;
    char *str;

    str = message->get_str(message, NULL, "type");
    if (str && !enum_from_name(certificate_type_names, str, ) &&
               !vici_cert_info_from_str(str, , ))
    {
        return create_reply("invalid certificate type '%s'", str);
    }
    lib->credmgr->flush_cache(lib->credmgr, type);

    return create_reply(NULL);
}

We can see that "clear-creds" flushes all creds in the daemon, all ca 
certificates, and all cached certificates.
"flush-certs" flushes all either the given type of "certificate" (or CRL), or 
any certificate and all CRLs.

IMHO the description should be changed to indicate it pertains CRLs, too.

End result: You can replace the call to purgecrls with a VICI request for "flush-certs" 
with type "x509crl"[2].

Kind regards
Noel

[1] from vici_cred.c
[2] from vici_cert_info.c


Am 04.08.21 um 19:27 schrieb Taylor, Philip (Space & Defence):

Noel,
Thanks for responding.

Your response does not answer my question, so I modify my question. Everything 
is loaded via VICI , nothing is loaded with ipsec commands or with 
configuration files.

Does the application need both commands when all certificates and CRLs are 
installed via VICI?

PhilT


Public

-Original Message-
From: Noel Kuntze 
Sent: 04 August 2021 15:50
To: Taylor, Philip (Space & Defence) ; 
Users@lists.strongswan.org
Subject: Re: [strongSwan] "ipsec purgecrls" vs VICI clear-creds

Hi Philip,

CRLs are Certificate Revocation Lists.
They're not secrets.

Kind regards
Noel

Am 04.08.21 um 14:29 schrieb Taylor, Philip (Space & Defence):

I am looking at some old application code that executes the command "ipsec 
purgecrls" and then sends the VICI command clear-creds.

Man ipsec purgecrls reveals

      Purgecrls - purges all cached CRLS

VICI protocola web page describes clear-creds as

Clear all loaded certificates, private key and shared key credentials.

This affects only credentials loaded over vici, but additionally flushes the 
credential store.

If a CRL is a credential, does clear-creds duplicate the "ipsec purgcrls" 
command, making the separate command redundant?

Does the code need to send both commands?

*Philip Taylor*


Public






OpenPGP_signature
Description: OpenPGP digital signature

Re: [strongSwan] reconect "loop" with: invalid HASH_V1 payload length, decryption failed

[Noel Kuntze]

Hello Lorenzo,

Looks like the log is truncated between 08:04:33 and 08:10:03.
Please provide complete logs, and get logs from the other peer.
See the HelpRequests article on the wiki for useful debug levels[1].

Kind regards
Noel

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

Am 04.08.21 um 08:15 schrieb Lorenzo Milesi:

I've a tunnel between a Fortigate 50E and a StrongSwan 5.8.2 server. The tunnel 
is normally up and running but every x minutes the connection is dropped for 
one minute, and then comes up again.
I checked the FAQs about that error, so I tried explicitly setting PSK for the 
IP address (I had %any before), it seems to last longer but the drop is still 
happening regularly.
Why rekeying doesn't work if connection does?
thanks


Aug  4 08:04:32 vpn01 charon: 06[ENC] generating QUICK_MODE request 1670801381 
[ HASH SA No KE ID ID ]
Aug  4 08:04:32 vpn01 charon: 06[NET] sending packet: from strongswan_ip[4500] 
to forti_ip[4500] (588 bytes)
Aug  4 08:04:32 vpn01 charon: 07[NET] received packet: from forti_ip[4500] to 
strongswan_ip[4500] (92 bytes)
Aug  4 08:04:32 vpn01 charon: 07[ENC] parsed INFORMATIONAL_V1 request 
2622873796 [ HASH D ]
Aug  4 08:04:32 vpn01 charon: 07[IKE] received DELETE for ESP CHILD_SA with SPI 
168c51e3
Aug  4 08:04:32 vpn01 charon: 07[IKE] CHILD_SA not found, ignored
Aug  4 08:04:32 vpn01 charon: 08[NET] received packet: from forti_ip[4500] to 
strongswan_ip[4500] (92 bytes)
Aug  4 08:04:32 vpn01 charon: 08[ENC] parsed INFORMATIONAL_V1 request 474486553 
[ HASH D ]
Aug  4 08:04:32 vpn01 charon: 08[IKE] received DELETE for ESP CHILD_SA with SPI 
168c51e1
Aug  4 08:04:32 vpn01 charon: 08[IKE] CHILD_SA not found, ignored
Aug  4 08:04:32 vpn01 charon: 16[NET] received packet: from forti_ip[4500] to 
strongswan_ip[4500] (92 bytes)
Aug  4 08:04:32 vpn01 charon: 16[ENC] parsed INFORMATIONAL_V1 request 
3851758626 [ HASH D ]
Aug  4 08:04:32 vpn01 charon: 16[IKE] received DELETE for ESP CHILD_SA with SPI 
168c51e2
Aug  4 08:04:32 vpn01 charon: 16[IKE] CHILD_SA not found, ignored
Aug  4 08:04:32 vpn01 charon: 12[NET] received packet: from forti_ip[4500] to 
strongswan_ip[4500] (92 bytes)
Aug  4 08:04:32 vpn01 charon: 12[ENC] parsed INFORMATIONAL_V1 request 
3352306708 [ HASH D ]
Aug  4 08:04:32 vpn01 charon: 12[IKE] received DELETE for ESP CHILD_SA with SPI 
168c51e4
Aug  4 08:04:32 vpn01 charon: 12[IKE] CHILD_SA not found, ignored
Aug  4 08:04:32 vpn01 charon: 11[NET] received packet: from forti_ip[4500] to 
strongswan_ip[4500] (572 bytes)
Aug  4 08:04:32 vpn01 charon: 11[ENC] parsed QUICK_MODE request 2074613372 [ 
HASH SA No KE ID ID ]
Aug  4 08:04:32 vpn01 charon: 11[CFG] selected proposal: 
ESP:AES_CBC_256/HMAC_SHA2_256_128/MODP_3072/NO_EXT_SEQ
Aug  4 08:04:32 vpn01 charon: 11[IKE] received 3600s lifetime, configured 86400s
Aug  4 08:04:32 vpn01 charon: 15[IKE] remote host is behind NAT
Aug  4 08:04:32 vpn01 charon: 14[IKE] remote host is behind NAT
Aug  4 08:04:32 vpn01 charon: 11[ENC] generating QUICK_MODE response 2074613372 
[ HASH SA No KE ID ID ]
Aug  4 08:04:33 vpn01 charon: 11[NET] sending packet: from strongswan_ip[4500] 
to forti_ip[4500] (588 bytes)
Aug  4 08:04:33 vpn01 charon: 12[NET] received packet: from forti_ip[4500] to 
strongswan_ip[4500] (604 bytes)
Aug  4 08:04:33 vpn01 charon: 12[ENC] invalid HASH_V1 payload length, 
decryption failed?
Aug  4 08:04:33 vpn01 charon: 12[ENC] could not decrypt payloads
Aug  4 08:04:33 vpn01 charon: 12[IKE] message parsing failed
Aug  4 08:04:33 vpn01 charon: 12[ENC] generating INFORMATIONAL_V1 request 
2030801044 [ HASH N(PLD_MAL) ]
Aug  4 08:10:03 vpn01 charon: 10[IKE] giving up after 5 retransmits
Aug  4 08:10:03 vpn01 charon: 10[IKE] restarting CHILD_SA remote01-lan
Aug  4 08:10:03 vpn01 charon: 10[IKE] initiating Main Mode IKE_SA 
remote01-base[151609] to forti_ip
Aug  4 08:10:03 vpn01 charon: 10[ENC] generating ID_PROT request 0 [ SA V V V V 
V ]
Aug  4 08:10:03 vpn01 charon: 10[NET] sending packet: from strongswan_ip[500] 
to forti_ip[500] (240 bytes)
Aug  4 08:10:03 vpn01 charon: 10[IKE] restarting CHILD_SA remote01-wifi
Aug  4 08:10:03 vpn01 charon: 11[NET] received packet: from forti_ip[500] to 
strongswan_ip[500] (188 bytes)
Aug  4 08:10:03 vpn01 charon: 11[ENC] parsed ID_PROT response 0 [ SA V V V V V ]
Aug  4 08:10:03 vpn01 charon: 11[IKE] received NAT-T (RFC 3947) vendor ID
Aug  4 08:10:03 vpn01 charon: 11[IKE] received DPD vendor ID
Aug  4 08:10:03 vpn01 charon: 11[ENC] received unknown vendor ID: 
82:99:03:17:57:a3:60:82:c6:a6:21:de:00:00:00:00
Aug  4 08:10:03 vpn01 charon: 11[IKE] received FRAGMENTATION vendor ID
Aug  4 08:10:03 vpn01 charon: 11[IKE] received FRAGMENTATION vendor ID
Aug  4 08:10:03 vpn01 charon: 11[CFG] selected proposal: 
IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_3072
Aug  4 08:10:03 vpn01 charon: 08[KNL] creating delete job for CHILD_SA 
ESP/0xc4e0d6cf/strongswan_ip
Aug  4 08:10:03 vpn01 charon: 08[JOB] CHILD_SA ESP/0xc4e0d6cf/strongswan_ip not 

Re: [strongSwan] "ipsec purgecrls" vs VICI clear-creds

[Noel Kuntze]

Hi Philip,

CRLs are Certificate Revocation Lists.
They're not secrets.

Kind regards
Noel

Am 04.08.21 um 14:29 schrieb Taylor, Philip (Space & Defence):

I am looking at some old application code that executes the command “ipsec 
purgecrls” and then sends the VICI command clear-creds.

Man ipsec purgecrls reveals

     Purgecrls – purges all cached CRLS

VICI protocola web page describes clear-creds as

Clear all loaded certificates, private key and shared key credentials.

This affects only credentials loaded over vici, but additionally flushes the 
credential store.

If a CRL is a credential, does clear-creds duplicate the “ipsec purgcrls” 
command, making the separate command redundant?

Does the code need to send both commands?

*Philip Taylor*


Public





OpenPGP_signature
Description: OpenPGP digital signature

Re: [strongSwan] VPN Suddenly Stopped Forwarding Internet

[Noel Kuntze]

Hello Jody,

Please provide the output of `iptables-save`, and the output of `ipsec 
statusall` once you tried to access the internet, but while the client is still 
connected.

Kind regards
Noel

Am 02.08.21 um 20:26 schrieb Jody Whitesides:

Having trouble trying to understand why VPN would suddenly stop allowing 
traffic to the internet (despite no changes to the server and was working fine 
for months). Devices can connect to the VPN and logs show they connect. 
However, they no longer get traffic to the internet or to the server itself. 
Unfortunately I don’t understand the logs enough to know the direct reason, but 
I’ve included some connection logs after the config. Any help that can lead to 
a fix would be appreciated.

Here’s the config:

config setup
         charondebug     ="dmn 1,mgr 1,ike 1,chd 1,job 1,cfg 1,knl 1,net 1,tls 1,lib 
1,enc 1,tnc 1"
         uniqueids       =no

conn %default
#        ike             =aes256-sha1-modp1024,3des-sha1-modp1024!
#        esp             =aes256-sha1,3des-sha1!
         fragmentation   =yes
         auto            =add
         dpdaction       =clear
         dpddelay        =40
         dpdtimeout      =130
         ikelifetime     =1h
         lifetime        =1h
         margintime      =9m
         rekeyfuzz       =100%
#        rekey           =yes
         aggressive      =no
         forceencaps     =yes
         left            =%any
         leftid          =(serverIP)
         leftcert        =(link to cert)
         leftsendcert    =always
         leftsubnet      =0.0.0.0/0,::/0
         right           =%any
         rightid         =%any
#        rightauth       =eap-mschapv2
         rightdns        
=45.76.254.23,172.98.193.62,2001:19f0:5401:2a4a:5400:03ff:fe2b:271f
         rightsourceip   =10.10.10.1/24
         rightsubnet     =%dynamic

#conn mac
#       keyexchange     =ikev1
#       authby          =xauthpsk
#       xauth           =server
#       reauth          =yes

conn ios
         ike             =aes256-sha1-modp1024,3des-sha1-modp1024!
         esp             =aes256-sha1,3des-sha1!
         keyexchange     =ikev1
         mobike          =yes
         reauth          =yes
         rekey           =yes
         leftallowany    =yes
         lefthostaccess  =yes
         leftfirewall    =yes
         leftauth        =pubkey
         rightallowany   =yes
         rightauth       =pubkey
         rightauth2      =xauth
         rightfirewall   =yes
         rightcert       =(link to cert)

conn ikev2-vpn
         ike             
=chacha20poly1305-sha512-curve25519-prfsha512,aes256gcm16-sha384-prfsha384-ecp384,aes128-sha1-modp1024,aes256-sha1-modp1024,3d>
         esp             
=chacha20poly1305-sha512,aes256gcm16-ecp384,aes256-sha256,aes256-sha1,3des-sha1!
         keyexchange     =ikev2
         type            =tunnel
         compress        =no
         rekey           =no
         rightauth       =eap-mschapv2
         rightsendcert   =never
         eap_identity    =%identity

Here’s the Log:
Aug  2 12:13:34 jodywhitesides *charon*-custom: 06[NET] received packet: from 
[IP of Device][500] to [IP of Server][500] (848 bytes)
Aug  2 12:13:34 jodywhitesides *charon*-custom: 06[ENC] parsed ID_PROT request 
0 [ SA V V V V V V V V V V V V V V ]
Aug  2 12:13:34 jodywhitesides *charon*-custom: 06[IKE] received NAT-T (RFC 
3947) vendor ID
Aug  2 12:13:34 jodywhitesides *charon*-custom: 06[IKE] received 
draft-ietf-ipsec-nat-t-ike vendor ID
Aug  2 12:13:34 jodywhitesides *charon*-custom: 06[IKE] received 
draft-ietf-ipsec-nat-t-ike-08 vendor ID
Aug  2 12:13:34 jodywhitesides *charon*-custom: 06[IKE] received 
draft-ietf-ipsec-nat-t-ike-07 vendor ID
Aug  2 12:13:34 jodywhitesides *charon*-custom: 06[IKE] received 
draft-ietf-ipsec-nat-t-ike-06 vendor ID
Aug  2 12:13:34 jodywhitesides *charon*-custom: 06[IKE] received 
draft-ietf-ipsec-nat-t-ike-05 vendor ID
Aug  2 12:13:34 jodywhitesides *charon*-custom: 06[IKE] received 
draft-ietf-ipsec-nat-t-ike-04 vendor ID
Aug  2 12:13:34 jodywhitesides *charon*-custom: 06[IKE] received 
draft-ietf-ipsec-nat-t-ike-03 vendor ID
Aug  2 12:13:34 jodywhitesides *charon*-custom: 06[IKE] received 
draft-ietf-ipsec-nat-t-ike-02 vendor ID
Aug  2 12:13:34 jodywhitesides *charon*-custom: 06[IKE] received 
draft-ietf-ipsec-nat-t-ike-02\n vendor ID
Aug  2 12:13:34 jodywhitesides *charon*-custom: 06[IKE] received XAuth vendor ID
Aug  2 12:13:34 jodywhitesides *charon*-custom: 06[IKE] received Cisco Unity 
vendor ID
Aug  2 12:13:34 jodywhitesides *charon*-custom: 06[IKE] received FRAGMENTATION 
vendor ID
Aug  2 12:13:34 jodywhitesides *charon*-custom: 06[IKE] received DPD vendor ID
Aug  2 12:13:34 jodywhitesides *charon*-custom: 06[IKE] [IP of Device] is 
initiating a Main Mode IKE_SA
Aug  2 12:13:34 jodywhitesides *charon*-custom: 06[CFG] selected proposal: 
IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
Aug  2 12:13:34 jodywhitesides *charon*-custom: 06[ENC] generating ID_PROT 
response 0 

Re: [strongSwan] revisiting problem with linux to VPN using network-manager-strongswan 1.4.5-2.1

[Noel Kuntze]

Hello David,

Yes, that shows that it is working.

Kind regards
Noel

Am 28.07.21 um 22:31 schrieb David H Durgee:

I did a bit more checking and found references to "ip xfrm policy list" and "ip xfrm 
state list" as possible sources of the confirmation of operation I am seeking.  I ran these 
commands with the VPN up and have attached the output of these commands.

I am not trained in reading these reports, but what I see does appear to 
indicate that the VPN is indeed functioning and handling the traffic as 
requested.  If someone who is trained could confirm this for me I would 
appreciate it.

Dave


Noel Kuntze wrote:  Hello David,

strongSwan by default builds policy based tunnels, not route based tunnels.
Thus no interface is needed or created.
Read up on how IPsec works on the wiki to get an understanding for it.

GUI indicators are not inherently related to if any tunnel exists, or works.

Kind regards
Noel

Am 01.07.21 um 20:31 schrieb David H Durgee:

I thought it might make sense to revisit this after the progress that has been 
made. It now appears that the connection is being established:


Jun 29 11:21:34 Z560 charon-nm: 11[IKE] authentication of 
'durgeeenterprises.publicvm.com' with EAP successful
Jun 29 11:21:34 Z560 charon-nm: 11[IKE] IKE_SA Durgee Enterprises, LLC[7] 
established between 
192.168.1.114[dhdurgee]...108.31.28.59[durgeeenterprises.publicvm.com]
Jun 29 11:21:34 Z560 charon-nm: 11[IKE] scheduling rekeying in 35705s
Jun 29 11:21:34 Z560 charon-nm: 11[IKE] maximum IKE_SA lifetime 36305s
Jun 29 11:21:34 Z560 charon-nm: 11[IKE] installing new virtual IP 10.10.10.1
Jun 29 11:21:34 Z560 avahi-daemon[750]: Registering new address record for 
10.10.10.1 on wlp5s0.IPv4.
Jun 29 11:21:34 Z560 charon-nm: 11[CFG] selected proposal: 
ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ
Jun 29 11:21:34 Z560 charon-nm: 11[IKE] CHILD_SA Durgee Enterprises, LLC{4} 
established with SPIs c8cad4e5_i c3f2eec4_o and TS 10.10.10.1/32 === 0.0.0.0/0
Jun 29 11:21:34 Z560 charon-nm: 11[IKE] peer supports MOBIKE
Jun 29 11:21:34 Z560 NetworkManager[758]:  [1624980094.6991] 
vpn-connection[0x562fdb93c2f0,72e4370d-ecfb-4e33-8572-5cf04431abb9,"Durgee Enterprises, 
LLC",0]: VPN connection: (IP Config Get) reply received.
Jun 29 11:21:34 Z560 NetworkManager[758]:  [1624980094.6997] 
vpn-connection[0x562fdb93c2f0,72e4370d-ecfb-4e33-8572-5cf04431abb9,"Durgee Enterprises, 
LLC",0]: VPN plugin: state changed: started (4)
Jun 29 11:21:34 Z560 NetworkManager[758]:  [1624980094.6997] 
vpn-connection[0x562fdb93c2f0,72e4370d-ecfb-4e33-8572-5cf04431abb9,"Durgee Enterprises, 
LLC",0]: VPN connection: (IP4 Config Get) reply received
Jun 29 11:21:34 Z560 NetworkManager[758]:  [1624980094.7003] 
vpn-connection[0x562fdb93c2f0,72e4370d-ecfb-4e33-8572-5cf04431abb9,"Durgee Enterprises, 
LLC",0]: Data: VPN Gateway: 108.31.28.59
Jun 29 11:21:34 Z560 NetworkManager[758]:  [1624980094.7003] 
vpn-connection[0x562fdb93c2f0,72e4370d-ecfb-4e33-8572-5cf04431abb9,"Durgee Enterprises, 
LLC",0]: Data: Tunnel Device: (null)
Jun 29 11:21:34 Z560 NetworkManager[758]:  [1624980094.7003] 
vpn-connection[0x562fdb93c2f0,72e4370d-ecfb-4e33-8572-5cf04431abb9,"Durgee Enterprises, 
LLC",0]: Data: IPv4 configuration:
Jun 29 11:21:34 Z560 NetworkManager[758]:  [1624980094.7003] 
vpn-connection[0x562fdb93c2f0,72e4370d-ecfb-4e33-8572-5cf04431abb9,"Durgee Enterprises, 
LLC",0]: Data:   Internal Address: 10.10.10.1
Jun 29 11:21:34 Z560 NetworkManager[758]:  [1624980094.7004] 
vpn-connection[0x562fdb93c2f0,72e4370d-ecfb-4e33-8572-5cf04431abb9,"Durgee Enterprises, 
LLC",0]: Data:   Internal Prefix: 32
Jun 29 11:21:34 Z560 NetworkManager[758]:  [1624980094.7004] 
vpn-connection[0x562fdb93c2f0,72e4370d-ecfb-4e33-8572-5cf04431abb9,"Durgee Enterprises, 
LLC",0]: Data:   Internal Point-to-Point Address: 10.10.10.1
Jun 29 11:21:34 Z560 NetworkManager[758]:  [1624980094.7004] 
vpn-connection[0x562fdb93c2f0,72e4370d-ecfb-4e33-8572-5cf04431abb9,"Durgee Enterprises, 
LLC",0]: Data:   Internal DNS: 8.8.8.8
Jun 29 11:21:34 Z560 NetworkManager[758]:  [1624980094.7004] 
vpn-connection[0x562fdb93c2f0,72e4370d-ecfb-4e33-8572-5cf04431abb9,"Durgee Enterprises, 
LLC",0]: Data:   Internal DNS: 8.8.4.4
Jun 29 11:21:34 Z560 NetworkManager[758]:  [1624980094.7004] 
vpn-connection[0x562fdb93c2f0,72e4370d-ecfb-4e33-8572-5cf04431abb9,"Durgee Enterprises, 
LLC",0]: Data:   DNS Domain: '(none)'
Jun 29 11:21:34 Z560 NetworkManager[758]:  [1624980094.7004] 
vpn-connection[0x562fdb93c2f0,72e4370d-ecfb-4e33-8572-5cf04431abb9,"Durgee Enterprises, 
LLC",0]: Data: No IPv6 configuration
Jun 29 11:21:34 Z560 NetworkManager[758]:  [1624980094.7013] 
vpn-connection[0x562fdb93c2f0,72e4370d-ecfb-4e33-8572-5cf04431abb9,"Durgee Enterprises, 
LLC",0]: VPN connection: (IP Config Get) complete


Unfortunately I am not seeing a tunnel interface being crea

Re: [strongSwan] transport mode android problems

[Noel Kuntze]

Hello Lewis,

That is because the Android app can only reasonably support tunnel mode with 
virtual IPs.
See the wiki article[1] for it, please.

Kind regards
Noel

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

Am 22.07.21 um 15:31 schrieb Lewis Robson:

Hi all,

I am having trouble connecting an android device to strongswan in transport 
mode.

android works with tunnel mode and certificates
android doesnt work with transport mode and certificates


here is my current config I am using for testing transport mode (working tunnel 
mode conf below)

conn host
     left=myexternalip
     leftcert=mycert
     leftsendcert=always
     leftauth=pubkey
     right=%any
     rightid=%any
     type=transport
     auto=add
     rightauth=pubkey
     authby=pubkey



error im seeing

from server end:

peer requested virtual IP %any
no virtual IP found, sending INTERNAL_ADDRESS_FAILURE
Jul 22 14:25:50 cerberus charon: 16[IKE] configuration payload negotiation 
failed, no CHILD_SA built
Jul 22 14:25:50 cerberus charon: 16[IKE] failed to establish CHILD_SA, keeping 
IKE_SA


from android end:

received internal address failure notify, no child sa built

closing ike sa due child sa setup failure

config that works with android device in tunnel mode and x509 certificates 
thats working below

(removing left subnet, changing type and removing right source ip breaks the 
connection ad i cant get in)

conn phones-on
     auto=add
     compress=no
     type=tunnel
     keyexchange=ikev2
     fragmentation=yes
     forceencaps=yes
     dpdaction=clear
     dpddelay=300s
     rekey=no
     left=%any
     leftid=externalip
     leftcert=mycert
     leftsendcert=always
     leftsubnet=0.0.0.0/0
     right=%any
     rightid=%any
     rightsendcert=always
     rightauth=pubkey
     authby=pubkey
     #rightauth=eap-mschapv2
     rightsourceip=10.10.10.0/24
     rightdns=8.8.8.8,8.8.4.4
     rightsendcert=never
     eap_identity=%identity
ike=chacha20poly1305-sha512-curve25519-prfsha512,aes256gcm16-sha384-prfsha384-ecp384,aes256-sha1-modp1024,aes128-sha1-modp1024,3des-sha1-modp1024!



any ideas?

thankyou :)





OpenPGP_signature
Description: OpenPGP digital signature

Re: [strongSwan] AWS EC2 IKEv2 tunnel up but no throughput

[noel . kuntze+strongswan-users-ml]

Hello Lew,

How exactly are you testing the tunnel?
Also, please provide the output of iptables-save.

Kind regards
Noel

Am July 5, 2021 7:28:19 AM UTC schrieb Lewis Shobbrook 
:
>Hi Guys,
>I have an IKEv2 tunnel that is established and up, but I am unable to
>route any packets across it.
>All ACL's are configured to allow UDP 500,4500 & protocols 50, 51 &
>icmp to/from the non aws end.
>Local iptables are permissive with default policys ACCEPT
>Security groups also allow anything outbound and the above ports &
>protos inbound.
>Here are a few particulars typically requested ahead of time.
>ip_forward is enabled rp_filter disabled as follows...
>net.ipv4.ip_forward = 1
>net.ipv4.conf.all.send_redirects = 0
>net.ipv4.conf.default.send_redirects = 0
>net.ipv4.tcp_max_syn_backlog = 1280
>net.ipv4.icmp_echo_ignore_broadcasts = 1
>net.ipv4.conf.all.accept_source_route = 0
>net.ipv4.conf.all.accept_redirects = 0
>net.ipv4.conf.all.secure_redirects = 0
>net.ipv4.conf.all.log_martians = 1
>net.ipv4.conf.default.accept_source_route = 0
>net.ipv4.conf.default.accept_redirects = 0
>net.ipv4.conf.default.secure_redirects = 0
>net.ipv4.icmp_echo_ignore_broadcasts = 1
>net.ipv4.icmp_ignore_bogus_error_responses = 1
>net.ipv4.tcp_syncookies = 1
>net.ipv4.conf.all.rp_filter = 0
>net.ipv4.conf.default.rp_filter = 0
>net.ipv4.tcp_mtu_probing = 1
>
>tcpdump just shows one way requests
>Looking at the 220 rt table I can see that the auto added route
>appears to be correct, and the xfrm policy nothing obvious to me, with
>no xfrm vi's used.
>Obfuscated ip's naturally...
>ip r li ta 220
>198.168.248.0/29 via 48.138.201.65 dev eth0 proto static src
>48.138.201.70
>ip xfrm policy
>src 48.138.201.64/26 dst 198.168.248.0/29
>dir out priority 371839 ptype main
>tmpl src 48.138.201.70 dst 68.169.15.170
>proto esp spi 0x2c1e849e reqid 1 mode tunnel
>src 198.168.248.0/29 dst 48.138.201.64/26
>dir fwd priority 371839 ptype main
>tmpl src 68.148.15.170 dst 48.138.201.70
>proto esp reqid 1 mode tunnel
>src 198.168.248.0/29 dst 48.138.201.64/26
>dir in priority 371839 ptype main
>tmpl src 68.148.15.170 dst 48.138.201.70
>proto esp reqid 1 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
>src ::/0 dst ::/0
>socket in priority 0 ptype main
>src ::/0 dst ::/0
>socket out priority 0 ptype main
>src ::/0 dst ::/0
>socket in priority 0 ptype main
>src ::/0 dst ::/0
>socket out priority 0 ptype main
>src 198.168.248.0/29 dst 48.138.201.64/26
>dir fwd priority 371840 ptype main
>tmpl src 68.148.15.170 dst 48.138.201.70
>proto esp reqid 2 mode tunnel
>src 198.168.248.0/29 dst 48.138.201.64/26
>dir in priority 371840 ptype main
>tmpl src 68.148.15.170 dst 48.138.201.70
>proto esp reqid 2 mode tunnel
>src 48.138.201.64/26 dst 198.168.248.0/29
>dir out priority 371840 ptype main
>tmpl src 48.138.201.70 dst 68.169.15.170
>proto esp reqid 2 mode tunnel
>
>ipsec statusall
>Status of IKE charon daemon (strongSwan 5.7.2, Linux
>4.14.232-177.418.amzn2.x86_64, x86_64):
>  uptime: 54 minutes, since Jul 05 06:10:30 2021
>  malloc: sbrk 2846720, mmap 0, used 1023696, free 1823024
>  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0,
>scheduled: 1
>  loaded plugins: charon pkcs11 tpm aesni aes des rc2 sha2 sha1 md4
>md5 mgf1 random nonce x509 revocation constraints acert pubkey pkcs1
>pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl gcrypt fips-prf gmp
>curve25519 chapoly xcbc cmac hmac ctr ccm gcm curl attr kernel-netlink
>resolve socket-default farp stroke vici updown eap-identity eap-sim
>eap-aka eap-aka-3gpp eap-aka-3gpp2 eap-md5 eap-gtc eap-mschapv2
>eap-dynamic eap-radius eap-tls eap-ttls eap-peap xauth-generic
>xauth-eap xauth-pam xauth-noauth dhcp led duplicheck unity counters
>Listening IP addresses:
>  48.138.201.70
>Connections:
>tunnel1:  %any...68.148.15.170  IKEv2
>tunnel1:   local:  uses pre-shared key authentication
>tunnel1:   remote: uses pre-shared key authentication
>tunnel1:   child:  48.138.201.64/26 === 198.168.248.0/29 TUNNEL
>Security Associations (1 up, 0 connecting):
>tunnel1[2]: ESTABLISHED 24 minutes ago,
>48.138.201.70[48.138.201.70]...65.169.15.170[65.169.15.170]
>tunnel1[2]: IKEv2 SPIs: d3e732eb14d78aec_i* b06860d1ceee2f9a_r,
>rekeying disabled
>tunnel1[2]: IKE proposal: AES_GCM_16_256/PRF_HMAC_SHA2_384/ECP_384
>tunnel1{2}:  INSTALLED, TUNNEL, reqid 2, ESP in UDP SPIs: cb651f89_i
>479cff91_o
>tunnel1{2}:  AES_GCM_16_256, 0 bytes_i, 0 bytes_o, rekeying disabled
>tunnel1{2}:   48.138.201.64/26 === 198.168.248.0/30
>
>VPC flow logs show no proto 50, only 4500 & 500.
>I've also tried to clamp mss not that I expect it would have changed 0
>throughput
>iptables -t mangle -A FORWARD 

Re: [strongSwan] revisiting problem with linux to VPN using network-manager-strongswan 1.4.5-2.1

[Noel Kuntze]

Hello David,

strongSwan by default builds policy based tunnels, not route based tunnels.
Thus no interface is needed or created.
Read up on how IPsec works on the wiki to get an understanding for it.

GUI indicators are not inherently related to if any tunnel exists, or works.

Kind regards
Noel

Am 01.07.21 um 20:31 schrieb David H Durgee:

I thought it might make sense to revisit this after the progress that has been 
made. It now appears that the connection is being established:


Jun 29 11:21:34 Z560 charon-nm: 11[IKE] authentication of 
'durgeeenterprises.publicvm.com' with EAP successful
Jun 29 11:21:34 Z560 charon-nm: 11[IKE] IKE_SA Durgee Enterprises, LLC[7] 
established between 
192.168.1.114[dhdurgee]...108.31.28.59[durgeeenterprises.publicvm.com]
Jun 29 11:21:34 Z560 charon-nm: 11[IKE] scheduling rekeying in 35705s
Jun 29 11:21:34 Z560 charon-nm: 11[IKE] maximum IKE_SA lifetime 36305s
Jun 29 11:21:34 Z560 charon-nm: 11[IKE] installing new virtual IP 10.10.10.1
Jun 29 11:21:34 Z560 avahi-daemon[750]: Registering new address record for 
10.10.10.1 on wlp5s0.IPv4.
Jun 29 11:21:34 Z560 charon-nm: 11[CFG] selected proposal: 
ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ
Jun 29 11:21:34 Z560 charon-nm: 11[IKE] CHILD_SA Durgee Enterprises, LLC{4} 
established with SPIs c8cad4e5_i c3f2eec4_o and TS 10.10.10.1/32 === 0.0.0.0/0
Jun 29 11:21:34 Z560 charon-nm: 11[IKE] peer supports MOBIKE
Jun 29 11:21:34 Z560 NetworkManager[758]:  [1624980094.6991] 
vpn-connection[0x562fdb93c2f0,72e4370d-ecfb-4e33-8572-5cf04431abb9,"Durgee Enterprises, 
LLC",0]: VPN connection: (IP Config Get) reply received.
Jun 29 11:21:34 Z560 NetworkManager[758]:  [1624980094.6997] 
vpn-connection[0x562fdb93c2f0,72e4370d-ecfb-4e33-8572-5cf04431abb9,"Durgee Enterprises, 
LLC",0]: VPN plugin: state changed: started (4)
Jun 29 11:21:34 Z560 NetworkManager[758]:  [1624980094.6997] 
vpn-connection[0x562fdb93c2f0,72e4370d-ecfb-4e33-8572-5cf04431abb9,"Durgee Enterprises, 
LLC",0]: VPN connection: (IP4 Config Get) reply received
Jun 29 11:21:34 Z560 NetworkManager[758]:  [1624980094.7003] 
vpn-connection[0x562fdb93c2f0,72e4370d-ecfb-4e33-8572-5cf04431abb9,"Durgee Enterprises, 
LLC",0]: Data: VPN Gateway: 108.31.28.59
Jun 29 11:21:34 Z560 NetworkManager[758]:  [1624980094.7003] 
vpn-connection[0x562fdb93c2f0,72e4370d-ecfb-4e33-8572-5cf04431abb9,"Durgee Enterprises, 
LLC",0]: Data: Tunnel Device: (null)
Jun 29 11:21:34 Z560 NetworkManager[758]:  [1624980094.7003] 
vpn-connection[0x562fdb93c2f0,72e4370d-ecfb-4e33-8572-5cf04431abb9,"Durgee Enterprises, 
LLC",0]: Data: IPv4 configuration:
Jun 29 11:21:34 Z560 NetworkManager[758]:  [1624980094.7003] 
vpn-connection[0x562fdb93c2f0,72e4370d-ecfb-4e33-8572-5cf04431abb9,"Durgee Enterprises, 
LLC",0]: Data:   Internal Address: 10.10.10.1
Jun 29 11:21:34 Z560 NetworkManager[758]:  [1624980094.7004] 
vpn-connection[0x562fdb93c2f0,72e4370d-ecfb-4e33-8572-5cf04431abb9,"Durgee Enterprises, 
LLC",0]: Data:   Internal Prefix: 32
Jun 29 11:21:34 Z560 NetworkManager[758]:  [1624980094.7004] 
vpn-connection[0x562fdb93c2f0,72e4370d-ecfb-4e33-8572-5cf04431abb9,"Durgee Enterprises, 
LLC",0]: Data:   Internal Point-to-Point Address: 10.10.10.1
Jun 29 11:21:34 Z560 NetworkManager[758]:  [1624980094.7004] 
vpn-connection[0x562fdb93c2f0,72e4370d-ecfb-4e33-8572-5cf04431abb9,"Durgee Enterprises, 
LLC",0]: Data:   Internal DNS: 8.8.8.8
Jun 29 11:21:34 Z560 NetworkManager[758]:  [1624980094.7004] 
vpn-connection[0x562fdb93c2f0,72e4370d-ecfb-4e33-8572-5cf04431abb9,"Durgee Enterprises, 
LLC",0]: Data:   Internal DNS: 8.8.4.4
Jun 29 11:21:34 Z560 NetworkManager[758]:  [1624980094.7004] 
vpn-connection[0x562fdb93c2f0,72e4370d-ecfb-4e33-8572-5cf04431abb9,"Durgee Enterprises, 
LLC",0]: Data:   DNS Domain: '(none)'
Jun 29 11:21:34 Z560 NetworkManager[758]:  [1624980094.7004] 
vpn-connection[0x562fdb93c2f0,72e4370d-ecfb-4e33-8572-5cf04431abb9,"Durgee Enterprises, 
LLC",0]: Data: No IPv6 configuration
Jun 29 11:21:34 Z560 NetworkManager[758]:  [1624980094.7013] 
vpn-connection[0x562fdb93c2f0,72e4370d-ecfb-4e33-8572-5cf04431abb9,"Durgee Enterprises, 
LLC",0]: VPN connection: (IP Config Get) complete


Unfortunately I am not seeing a tunnel interface being created and routing 
added:


enp6s0: flags=4163  mtu 1500
    ether b8:70:f4:2c:6b:9f  txqueuelen 1000  (Ethernet)
    RX packets 1143393  bytes 1164336056 (1.1 GB)
    RX errors 0  dropped 20  overruns 0  frame 0
    TX packets 912738  bytes 112966285 (112.9 MB)
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73  mtu 65536
    inet 127.0.0.1  netmask 255.0.0.0
    inet6 ::1  prefixlen 128  scopeid 0x10
    loop  txqueuelen 1000  (Local Loopback)
    RX packets 95404  bytes 9207887 (9.2 MB)
    RX errors 0  dropped 0  overruns 0  frame 0
    TX packets 95404  bytes 9207887 (9.2 MB)
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlp5s0: flags=4163  mtu 1500
    inet 192.168.1.114  netmask 

Re: [strongSwan] problem connecting linux laptop to VPN using network-manager-strongswan 1.4.5-2.1

[Noel Kuntze]

Set "Request an inner IP address".

Am 28.06.21 um 15:55 schrieb David H Durgee:

Michael Schwartzkopff wrote:

On 28.06.21 15:34, David H Durgee wrote:

Michael Schwartzkopff wrote:

On 28.06.21 13:44, David H Durgee wrote:

I added that package and got further this time:


(...)
Jun 28 07:33:58 Z560 charon-nm: 06[ENC] parsed IKE_AUTH response 5 [
AUTH N(MOBIKE_SUP) N(NO_ADD_ADDR) N(FAIL_CP_REQ) N(TS_UNACCEPT) ]
Jun 28 07:33:58 Z560 charon-nm: 06[IKE] authentication of
'durgeeenterprises.publicvm.com' with EAP successful
Jun 28 07:33:58 Z560 charon-nm: 06[IKE] IKE_SA Durgee Enterprises,
LLC[1] established between
192.168.1.114[dhdurgee]...108.31.28.59[durgeeenterprises.publicvm.com]
Jun 28 07:33:58 Z560 charon-nm: 06[IKE] scheduling rekeying in 35606s
Jun 28 07:33:58 Z560 charon-nm: 06[IKE] maximum IKE_SA lifetime 36206s
Jun 28 07:33:58 Z560 charon-nm: 06[IKE] received FAILED_CP_REQUIRED
notify, no CHILD_SA built
Jun 28 07:33:58 Z560 charon-nm: 06[IKE] failed to establish CHILD_SA,
keeping IKE_SA

hi,


Your responder (Server) seems to have some kind of configured poliy
where the server waits for a configuration request from the client. But
the clients does not ask for the config and the server terminates the
connection.

Please see the logs of you server, what exactly is missing. Perhaps the
server wants to hand out an IP address to the client or something else.


Mit freundlichen Grüßen,


Looking at the log on the server I see:


Jun 28 07:33:58 DG41TY charon: 10[IKE] authentication of 'dhdurgee'
with EAP successful
Jun 28 07:33:58 DG41TY charon: 10[IKE] authentication of
'durgeeenterprises.publicvm.com' (myself) with EAP
Jun 28 07:33:58 DG41TY charon: 10[IKE] IKE_SA ikev2-vpn[61]
established between
192.168.80.11[durgeeenterprises.publicvm.com]...172.58.190.234[dhdurgee]
Jun 28 07:33:58 DG41TY charon: 10[IKE] IKE_SA ikev2-vpn[61]
established between
192.168.80.11[durgeeenterprises.publicvm.com]...172.58.190.234[dhdurgee]
Jun 28 07:33:58 DG41TY charon: 10[IKE] expected a virtual IP request,
sending FAILED_CP_REQUIRED
Jun 28 07:33:58 DG41TY charon: 10[IKE] traffic selectors 0.0.0.0/0
::/0 === 192.168.1.114/32 inacceptable
Jun 28 07:33:58 DG41TY charon: 10[IKE] failed to establish CHILD_SA,
keeping IKE_SA
Jun 28 07:33:58 DG41TY charon: 10[ENC] generating IKE_AUTH response 5
[ AUTH N(MOBIKE_SUP) N(NO_ADD_ADDR) N(FAIL_CP_REQ) N(TS_UNACCEPT) ]
Jun 28 07:33:58 DG41TY charon: 10[NET] sending packet: from
192.168.80.11[4500] to 172.58.190.234[59726] (124 bytes)
Jun 28 07:33:58 DG41TY charon: 14[NET] received packet: from
172.58.190.234[59726] to 192.168.80.11[4500] (76 bytes)
Jun 28 07:33:58 DG41TY charon: 14[ENC] parsed INFORMATIONAL request 6
[ D ]
Jun 28 07:33:58 DG41TY charon: 14[IKE] received DELETE for IKE_SA
ikev2-vpn[61]
Jun 28 07:33:58 DG41TY charon: 14[IKE] deleting IKE_SA ikev2-vpn[61]
between
192.168.80.11[durgeeenterprises.publicvm.com]...172.58.190.234[dhdurgee]
Jun 28 07:33:58 DG41TY charon: 14[IKE] deleting IKE_SA ikev2-vpn[61]
between
192.168.80.11[durgeeenterprises.publicvm.com]...172.58.190.234[dhdurgee]
Jun 28 07:33:58 DG41TY charon: 14[IKE] IKE_SA deleted
Jun 28 07:33:58 DG41TY charon: 14[IKE] IKE_SA deleted
Jun 28 07:33:58 DG41TY charon: 14[ENC] generating INFORMATIONAL
response 6 [ ]
Jun 28 07:33:58 DG41TY charon: 14[NET] sending packet: from
192.168.80.11[4500] to 172.58.190.234[59726] (76 bytes)

Looking at my settings for the network connection shows IPv4 enabled
expecting an address to be assigned automatically via DHCP with DNS
and Routes set as automatic.  The checkbox for "use this connection
only for resources on its network" is NOT checked.  The page for IPv6
is also set as automatic with the checkbox NOT checked.

On the identity page none of the options are checked.  Options are:

"Request an inner IP address"
"Enforce UDP encapsulation"
"Use IP compression"

All this should be defaults, as I only filled in the name, gateway,
certificate, authentication(EAP), username and password fields.

Dave


I don't know about the manufacturer of your server side. but did you try
to add leftsourceip=%config to your client (initiator) config? Also
%config6 for IPv6 exists. See
https://wiki.strongswan.org/projects/strongswan/wiki/VirtualIp




Mit freundlichen Grüßen,



I am configuring this client using the strongswan plugin for network manager as 
noted in the subject line.  I have attached the created network connection to 
this post for your inspection.  I guess additional lines could be edited in 
manually if necessary, but now I am wondering if I am posting in the proper 
place.  Is it possible this is a network-manager problem as opposed to 
strongswan?

Dave




OpenPGP_signature
Description: OpenPGP digital signature

Re: [strongSwan] problem connecting linux laptop to VPN using network-manager-strongswan 1.4.5-2.1

[Noel Kuntze]

Hi David,


 Jun 28 07:33:58 Z560 charon-nm: 06[IKE] received FAILED_CP_REQUIRED notify, no 
CHILD_SA built


You need to set NetworkManager to request a virtual IP.

Kind regards
Noel

Am 28.06.21 um 13:44 schrieb David H Durgee:

I added that package and got further this time:


Jun 28 07:33:57 Z560 charon-nm: 13[IKE] server requested EAP_IDENTITY (id 
0x00), sending 'dhdurgee'
Jun 28 07:33:57 Z560 charon-nm: 13[ENC] generating IKE_AUTH request 2 [ 
EAP/RES/ID ]
Jun 28 07:33:57 Z560 charon-nm: 13[NET] sending packet: from 
192.168.1.114[47031] to 108.31.28.59[4500] (92 bytes)
Jun 28 07:33:58 Z560 charon-nm: 15[NET] received packet: from 
108.31.28.59[4500] to 192.168.1.114[47031] (108 bytes)
Jun 28 07:33:58 Z560 charon-nm: 15[ENC] parsed IKE_AUTH response 2 [ 
EAP/REQ/MSCHAPV2 ]
Jun 28 07:33:58 Z560 charon-nm: 15[IKE] server requested EAP_MSCHAPV2 
authentication (id 0xB0)
Jun 28 07:33:58 Z560 charon-nm: 15[ENC] generating IKE_AUTH request 3 [ 
EAP/RES/MSCHAPV2 ]
Jun 28 07:33:58 Z560 charon-nm: 15[NET] sending packet: from 
192.168.1.114[47031] to 108.31.28.59[4500] (140 bytes)
Jun 28 07:33:58 Z560 charon-nm: 01[NET] received packet: from 
108.31.28.59[4500] to 192.168.1.114[47031] (140 bytes)
Jun 28 07:33:58 Z560 charon-nm: 01[ENC] parsed IKE_AUTH response 3 [ 
EAP/REQ/MSCHAPV2 ]
Jun 28 07:33:58 Z560 charon-nm: 01[IKE] EAP-MS-CHAPv2 succeeded: 
'Welcome2strongSwan'
Jun 28 07:33:58 Z560 charon-nm: 01[ENC] generating IKE_AUTH request 4 [ 
EAP/RES/MSCHAPV2 ]
Jun 28 07:33:58 Z560 charon-nm: 01[NET] sending packet: from 
192.168.1.114[47031] to 108.31.28.59[4500] (76 bytes)
Jun 28 07:33:58 Z560 charon-nm: 07[NET] received packet: from 
108.31.28.59[4500] to 192.168.1.114[47031] (76 bytes)
Jun 28 07:33:58 Z560 charon-nm: 07[ENC] parsed IKE_AUTH response 4 [ EAP/SUCC ]
Jun 28 07:33:58 Z560 charon-nm: 07[IKE] EAP method EAP_MSCHAPV2 succeeded, MSK 
established
Jun 28 07:33:58 Z560 charon-nm: 07[IKE] authentication of 'dhdurgee' (myself) 
with EAP
Jun 28 07:33:58 Z560 charon-nm: 07[ENC] generating IKE_AUTH request 5 [ AUTH ]
Jun 28 07:33:58 Z560 charon-nm: 07[NET] sending packet: from 
192.168.1.114[47031] to 108.31.28.59[4500] (92 bytes)
Jun 28 07:33:58 Z560 charon-nm: 06[NET] received packet: from 
108.31.28.59[4500] to 192.168.1.114[47031] (124 bytes)
Jun 28 07:33:58 Z560 charon-nm: 06[ENC] parsed IKE_AUTH response 5 [ AUTH 
N(MOBIKE_SUP) N(NO_ADD_ADDR) N(FAIL_CP_REQ) N(TS_UNACCEPT) ]
Jun 28 07:33:58 Z560 charon-nm: 06[IKE] authentication of 
'durgeeenterprises.publicvm.com' with EAP successful
Jun 28 07:33:58 Z560 charon-nm: 06[IKE] IKE_SA Durgee Enterprises, LLC[1] 
established between 
192.168.1.114[dhdurgee]...108.31.28.59[durgeeenterprises.publicvm.com]
Jun 28 07:33:58 Z560 charon-nm: 06[IKE] scheduling rekeying in 35606s
Jun 28 07:33:58 Z560 charon-nm: 06[IKE] maximum IKE_SA lifetime 36206s
Jun 28 07:33:58 Z560 charon-nm: 06[IKE] received FAILED_CP_REQUIRED notify, no 
CHILD_SA built
Jun 28 07:33:58 Z560 charon-nm: 06[IKE] failed to establish CHILD_SA, keeping 
IKE_SA
Jun 28 07:33:58 Z560 charon-nm: 06[IKE] peer supports MOBIKE
Jun 28 07:33:58 Z560 charon-nm: 08[IKE] deleting IKE_SA Durgee Enterprises, 
LLC[1] between 
192.168.1.114[dhdurgee]...108.31.28.59[durgeeenterprises.publicvm.com]
Jun 28 07:33:58 Z560 charon-nm: 08[IKE] sending DELETE for IKE_SA Durgee 
Enterprises, LLC[1]
Jun 28 07:33:58 Z560 charon-nm: 08[ENC] generating INFORMATIONAL request 6 [ D ]
Jun 28 07:33:58 Z560 charon-nm: 08[NET] sending packet: from 
192.168.1.114[47031] to 108.31.28.59[4500] (76 bytes)
Jun 28 07:33:58 Z560 charon-nm: 09[NET] received packet: from 
108.31.28.59[4500] to 192.168.1.114[47031] (76 bytes)
Jun 28 07:33:58 Z560 charon-nm: 09[ENC] parsed INFORMATIONAL response 6 [ ]
Jun 28 07:33:58 Z560 charon-nm: 09[IKE] IKE_SA deleted


Obviously I am still missing something or have a setting wrong. Any suggestions?

Dave


Charles Fadipe wrote:  Hi David,


Please confirm you have StrongSwann’seap-mschapv2 plugin installed.

If not try Installing,libcharon-extra-plugins on your client.


Kind Regards

/Charles Fadipe/

/Junior Penetration and Security Tester
/
/University Information Services
/

/University of Cambridge/

Re: [strongSwan] Version numbers

[Noel Kuntze]

That version number scheme is compromised of the strongSwan version (left part 
of the /)
and the version number of the *currently running kernel* (right part of the /).

The right part is of no relevance to the code run by strongSwan. It's a legacy 
thing.
You're strongly encouraged to switch to swanctl.

Kind regards
Noel

Am 23.06.21 um 16:26 schrieb David Pearce - C:

I've got two SS servers, one works, one sort of work right.

The working one runs "Linux strongSwan U5.8.4/K4.15.0-142-generic"

The sortof server is running "Linux strongSwan 
U5.8.4/K4.18.0-305.3.1.el8_4.x86_64"

What is the difference between the two versions? Is one 32-bit and one 64-bit?

*Dave Pearce*

Blue Origin OLS

dpear...@blueorigin.com 






OpenPGP_signature
Description: OpenPGP digital signature

Re: [strongSwan] FW: defining a connection profile using DNS name in the cert's alt subject name cert field

[Noel Kuntze]

at your currently loaded server side config, which is the following:
- local ID "C=US, O=ATT_FirstNet, OU=ATT_FN_SeGW, 
CN=zrdm55asegw52.epc.mnc670.mcc312.3gppnetwork.org"
- remote ID "zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org"

Explicitely compared as follows:

local ID %any contains "C=US, O=ATT_FirstNet, OU=ATT_FN_SeGW, 
CN=zrdm55asegw52.epc.mnc670.mcc312.3gppnetwork.org" (that's fine)
remote ID "C=US, O=ATT_FirstNet, OU=ATT_FN_SeGW, 
CN=zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org" DOES NOT MATCH 
zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org

Solutions:
a) Explicitely set the remote ID on the server side to "C=US, O=ATT_FirstNet, 
OU=ATT_FN_SeGW, CN=zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org" (that's the ID 
the client actually sends)
    * See if the identity check later on the client side works out once the 
identity the server sends for itself is known to the client. If it doesn't, 
mutate configs accordingly.
b) Set the local ID on the client to 
"zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org" (that should/will work because 
the ID is exactly contained as type FQDN in the SAN of the client cert)
    remote_addrs = 2001:1890:111b:1c03::2  # tunnel addr for C1/D1
    local {
    auth = pubkey
    certs = zakr3dsegw51.crt
    id = "zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org"
    }
    remote {
    auth = pubkey
    }
c) Remove the identity in the server config's remote auth section (will permit 
any certificate if sent id is part of the certificate, thus any correctly 
configured client with a trusted certificate)

I presume this is a POC where in the end a single CA or CAs under a common sub 
ca issue client certificates. In that case just get that cert and set it in 
remote.cacerts. strongSwan will ensure that certificates of clients that try to 
authenticate have to have the configured CA certificate in its trust path.
That's the preferred solution. That way you can use that single connection 
definition for all clients. The lookup for configs while config matching in the 
code is linear so keep your number of loaded connections at a reasonable 
number. Also, don't configure DNS names as local or remote addresses.
That will cause a DNS lookup for every config match (not good).

Let me know if this helps.

Kind regards
Noel


Addendum:
1) Standardized Identity types (from RFC5996)

   ID Type   Value
   ---
   ID_IPV4_ADDR1
  A single four (4) octet IPv4 address.

   ID_FQDN 2
  A fully-qualified domain name string.  An example of an ID_FQDN
  is "example.com".  The string MUST NOT contain any terminators
  (e.g., NULL, CR, etc.). All characters in the ID_FQDN are ASCII;
  for an "internationalized domain name", the syntax is as defined
  in [IDNA  <https://datatracker.ietf.org/doc/html/rfc5996#ref-IDNA>], for example 
"xn--tmonesimerkki-bfbb.example.net".

   ID_RFC822_ADDR  3
  A fully-qualifiedRFC 822  <https://datatracker.ietf.org/doc/html/rfc822>  
email address string.  An example of a
  ID_RFC822_ADDR is "jsm...@example.com".  The string MUST NOT
  contain any terminators.  Because of [EAI  
<https://datatracker.ietf.org/doc/html/rfc5996#ref-EAI>], implementations would
  be wise to treat this field as UTF-8 encoded text, not as
  pure ASCII.

   ID_IPV6_ADDR5
  A single sixteen (16) octet IPv6 address.

   ID_DER_ASN1_DN  9
  The binary Distinguished Encoding Rules (DER) encoding of an
  ASN.1 X.500 Distinguished Name [PKIX  
<https://datatracker.ietf.org/doc/html/rfc5996#ref-PKIX>].

   ID_DER_ASN1_GN  10
  The binary DER encoding of an ASN.1 X.509 GeneralName [PKIX  
<https://datatracker.ietf.org/doc/html/rfc5996#ref-PKIX>].

   ID_KEY_ID   11
  An opaque octet stream that may be used to pass vendor-
  specific information necessary to do certain proprietary
  types of identification.


2) known strongSwan identity types (from man swanctl.conf):
The following prefixes are known: ipv4, ipv6, rfc822, email, userfqdn, fqdn, 
dns, asn1dn,  asn1gn and keyid.  Custom type prefixes may be specified by 
surrounding the numerical type value by curly brackets.

Am 02.06.21 um 21:06 schrieb FINLEY, DAVID BRIAN:

Hello, I've resent this a couple of times over the last few weeks with no 
response. Appreciate that you may be too busy, just let me know if that's the 
case so that I know you received it and then I wont send any further follow ups.
Thx.

Dave Finley
df1...@att.com
(630) 719-4391  (desk)
(630) 740-5198  (mobile)

-Original Message-
From: FINLEY, DAVID BRIAN
Sent: Mo

Re: [strongSwan] Simple IPsec host-host test

[Noel Kuntze]

Hello Hoss,

Well, the first two just load settings from the config files, the latter starts 
the connection.
You specified start_action=trap in the child section, so the kernel tells the 
daemon when
to up the child (that is the case when there's no IPsec state for the matched 
trap policy).

I presume up to now you either did not have the config loaded, did not read the 
log to see if the daemon did anything,
or there simply was no traffic that needed to be processed.

Kind regards
Noel

Am 28.05.21 um 16:57 schrieb H Yavari:

Hi Noel,

Thanks for the reply.
I resolved the issue with running the swanctl -c and swanctl -q then swanctl -i 
--child host-host

it is the correct way?

Regards,
Hoss


On Friday, May 28, 2021, 07:48:13 AM PDT, Noel Kuntze 
 wrote:


Hello Hoss,

What do you expect to happen?
What exactly did you do up to this point?

Kind regards
Noel

Am 27.05.21 um 19:20 schrieb H Yavari:
> Hi to all,
>
> I did a simple configuration based on test samples for two ec2 on AWS, but 
nothing happens between the two machines. What I am missing?
>
> (10.0.0.30) Sun <===> Moon (10.0.0.20)
>
> connections {
>
>     host-host {
>        remote_addrs = 10.0.0.20
>
>        local {
>           auth = psk
>           id = sun.strongswan.org
>        }
>        remote {
>           auth = psk
>           id = moon.strongswan.org
>        }
>        children {
>           host-host {
>                  start_action = trap
>           }
>        }
>     }
> }
> secrets {
>     ike-1 {
>        id-moon = moon.strongswan.org
>        id-sun = sun.strongswan.org
>        secret = 0sv+NkxY9LLZvwj4q
>     }
> }
>
>
> 
>
>
>
> connections {
>
>     host-host {
>        remote_addrs = 10.0.0.30
>
>        local {
>           auth = psk
>           id = moon.strongswan.org
>        }
>        remote {
>           auth = psk
>           id = sun.strongswan.org
>        }
>        children {
>           host-host {
>                  start_action = start
>           }
>        }
>     }
> }
>
> secrets {
>     ike-1 {
>        id-1 = moon.strongswan.org
>        secret = 0x45a30759df97dc26a15b88ff
>     }
>     ike-2 {
>        id-2 = sun.strongswan.org
>        secret = "This is a strong password"
>     }
>     ike-3 {
>        id-3a = moon.strongswan.org
>        id-3b = sun.strongswan.org
>        secret = 0sv+NkxY9LLZvwj4q
>     }
>     ike-4 {
>        secret = 'My "home" is my "castle"!'
>     }
>     ike-5 {
>       id-5 = 10.0.0.20
>       secret = "Andi's home"
>     }
> }
>
>
> EC2 : Debian
> Version: 5.7.2
>
> Thanks.
>
> BR
> Hoss
>





OpenPGP_signature
Description: OpenPGP digital signature

Re: [strongSwan] Simple IPsec host-host test

[Noel Kuntze]

Hello Hoss,

What do you expect to happen?
What exactly did you do up to this point?

Kind regards
Noel

Am 27.05.21 um 19:20 schrieb H Yavari:

Hi to all,

I did a simple configuration based on test samples for two ec2 on AWS, but 
nothing happens between the two machines. What I am missing?

(10.0.0.30) Sun <===> Moon (10.0.0.20)

connections {

    host-host {
       remote_addrs = 10.0.0.20

       local {
          auth = psk
          id = sun.strongswan.org
       }
       remote {
          auth = psk
          id = moon.strongswan.org
       }
       children {
          host-host {
                 start_action = trap
          }
       }
    }
}
secrets {
    ike-1 {
       id-moon = moon.strongswan.org
       id-sun = sun.strongswan.org
       secret = 0sv+NkxY9LLZvwj4q
    }
}






connections {

    host-host {
       remote_addrs = 10.0.0.30

       local {
          auth = psk
          id = moon.strongswan.org
       }
       remote {
          auth = psk
          id = sun.strongswan.org
       }
       children {
          host-host {
                 start_action = start
          }
       }
    }
}

secrets {
    ike-1 {
       id-1 = moon.strongswan.org
       secret = 0x45a30759df97dc26a15b88ff
    }
    ike-2 {
       id-2 = sun.strongswan.org
       secret = "This is a strong password"
    }
    ike-3 {
       id-3a = moon.strongswan.org
       id-3b = sun.strongswan.org
       secret = 0sv+NkxY9LLZvwj4q
    }
    ike-4 {
       secret = 'My "home" is my "castle"!'
    }
    ike-5 {
      id-5 = 10.0.0.20
      secret = "Andi's home"
    }
}


EC2 : Debian
Version: 5.7.2

Thanks.

BR
Hoss





OpenPGP_signature
Description: OpenPGP digital signature

Re: [strongSwan] firewall configuration on Linux for IKE and dpd?

[Noel Kuntze]

Hello Harald,

You can obviously do it, but don't need it, unless you use stateful firewall 
rules or accounting using conntrack.

Kind regards
Noel

Am 27.05.21 um 14:49 schrieb Harald Dunkel:

Hi folks,

I wonder if it is reasonable to use connection tracking for
500/udp and 4500/udp in the iptables configuration, esp.
wrt dead peer detection?


Your thoughts on this?

Regards
Harri




OpenPGP_signature
Description: OpenPGP digital signature

Re: [strongSwan] Unable to find PSK for tunnel: no peer config found

[Noel Kuntze]

Hello Lorenzo,

That's one that is also puzzling me at times.
Maybe there's a newline at the end of the PSK in the fortigate and
that's not filtered and also not displayed in the UI.
Try entering the PSK there by hand. That way you can't unknowingly
copy newlines - or enter special characters.

Kind regards
Noel

Am 26.05.21 um 16:40 schrieb Lorenzo Milesi:

Thanks for the quick respose.
Gee, I feel ashamed, I'm usually the one spotting typos!! :(

Fixed that now I've apparently a PSK mismatch because I get

May 26 16:36:51 vpn01 charon: 03[NET] received packet: from 
217.133.18.100[4500] to 95.110.128.186[4500]
May 26 16:36:51 vpn01 charon: 10[MGR] checkout IKEv1 SA by message with SPIs 
4e33bc842b30dd31_i 909c49b7e60be2ac_r
May 26 16:36:51 vpn01 charon: 10[MGR] IKE_SA sts-base[5] successfully checked 
out
May 26 16:36:51 vpn01 charon: 10[NET] received packet: from 
217.133.18.100[4500] to 95.110.128.186[4500] (556 bytes)
May 26 16:36:51 vpn01 charon: 10[ENC] invalid HASH_V1 payload length, 
decryption failed?
May 26 16:36:51 vpn01 charon: 10[ENC] could not decrypt payloads

But I'm puzzled, as I'm directly copying from the secrets file to the Fortigate 
GUI!
My secrets is now:

2.3.8.1 : PSK"abcde"
Stelle : PSK abcde

(2.3.8.1 being the fortigate public ip)

- Original Message -

From: "Noel Kuntze" 
To: "Lorenzo Milesi" , "users" 

Sent: Wednesday, May 26, 2021 4:24:31 PM
Subject: Re: [strongSwan] Unable to find PSK for tunnel: no peer config found
Hi Lorenzo,

You are the victim of a typo.


 righid=Stelle

Should be rightid.

Kind regards
Noel

Am 26.05.21 um 16:18 schrieb Lorenzo Milesi:

Hi.
I'm (still) trying to configure a tunnel between a StrongSwan 5.6.2 (Ubuntu
18.04) host and a Fortigate device. I finally came up with a working
configuration, but now I'm unable to have srongswan authenticate, I get the
infamous
May 26 16:05:19 vpn01 charon: 13[IKE] no peer config found
I tried different formats of selectors but they all fail. I checked the config
several times but I cannot find what's wrong.

My ipsec.secrets:
95.1.8.6 %any : PSK   "abcde"
95.1.8.6 2.3.8.1 : PSK "abcde"
95.1.8.6 : PSK    "abcde"
Stelle : PSK    "abcde"


My ipsec.conf:
conn sts-base
      keyexchange=ikev1
      fragmentation=yes
      dpdaction=restart
      ike=aes256-sha256-modp3072
      esp=aes256-sha256
      keyingtries=%forever
      leftsubnet=172.32.1.0/24
      lifetime=86400
      leftauth=psk
      rightauth=psk
      righid=Stelle
      auto=start
      right=2.3.8.1

conn site-3-1
      also=sts-base
      leftsubnet=172.32.1.0/24
      rightsubnet=192.168.8.0/24

conn site-3-2
      also=sts-base
      leftsubnet=172.32.1.0/24
      rightsubnet=192.168.9.0/24


Log:
May 26 16:05:19 vpn01 ipsec[1367]: 15[IKE] remote host is behind NAT
May 26 16:05:19 vpn01 ipsec[1367]: 15[CFG] peer config match local: 1 (ID_ANY)
May 26 16:05:19 vpn01 ipsec[1367]: 15[CFG] peer config match remote: 1 (ID_ANY)
May 26 16:05:19 vpn01 ipsec[1367]: 15[CFG] ike config match: 2076 (95.1.8.6
2.3.8.1 IKEv1)
May 26 16:05:19 vpn01 ipsec[1367]: 15[CFG]   candidate "sts-base", match:
1/1/2076 (me/other/ike)
May 26 16:05:19 vpn01 ipsec[1367]: 15[IKE] natd_chunk => 22 bytes @
0x7ff92cef4ac0
May 26 16:05:19 vpn01 ipsec[1367]: 15[IKE]    0: D6 50 6B F7 85 FD B6 F3 B1 F8
20 48 71 AD 06 01  .Pk... Hq...
May 26 16:05:19 vpn01 ipsec[1367]: 15[IKE]   16: D9 85 12 64 01 F4
     ...d..
May 26 16:05:19 vpn01 ipsec[1367]: 15[IKE] natd_hash => 32 bytes @
0x7ff91000c150
May 26 16:05:19 vpn01 ipsec[1367]: 15[IKE]    0: D1 DB AE ED 2E B2 94 77 32 7E
51 CE 9B 0A 49 D5  ...w2~Q...I.
May 26 16:05:19 vpn01 ipsec[1367]: 15[IKE]   16: 11 8F CC 18 33 70 47 FE D0 04
3B 8E EA DF 9E 3D  3pG...;=
May 26 16:05:19 vpn01 ipsec[1367]: 15[IKE] natd_chunk => 22 bytes @
0x7ff92cef4ac0
May 26 16:05:19 vpn01 ipsec[1367]: 15[IKE]    0: D6 50 6B F7 85 FD B6 F3 B1 F8
20 48 71 AD 06 01  .Pk... Hq...
May 26 16:05:19 vpn01 ipsec[1367]: 15[IKE]   16: 5F 6E 80 BA 01 F4
     _n
May 26 16:05:19 vpn01 ipsec[1367]: 15[IKE] natd_hash => 32 bytes @
0x7ff91000c150
May 26 16:05:19 vpn01 ipsec[1367]: 15[IKE]    0: 27 C0 28 F3 4D E2 DD 93 03 04
E6 98 8A 20 02 3B  '.(.M .;
May 26 16:05:19 vpn01 ipsec[1367]: 15[IKE]   16: BA AC FF 7F C6 23 EC 1E 9F 77
1A 9E D7 DD EB 11  .#...w..
May 26 16:05:19 vpn01 ipsec[1367]: 15[ENC] generating ID_PROT response 0 [ KE No
NAT-D NAT-D ]
May 26 16:05:19 vpn01 ipsec[1367]: 15[NET] sending packet: from 95.1.8.6[500] to
2.3.8.1[500] (524 bytes)
May 26 16:05:19 vpn01 ipsec[1367]: 04[NET] sending packet: from 95.1.8.6[500] to
2.3.8.1[500]
May 26 16:05:19 vpn01 ipsec[1367]: 15[MGR] checkin IKE_SA (unnamed)[102]
May 26 16:05:19 vpn01 ipsec[1367]: 15[MGR] checkin of IKE_SA successful
May 26 16:05:19 vpn01 ipsec[1367]: 03[NET] received packet => 112

Re: [strongSwan] Unable to find PSK for tunnel: no peer config found

[Noel Kuntze]

Hi Lorenzo,

You are the victim of a typo.


righid=Stelle


Should be rightid.

Kind regards
Noel

Am 26.05.21 um 16:18 schrieb Lorenzo Milesi:

Hi.
I'm (still) trying to configure a tunnel between a StrongSwan 5.6.2 (Ubuntu 
18.04) host and a Fortigate device. I finally came up with a working 
configuration, but now I'm unable to have srongswan authenticate, I get the 
infamous
May 26 16:05:19 vpn01 charon: 13[IKE] no peer config found
I tried different formats of selectors but they all fail. I checked the config 
several times but I cannot find what's wrong.

My ipsec.secrets:
95.1.8.6 %any : PSK   "abcde"
95.1.8.6 2.3.8.1 : PSK "abcde"
95.1.8.6 : PSK    "abcde"
Stelle : PSK    "abcde"


My ipsec.conf:
conn sts-base
     keyexchange=ikev1
     fragmentation=yes
     dpdaction=restart
     ike=aes256-sha256-modp3072
     esp=aes256-sha256
     keyingtries=%forever
     leftsubnet=172.32.1.0/24
     lifetime=86400
     leftauth=psk
     rightauth=psk
     righid=Stelle
     auto=start
     right=2.3.8.1

conn site-3-1
     also=sts-base
     leftsubnet=172.32.1.0/24
     rightsubnet=192.168.8.0/24

conn site-3-2
     also=sts-base
     leftsubnet=172.32.1.0/24
     rightsubnet=192.168.9.0/24


Log:
May 26 16:05:19 vpn01 ipsec[1367]: 15[IKE] remote host is behind NAT
May 26 16:05:19 vpn01 ipsec[1367]: 15[CFG] peer config match local: 1 (ID_ANY)
May 26 16:05:19 vpn01 ipsec[1367]: 15[CFG] peer config match remote: 1 (ID_ANY)
May 26 16:05:19 vpn01 ipsec[1367]: 15[CFG] ike config match: 2076 (95.1.8.6 
2.3.8.1 IKEv1)
May 26 16:05:19 vpn01 ipsec[1367]: 15[CFG]   candidate "sts-base", match: 
1/1/2076 (me/other/ike)
May 26 16:05:19 vpn01 ipsec[1367]: 15[IKE] natd_chunk => 22 bytes @ 
0x7ff92cef4ac0
May 26 16:05:19 vpn01 ipsec[1367]: 15[IKE]    0: D6 50 6B F7 85 FD B6 F3 B1 F8 
20 48 71 AD 06 01  .Pk... Hq...
May 26 16:05:19 vpn01 ipsec[1367]: 15[IKE]   16: D9 85 12 64 01 F4  
  ...d..
May 26 16:05:19 vpn01 ipsec[1367]: 15[IKE] natd_hash => 32 bytes @ 
0x7ff91000c150
May 26 16:05:19 vpn01 ipsec[1367]: 15[IKE]    0: D1 DB AE ED 2E B2 94 77 32 7E 
51 CE 9B 0A 49 D5  ...w2~Q...I.
May 26 16:05:19 vpn01 ipsec[1367]: 15[IKE]   16: 11 8F CC 18 33 70 47 FE D0 04 
3B 8E EA DF 9E 3D  3pG...;=
May 26 16:05:19 vpn01 ipsec[1367]: 15[IKE] natd_chunk => 22 bytes @ 
0x7ff92cef4ac0
May 26 16:05:19 vpn01 ipsec[1367]: 15[IKE]    0: D6 50 6B F7 85 FD B6 F3 B1 F8 
20 48 71 AD 06 01  .Pk... Hq...
May 26 16:05:19 vpn01 ipsec[1367]: 15[IKE]   16: 5F 6E 80 BA 01 F4  
  _n
May 26 16:05:19 vpn01 ipsec[1367]: 15[IKE] natd_hash => 32 bytes @ 
0x7ff91000c150
May 26 16:05:19 vpn01 ipsec[1367]: 15[IKE]    0: 27 C0 28 F3 4D E2 DD 93 03 04 
E6 98 8A 20 02 3B  '.(.M .;
May 26 16:05:19 vpn01 ipsec[1367]: 15[IKE]   16: BA AC FF 7F C6 23 EC 1E 9F 77 
1A 9E D7 DD EB 11  .#...w..
May 26 16:05:19 vpn01 ipsec[1367]: 15[ENC] generating ID_PROT response 0 [ KE 
No NAT-D NAT-D ]
May 26 16:05:19 vpn01 ipsec[1367]: 15[NET] sending packet: from 95.1.8.6[500] 
to 2.3.8.1[500] (524 bytes)
May 26 16:05:19 vpn01 ipsec[1367]: 04[NET] sending packet: from 95.1.8.6[500] 
to 2.3.8.1[500]
May 26 16:05:19 vpn01 ipsec[1367]: 15[MGR] checkin IKE_SA (unnamed)[102]
May 26 16:05:19 vpn01 ipsec[1367]: 15[MGR] checkin of IKE_SA successful
May 26 16:05:19 vpn01 ipsec[1367]: 03[NET] received packet => 112 bytes @ 
0x7ff9326fd440
May 26 16:05:19 vpn01 ipsec[1367]: 03[NET]    0: 00 00 00 00 D6 50 6B F7 85 FD 
B6 F3 B1 F8 20 48  .Pk... H
May 26 16:05:19 vpn01 ipsec[1367]: 03[NET]   16: 71 AD 06 01 05 10 02 01 00 00 
00 00 00 00 00 6C  q..l
May 26 16:05:19 vpn01 charon: 03[NET]    0: 00 00 00 00 D6 50 6B F7 85 FD B6 F3 
B1 F8 20 48  .Pk... H
May 26 16:05:19 vpn01 ipsec[1367]: 03[NET]   32: DF 47 5C 43 7A CD 60 FF DB 15 
51 27 EA 7B 39 1A  .G\Cz.`...Q'.{9.
May 26 16:05:19 vpn01 charon: 03[NET]   16: 71 AD 06 01 05 10 02 01 00 00 00 00 
00 00 00 6C  q..l
May 26 16:05:19 vpn01 charon: 03[NET]   32: DF 47 5C 43 7A CD 60 FF DB 15 51 27 
EA 7B 39 1A  .G\Cz.`...Q'.{9.
May 26 16:05:19 vpn01 charon: 03[NET]   48: D2 4E D8 56 36 6B 3C B6 4D 48 4A 65 B1 
8B 90 B9  .N.V6k<.MHJe
May 26 16:05:19 vpn01 charon: 03[NET]   64: E9 67 7F E3 0F 5B 38 43 41 6B DA 67 
FD 2C 69 4F  .g...[8CAk.g.,iO
May 26 16:05:19 vpn01 charon: 03[NET]   80: 0D 36 D5 65 67 E5 CE D7 6C D4 44 D3 
94 EF 55 CC  .6.eg...l.D...U.
May 26 16:05:19 vpn01 charon: 03[NET]   96: 4F 84 82 E2 05 A0 DD E9 9F FB F2 B5 
DE 54 E1 77  OT.w
May 26 16:05:19 vpn01 charon: 03[NET] received packet: from 2.3.8.1[4500] to 
95.1.8.6[4500]
May 26 16:05:19 vpn01 charon: 03[NET] waiting for data on sockets
May 26 16:05:19 vpn01 charon: 13[MGR] checkout IKEv1 SA by message with SPIs 
d6506bf785fdb6f3_i b1f8204871ad0601_r
May 26 16:05:19 vpn01 charon: 13[MGR] IKE_SA (unnamed)[102] successfully 
checked out
May 26 16:05:19 vpn01 charon: 13[NET] received packet: from 2.3.8.1[4500] to 

Re: [strongSwan] NO_PROPOSAL_CHOSEN when using 5.6.2 on Ubuntu 18.04

[Noel Kuntze]

Yes. Make sure you only either run the daemon using "ipsec restart"/"ipsec 
start", or using the init daemon of your system.

Am 14.05.21 um 22:20 schrieb Karuna Sagar Krishna:

I think I figured out the issue. There were 2 instances of starter process 
running. Would this have caused `sudo ipsec update` to not really take effect?

root      3625     1  0 May12 ?        00:00:00 /usr/lib/ipsec/starter --daemon 
charon --nofork
root      4246  3625  0 May12 ?        00:00:02 /usr/lib/ipsec/charon
root      5313     1  0 May12 ?        00:00:00 /usr/lib/ipsec/starter --daemon 
charon

--karuna


On Wed, May 12, 2021 at 12:24 PM Karuna Sagar Krishna mailto:karunasag...@gmail.com>> wrote:

I see that `sudo ipsec status` return exit code 3. Couldn't find the 
significance of this exit code in the documentation. Can you help understand 
what exit code 3 implies?

--karuna


On Wed, May 12, 2021 at 10:15 AM Noel Kuntze 
 wrote:

the strace isn't useful because starter is doing the reading and loading of the 
config. "ipsec" only tells starter to do that.
Please run dos2unix on the config files on the server and check if that 
helps.

Am 12.05.21 um 18:49 schrieb Karuna Sagar Krishna:
> Ah yes, that is probably because I copied the contents of ipsec.conf 
from my terminal window to notepad. I verified that on the Ubuntu nodes it uses 
Unix line endings and in production scenario this file is generated by scripts on 
the Ubuntu node itself.
>
> --karuna
>
>
> On Wed, May 12, 2021 at 6:58 AM Tobias Brunner mailto:tob...@strongswan.org> <mailto:tob...@strongswan.org 
<mailto:tob...@strongswan.org>>> wrote:
>
>     Hi Karuna,
>
>     > @Tobias Brunner <mailto:tob...@strongswan.org <mailto:tob...@strongswan.org> 
<mailto:tob...@strongswan.org <mailto:tob...@strongswan.org>>> do you have any inputs on
>     > this issue?
>
>     Make sure your config file uses Unix line endings (\n) and not 
Windows
>     (\r\n), which the file you sent does.
>
>     Regards,
>     Tobias
>







OpenPGP_signature
Description: OpenPGP digital signature

Re: [strongSwan] NO_PROPOSAL_CHOSEN when using 5.6.2 on Ubuntu 18.04

[Noel Kuntze]

the strace isn't useful because starter is doing the reading and loading of the config. 
"ipsec" only tells starter to do that.
Please run dos2unix on the config files on the server and check if that helps.

Am 12.05.21 um 18:49 schrieb Karuna Sagar Krishna:

Ah yes, that is probably because I copied the contents of ipsec.conf from my 
terminal window to notepad. I verified that on the Ubuntu nodes it uses Unix 
line endings and in production scenario this file is generated by scripts on 
the Ubuntu node itself.

--karuna


On Wed, May 12, 2021 at 6:58 AM Tobias Brunner mailto:tob...@strongswan.org>> wrote:

Hi Karuna,

> @Tobias Brunner > do you have any inputs on
> this issue?

Make sure your config file uses Unix line endings (\n) and not Windows
(\r\n), which the file you sent does.

Regards,
Tobias






OpenPGP_signature
Description: OpenPGP digital signature

Re: [strongSwan] NO_PROPOSAL_CHOSEN when using 5.6.2 on Ubuntu 18.04

[Noel Kuntze]

I'm sorry, I'm at mit wit's end. Try restarting the daemon. Maybe that helps.

Am 12.05.21 um 02:33 schrieb Karuna Sagar Krishna:

Not sure if I fully understand. Did you mean to say - remove `auto=route` from 
default connection and add `auto=add` to each connection section? If yes, I 
made this change manually to ipsec.conf, ran `sudo ipsec update` but the status 
has not changed and I'm not able to ping the nodes.

--karuna


On Tue, May 11, 2021 at 5:13 PM Noel Kuntze  
wrote:

Oh. Right. You need to add auto=add to the configs. In your case, it's 
probably good if you'd change your script to add that to the conns inserted.

Am 12.05.21 um 01:55 schrieb Karuna Sagar Krishna:
> Shortened the connection names and changed the order (attached). Tried 
various orders and shorter names. Each time ran `sudo ipsec update` followed by 
`sudo ipsec statusall`. The status did not change each time; the status still 
shows the old name for established connection. And there is nothing specific to 
this experiment in the logs.
>
> --karuna
>






OpenPGP_signature
Description: OpenPGP digital signature

Re: [strongSwan] NO_PROPOSAL_CHOSEN when using 5.6.2 on Ubuntu 18.04

[Noel Kuntze]

Okay, now we at least know the config line is at actually read.

What happens when you change the order of the config lines or assign them 
shorter names?

Am 12.05.21 um 01:41 schrieb Karuna Sagar Krishna:

Yes, I tried that i.e. added some garbage line to ipsec.conf and issued `sudo 
ipsec update`. And I see the errors in the logs as expected. Later I reverted 
the garbage lines and issued `sudo ipsec update` but the issue remains i.e. no 
errors in the logs but the statusall hasn't changed.

May 11 23:20:03 hn1-kkafka ipsec[4941]: # unknown keyword 'something'
May 11 23:20:03 hn1-kkafka ipsec[4941]: ### 1 parsing error (0 fatal) ###
May 11 23:23:26 hn1-kkafka ipsec[4941]: # unknown keyword 'garbage'
May 11 23:23:26 hn1-kkafka ipsec[4941]: message repeated 8 times: [ # unknown 
keyword 'garbage']
May 11 23:23:26 hn1-kkafka ipsec[4941]: # unknown keyword 'garbage'

--karuna

On Tue, May 11, 2021 at 4:17 PM Noel Kuntze  
wrote:

Hi, please verify that the config file is actually used. For example add a 
deliberate syntax error. Like just garbage on a line. Check if the daemon 
and/or ipsec complains about that.

Am 12.05.21 um 01:15 schrieb Karuna Sagar Krishna:
> Thanks for the quick replies!
>
> Running `sudo ipsec update` or `sudo ipsec reload` is effectively a 
no-op. Captured the terminal output below:
>
>
>
> karkrish@hn1-kkafka:~$ sudo ipsec statusall
> Status of IKE charon daemon (strongSwan 5.6.2, Linux 5.4.0-1046-azure, 
x86_64):
>   uptime: 2 hours, since May 11 20:42:06 2021
>   malloc: sbrk 2703360, mmap 0, used 847536, free 1855824
>   worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, 
scheduled: 2
>   loaded plugins: charon aesni aes rc2 sha2 sha1 md4 md5 mgf1 random 
nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey 
sshkey pem openssl fips-prf gmp agent xcbc hmac gcm attr kernel-netlink resolve 
socket-default connmark stroke updown eap-mschapv2 xauth-generic counters
> Listening IP addresses:
>   10.0.0.14
> Connections:
> hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net> 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net>>:  
10.0.0.14...10.0.0.15  IKEv2
> hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net> 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net>>:   local:  
[CN=IP-37fa1445fc.hdinsight-stable.azure-test.net <http://IP-37fa1445fc.hdinsight-stable.azure-test.net> 
<http://IP-37fa1445fc.hdinsight-stable.azure-test.net 
<http://IP-37fa1445fc.hdinsight-stable.azure-test.net>>] uses public key authentication
> hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net> 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net>>:    cert:  
"CN=IP-37fa1445fc.hdinsight-stable.azure-test.net <http://IP-37fa1445fc.hdinsight-stable.azure-test.net> 
<http://IP-37fa1445fc.hdinsight-stable.azure-test.net <http://IP-37fa1445fc.hdinsight-stable.azure-test.net>>"
> hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net> 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net>>:   remote: 
[CN=IP-37fa1445fc.hdinsight-stable.azure-test.net <http://IP-37fa1445fc.hdinsight-stable.azure-test.net> 
<http://IP-37fa1445fc.hdinsight-stable.azure-test.net 
<http://IP-37fa1445fc.hdinsight-stable.azure-test.net>>] uses public key authentication
> hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net> 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net>>:    cert:  
"CN=IP-37fa1445fc.hdinsight-stable.azure-test.net <http://IP-37fa1445fc.hdinsight-stable.azure-test.net> 
<http://IP-37fa1445fc.hdinsight-stable.azure-test.net <http://IP-37fa1445fc.hdinsight-stable.azure-test.net>>"
> hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net> 
<http://hn0-kk

Re: [strongSwan] NO_PROPOSAL_CHOSEN when using 5.6.2 on Ubuntu 18.04

[Noel Kuntze]

lz4hfuq0bvkf.dx.internal.cloudapp.net 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net>:   
child:  dynamic === dynamic TRANSPORT
hn1-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
<http://hn1-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net>:  
10.0.0.14...10.0.0.14  IKEv2
hn1-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
<http://hn1-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net>:   local:  
[CN=IP-37fa1445fc.hdinsight-stable.azure-test.net 
<http://IP-37fa1445fc.hdinsight-stable.azure-test.net>] uses public key authentication
hn1-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
<http://hn1-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net>:    cert:  
"CN=IP-37fa1445fc.hdinsight-stable.azure-test.net 
<http://IP-37fa1445fc.hdinsight-stable.azure-test.net>"
hn1-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
<http://hn1-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net>:   remote: 
[CN=IP-37fa1445fc.hdinsight-stable.azure-test.net 
<http://IP-37fa1445fc.hdinsight-stable.azure-test.net>] uses public key authentication
hn1-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
<http://hn1-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net>:    cert:  
"CN=IP-37fa1445fc.hdinsight-stable.azure-test.net 
<http://IP-37fa1445fc.hdinsight-stable.azure-test.net>"
hn1-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
<http://hn1-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net>:   
child:  dynamic === dynamic TRANSPORT
Routed Connections:
hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net>{5}:  
ROUTED, TRANSPORT, reqid 1
hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net>{5}: 10.0.0.14/32 
<http://10.0.0.14/32> === 10.0.0.15/32 <http://10.0.0.15/32>
hn1-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
<http://hn1-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net>{2}:  
ROUTED, TRANSPORT, reqid 2
hn1-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
<http://hn1-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net>{2}: 10.0.0.14/32 
<http://10.0.0.14/32> === 10.0.0.14/32 <http://10.0.0.14/32>
Security Associations (1 up, 0 connecting):
hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net>[11]: ESTABLISHED 2 
hours ago, 10.0.0.14[CN=IP-37fa1445fc.hdinsight-stable.azure-test.net 
<http://IP-37fa1445fc.hdinsight-stable.azure-test.net>]...10.0.0.15[CN=IP-37fa1445fc.hdinsight-stable.azure-test.net
 <http://IP-37fa1445fc.hdinsight-stable.azure-test.net>]
hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net>[11]: 
IKEv2 SPIs: 1536ce9853bef399_i c00b62dfefa5f4ce_r*, public key reauthentication in 5 
hours
hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net>[11]: 
IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net>{3}:  
INSTALLED, TRANSPORT, reqid 1, ESP SPIs: c73ba254_i c0ffd04a_o
hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net>{3}:  
AES_CBC_256/HMAC_SHA2_256_128, 234876 bytes_i (4189 pkts, 0s ago), 910520 bytes_o 
(3037 pkts, 1474s ago), rekeying in 5 hours
hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net>{3}: 10.0.0.14/32 
<http://10.0.0.14/32> === 10.0.0.15/32 <http://10.0.0.15/32>

On Tue, May 11, 2021 at 4:11 PM Noel Kuntze  
wrote:

Alright, found it.

Please verify that it's the actual ipsec.conf that is loaded because there 
also aren't any errors regarding config files logged.
What happens when you run "ipsec update" or "ipsec reload" from the 
terminal?

Kind regards
Noel

Am 12.05.21 um 01:09 schrieb Noel Kuntze:
> Okay, what's your complete ipsec.conf? Can you send it?
>
> Kind regards
> Noel
>
> Am 12.05.21 um 00:54 schrieb Karuna Sagar Krishna:
>> Attaching full charon logs.
>>
>> Can you help with the ipsec.conf interface. I'll plan to switch to 
swanctl going forward, but currently this is blocking our releases.
>>
>> --karuna
>>
>>
>> On Tue, May 11, 2021 at 2:54 PM Noel Kuntze 

Re: [strongSwan] NO_PROPOSAL_CHOSEN when using 5.6.2 on Ubuntu 18.04

[Noel Kuntze]

Alright, found it.

Please verify that it's the actual ipsec.conf that is loaded because there also 
aren't any errors regarding config files logged.
What happens when you run "ipsec update" or "ipsec reload" from the terminal?

Kind regards
Noel

Am 12.05.21 um 01:09 schrieb Noel Kuntze:

Okay, what's your complete ipsec.conf? Can you send it?

Kind regards
Noel

Am 12.05.21 um 00:54 schrieb Karuna Sagar Krishna:

Attaching full charon logs.

Can you help with the ipsec.conf interface. I'll plan to switch to swanctl 
going forward, but currently this is blocking our releases.

--karuna


On Tue, May 11, 2021 at 2:54 PM Noel Kuntze 
 wrote:

    Hi,

    Full logs please, as shown on the HelpRequests[1] page on the wiki.
    Also, it's strongly recommended to use swanctl instead if possible. That's 
the better configuration backend.

    Kind regards
    Noel

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

    Am 11.05.21 um 23:50 schrieb Karuna Sagar Krishna:
    > Hi,
    >
    > I'm setting up a IPSec connection between a bunch of Ubuntu 18.04 LTS nodes. I'm using 
Strongswan (Linux strongSwan U5.6.2/K5.4.0-1046-azure) on the Ubuntu nodes. The number of nodes 
is dynamic i.e. there are frequent scale out/ins. So the ipsec.conf file (see attached) is 
updated with additional conn sections and `sudo ipsec update` is used to reload the config 
file. However, I've noticed intermittent network connectivity issues and the syslog shows -> 
"no IKE config found for 10.0.0.14...10.0.0.18, sending NO_PROPOSAL_CHOSEN". Clearly, 
the ipsec status shows that the daemon has not reloaded the config irrespective of issuing 
`sudo ipsec update` multiple times.
    >
    > Can you help understand why the config is not updated and how to fix this 
issue?
    >
    >
    >
    > IPSec status:
    > -
    >
    >  > sudo ipsec statusall
    >
    > Status of IKE charon daemon (strongSwan 5.6.2, Linux 5.4.0-1046-azure, 
x86_64):
    >    uptime: 45 minutes, since May 11 20:42:07 2021
    >    malloc: sbrk 2703360, mmap 0, used 778800, free 1924560
    >    worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, 
scheduled: 2
    >    loaded plugins: charon aesni aes rc2 sha2 sha1 md4 md5 mgf1 random 
nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey 
sshkey pem openssl fips-prf gmp agent xcbc hmac gcm attr kernel-netlink resolve 
socket-default connmark stroke updown eap-mschapv2 xauth-generic counters
    > Listening IP addresses:
    >    10.0.0.14
    > Connections:
    > hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net> 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net>>:  
10.0.0.14...10.0.0.15  IKEv2
    > hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net> 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net>>:   local:  
[CN=IP-37fa1445fc.hdinsight-stable.azure-test.net <http://IP-37fa1445fc.hdinsight-stable.azure-test.net> 
<http://IP-37fa1445fc.hdinsight-stable.azure-test.net 
<http://IP-37fa1445fc.hdinsight-stable.azure-test.net>>] uses public key authentication
    > hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net> 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net>>:    cert:  
"CN=IP-37fa1445fc.hdinsight-stable.azure-test.net <http://IP-37fa1445fc.hdinsight-stable.azure-test.net> 
<http://IP-37fa1445fc.hdinsight-stable.azure-test.net <http://IP-37fa1445fc.hdinsight-stable.azure-test.net>>"
    > hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net> 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net>>:   remote: 
[CN=IP-37fa1445fc.hdinsight-stable.azure-test.net <http://IP-37fa1445fc.hdinsight-stable.azure-test.net> 
<http://IP-37fa1445fc.hdinsight-stable.azure-test.net 
<http://IP-37fa1445fc.hdinsight-stable.azure-test.net>>] uses public key authentication
    > hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net> 
<ht

Re: [strongSwan] NO_PROPOSAL_CHOSEN when using 5.6.2 on Ubuntu 18.04

[Noel Kuntze]

Okay, what's your complete ipsec.conf? Can you send it?

Kind regards
Noel

Am 12.05.21 um 00:54 schrieb Karuna Sagar Krishna:

Attaching full charon logs.

Can you help with the ipsec.conf interface. I'll plan to switch to swanctl 
going forward, but currently this is blocking our releases.

--karuna


On Tue, May 11, 2021 at 2:54 PM Noel Kuntze 
 wrote:

Hi,

Full logs please, as shown on the HelpRequests[1] page on the wiki.
Also, it's strongly recommended to use swanctl instead if possible. That's 
the better configuration backend.

Kind regards
Noel

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

Am 11.05.21 um 23:50 schrieb Karuna Sagar Krishna:
> Hi,
>
> I'm setting up a IPSec connection between a bunch of Ubuntu 18.04 LTS nodes. I'm using 
Strongswan (Linux strongSwan U5.6.2/K5.4.0-1046-azure) on the Ubuntu nodes. The number of nodes 
is dynamic i.e. there are frequent scale out/ins. So the ipsec.conf file (see attached) is 
updated with additional conn sections and `sudo ipsec update` is used to reload the config 
file. However, I've noticed intermittent network connectivity issues and the syslog shows -> 
"no IKE config found for 10.0.0.14...10.0.0.18, sending NO_PROPOSAL_CHOSEN". Clearly, 
the ipsec status shows that the daemon has not reloaded the config irrespective of issuing 
`sudo ipsec update` multiple times.
>
> Can you help understand why the config is not updated and how to fix this 
issue?
>
>
>
> IPSec status:
> -
>
>  > sudo ipsec statusall
>
> Status of IKE charon daemon (strongSwan 5.6.2, Linux 5.4.0-1046-azure, 
x86_64):
>    uptime: 45 minutes, since May 11 20:42:07 2021
>    malloc: sbrk 2703360, mmap 0, used 778800, free 1924560
>    worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, 
scheduled: 2
>    loaded plugins: charon aesni aes rc2 sha2 sha1 md4 md5 mgf1 random 
nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey 
sshkey pem openssl fips-prf gmp agent xcbc hmac gcm attr kernel-netlink resolve 
socket-default connmark stroke updown eap-mschapv2 xauth-generic counters
> Listening IP addresses:
>    10.0.0.14
> Connections:
> hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net> 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net>>:  
10.0.0.14...10.0.0.15  IKEv2
> hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net> 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net>>:   local:  
[CN=IP-37fa1445fc.hdinsight-stable.azure-test.net <http://IP-37fa1445fc.hdinsight-stable.azure-test.net> 
<http://IP-37fa1445fc.hdinsight-stable.azure-test.net 
<http://IP-37fa1445fc.hdinsight-stable.azure-test.net>>] uses public key authentication
> hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net> 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net>>:    cert:  
"CN=IP-37fa1445fc.hdinsight-stable.azure-test.net <http://IP-37fa1445fc.hdinsight-stable.azure-test.net> 
<http://IP-37fa1445fc.hdinsight-stable.azure-test.net <http://IP-37fa1445fc.hdinsight-stable.azure-test.net>>"
> hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net> 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net>>:   remote: 
[CN=IP-37fa1445fc.hdinsight-stable.azure-test.net <http://IP-37fa1445fc.hdinsight-stable.azure-test.net> 
<http://IP-37fa1445fc.hdinsight-stable.azure-test.net 
<http://IP-37fa1445fc.hdinsight-stable.azure-test.net>>] uses public key authentication
> hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net> 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
<http://hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net>>:    cert:  
"CN=IP-37fa1445fc.hdinsight-stable.azure-test.net <http://IP-37fa1445fc.hdinsight-stable.azure-test.net> 

Re: [strongSwan] NO_PROPOSAL_CHOSEN when using 5.6.2 on Ubuntu 18.04

[Noel Kuntze]

Hi,

Full logs please, as shown on the HelpRequests[1] page on the wiki.
Also, it's strongly recommended to use swanctl instead if possible. That's the 
better configuration backend.

Kind regards
Noel

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

Am 11.05.21 um 23:50 schrieb Karuna Sagar Krishna:

Hi,

I'm setting up a IPSec connection between a bunch of Ubuntu 18.04 LTS nodes. I'm using 
Strongswan (Linux strongSwan U5.6.2/K5.4.0-1046-azure) on the Ubuntu nodes. The number of 
nodes is dynamic i.e. there are frequent scale out/ins. So the ipsec.conf file (see 
attached) is updated with additional conn sections and `sudo ipsec update` is used to reload 
the config file. However, I've noticed intermittent network connectivity issues and the 
syslog shows -> "no IKE config found for 10.0.0.14...10.0.0.18, sending 
NO_PROPOSAL_CHOSEN". Clearly, the ipsec status shows that the daemon has not reloaded 
the config irrespective of issuing `sudo ipsec update` multiple times.

Can you help understand why the config is not updated and how to fix this issue?



IPSec status:
-

 > sudo ipsec statusall

Status of IKE charon daemon (strongSwan 5.6.2, Linux 5.4.0-1046-azure, x86_64):
   uptime: 45 minutes, since May 11 20:42:07 2021
   malloc: sbrk 2703360, mmap 0, used 778800, free 1924560
   worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, 
scheduled: 2
   loaded plugins: charon aesni aes rc2 sha2 sha1 md4 md5 mgf1 random nonce 
x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey 
pem openssl fips-prf gmp agent xcbc hmac gcm attr kernel-netlink resolve 
socket-default connmark stroke updown eap-mschapv2 xauth-generic counters
Listening IP addresses:
   10.0.0.14
Connections:
hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
:  
10.0.0.14...10.0.0.15  IKEv2
hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
:   local:  
[CN=IP-37fa1445fc.hdinsight-stable.azure-test.net 
] uses public key authentication
hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
:    cert:  
"CN=IP-37fa1445fc.hdinsight-stable.azure-test.net 
"
hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
:   remote: 
[CN=IP-37fa1445fc.hdinsight-stable.azure-test.net 
] uses public key authentication
hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
:    cert:  
"CN=IP-37fa1445fc.hdinsight-stable.azure-test.net 
"
hn0-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
:   
child:  dynamic === dynamic TRANSPORT
hn1-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
:  
10.0.0.14...10.0.0.14  IKEv2
hn1-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
:   local:  
[CN=IP-37fa1445fc.hdinsight-stable.azure-test.net 
] uses public key authentication
hn1-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
:    cert:  
"CN=IP-37fa1445fc.hdinsight-stable.azure-test.net 
"
hn1-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
:   remote: 
[CN=IP-37fa1445fc.hdinsight-stable.azure-test.net 
] uses public key authentication
hn1-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
:    cert:  
"CN=IP-37fa1445fc.hdinsight-stable.azure-test.net 
"
hn1-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
:   
child:  dynamic === dynamic TRANSPORT
/*Routed Connections:
hn1-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
{2}:  
ROUTED, TRANSPORT, reqid 2
hn1-kkafka.p0gi1uxxaaeebnlz4hfuq0bvkf.dx.internal.cloudapp.net 
{2}: 10.0.0.14/32 

Re: [strongSwan] connecting Linux Centos Box to Amazon VPC

[Noel Kuntze]

Hi,

Provide output of iptables-save please.

Kind regards
Noel

Am 01.05.21 um 12:43 schrieb Edvinas Kairys:

Hello,

I've established BGP connection from my Centos Linux box to Amazon VPC - using this 
guide: 
https://www.edge-cloud.net/2019/07/18/aws-site-2-site-vpn-with-strongswan-frrouting/#strongswan-setup
 


The only strange thing is that on IPtables mangle table - I don't see any 
matches on MARK f-ction which should set a MARK on incomming traffic. But IPSEC 
is still working (at least for now) don't know is it something i need to take 
care of or no.:

|pkts bytes target prot opt in out source destination Chain INPUT (policy ACCEPT 207M packets, 207G bytes) pkts bytes target prot opt in out source destination ||*_0 0 MARK_*||__ esp -- * * xx.xx.204.63 xx.xx.xx.251 MARK set 0x64 __||*_0 0 MARK _*||esp -- * * xx.xx.121.249 xx.xx.xx.251 MARK set 0xc8 Chain FORWARD (policy ACCEPT 100M packets, 131G bytes) pkts bytes target prot opt in out source destination 78389 4702K TCPMSS tcp -- * 
VTI_awssg1 0.0.0.0/0  0.0.0.0/0  tcp flags:0x06/0x02 TCPMSS clamp to PMTU 807 48404 TCPMSS tcp -- * VTI_awssg2 
0.0.0.0/0  0.0.0.0/0  tcp flags:0x06/0x02 TCPMSS clamp to PMTU Chain OUTPUT (policy ACCEPT 90M packets, 73G bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 192M packets, 205G bytes) pkts bytes target prot opt in 
out source destination |


Any ideas ? Thanks.





OpenPGP_signature
Description: OpenPGP digital signature

Re: [strongSwan] Strongswan IKEv2 certificates - "user authentication failed" ????

[Noel Kuntze]

Set connections..send_cert=yes

Exactly as shown in the generated conn. It's not present in the faulty 
configuration.


Am 26.04.21 um 21:01 schrieb bls s:

I use nearly the same. Here’s the complete connection definition for iOS as 
generated by my pistrong strongSwan management tool:

     ios-pubkey-ikev2 {

     version = 2

     proposals = 
aes256-sha1-modp1024,aes192-sha256-modp3072,aes128-sha1-modp1536,aes128-sha256-modp1536,aes128-sha256-modp2048,default

     rekey_time = 0s

     pools = primary-pool-ipv4

     fragmentation = no

     dpd_delay = 30s

     send_cert = always

     local-1 {

  

auth = pubkey


  

cacerts = strongSwanCACert.pem


  

certs = ios-strongSwanVPNCert.pem


  

id = ios.crystix.com


     }

     remote-1 {

  

auth = eap-tls


      id = %any

     }

     children {

  

net-ios {


  local_ts = 0.0.0.0/0

  rekey_time = 0s

  dpd_action = clear

  esp_proposals = 
aes256-sha1-modp1024,aes192-sha256-modp3072,aes128-sha1-modp1536,aes128-sha256-modp1536,aes128-sha256-modp2048,default

  

}


     }

     }

     primary-pool-ipv4 {

     addrs = 10.92.10.0/24

     dns = 192.168.92.3

     }

}

*From:* Users  *On Behalf Of *Jafar 

Al-Gharaibeh

*Sent:* Monday, April 26, 2021 8:21 AM
*To:* pLAN9 Administrator ; users@lists.strongswan.org
*Subject:* Re: [strongSwan] Strongswan IKEv2 certificates - "user authentication 
failed" 

Try the following for "remote":

/    remote {
     auth = 

eap-tls
     eap_id 

= %any

     }/

--Jafar

On 4/24/21 10:33 PM, pLAN9 Administrator wrote:

I am trying to set up Strongswan to act as a remote access  server for an 
iPhone using IKEv2 certificate auth. It is a major headache!

I have made sure to set the SAN in both the server and phone certificate. 
Here is the the server SAN:

/    X509v3 extensions:
     

X509v3 Subject Alternative Name:

     DNS:echo.pLAN9.co
     

X509v3 Extended Key Usage:

     TLS Web Server Authentication, TLS Web Client 
Authentication/

Here is the phone SAN:

/    X509v3 extensions:
     

X509v3 Subject Alternative Name:

     DNS:pLAN9-iPhone.pLAN9.co
     

X509v3 Extended Key Usage:

     TLS Web Server Authentication, TLS Web Client 
Authentication/

Here is /etc/swanctl/swanctl.conf

/connections {
     RA {
     local_addrs = %any
     local {
     auth = pubkey
     certs = ECHO.crt
     id = @echo.pLAN9.co
     }
     remote {
     auth = pubkey
     id = %any
     }
     children {
     net {
     local_ts = 0.0.0.0/0
     esp_proposals = aes256-sha256
     }
     }
     version = 2
     proposals = aes256-sha256-modp2048
     send_certreq = no
     pools = pool
     }
}
pools {
     pool {
     addrs = 172.16.16.64/29
     dns = 172.16.16.1
     }
     }/

Here is the output of a connection:

/01[NET] received packet: from IPHONE_IP[9975] to STRONGSWAN_IP[500] (604 
bytes)
01[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(REDIR_SUP) N(NATD_S_IP) 
N(NATD_D_IP) N(FRAG_SUP) ]
01[IKE] IPHONE_IP is initiating an IKE_SA
01[CFG] selected proposal: 
IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
01[IKE] remote host is behind NAT
01[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) 
N(NATD_D_IP) N(FRAG_SUP) N(CHDLESS_SUP) N(MULT_AUTH) ]
01[NET] sending packet: from STRONGSWAN_IP[500] to IPHONE_IP[9975] (456 
bytes)
10[NET] received packet: from IPHONE_IP[9959] to STRONGSWAN_IP[4500] (532 
bytes)
10[ENC] parsed IKE_AUTH request 1 [ EF(1/4) ]
13[NET] received packet: from IPHONE_IP[9959] to STRONGSWAN_IP[4500] (532 
bytes)
10[ENC] received fragment #1 of 4, waiting for complete IKE message
13[ENC] parsed IKE_AUTH request 1 [ EF(2/4) ]
13[ENC] received fragment #2 of 4, waiting for complete IKE message
14[NET] received packet: from IPHONE_IP[9959] to STRONGSWAN_IP[4500] (532 
bytes)
14[ENC] parsed IKE_AUTH request 1 [ EF(3/4) ]
01[NET] received packet: from IPHONE_IP[9959] to STRONGSWAN_IP[4500] (180 
bytes)
14[ENC] received fragment #3 of 4, waiting for complete 

Re: [strongSwan] chain multiple vpn on android

[Noel Kuntze]

Hello Rafael,

The app does not support that.
Generally, because the Android app uses the same source code with just an 
Android specific UI and some extra plugins, the restrictions are at the very least those
of the base software (strongSwan). strongSwan doesn't support VPNs inside 
VPNs either explicitely because (AFAIK) the Linux kernel with XFRM can't do it.


Kind regards
Noel

Am 20.04.21 um 20:37 schrieb Rafael:

On Windows we can connect in a vpn inside other vpn.
Internet-->vpn1-->vpn2.  Is there a way to connect with andoird's
strongswan? When I try to connect it disconnect the first one.





OpenPGP_signature
Description: OpenPGP digital signature

Re: [strongSwan] pools attrs

[Noel Kuntze]

Hello Volodymyr,

The attributes are unhandled because there is no handler registered for it in 
the code.
You can extend the updown plugin to handle those attributes but it's unlikely 
your changes
would be merged because the updown plugin is considered deprecated.

Kind regards
Noel

Am 08.04.21 um 11:25 schrieb Volodymyr Litovka:

In general, what I need to get. I'm trying to build kind of mesh topology, 
where every host can be both client and server at the same time for different 
connections (it can accept connections and place connections to another hosts). 
Routing is OSPF-based and in order to run OSPF over tunnels, I need to specify 
an addressing on interface like the following statement -

$ ip addr add ${PLUTO_MY_SOURCEIP} peer ${PLUTO_PEER_SOURCEIP} dev 
xfrm${PLUTO_IF_ID_IN}

- while on the server side I have both server peer address (I just know 

it) and client peer address (PLUTO_PEER_SOURCEIP),
- the issue is on the client side: it has only PLUTO_MY_SOURCEIP and no 

ideas which is PLUTO_PEER_SOURCEIP


What I want is to use any of the available attribute in pools definition (e.g. 
"server") to signal on remote side server's peer address.

I managed to work over "dns" attribute (enabling dns_handler in updown.conf, 
while keeping resolve.conf disabled) but DNS is widely used attributed and this trick can 
be unapplicable in most situations.

So the question is - how to get e.g. "server" attribute in PLUTO_* variables?

On 08.04.2021 01:20, Volodymyr Litovka wrote:


Hi colleagues,

are there any ways to get remote side attributes, specified in "pools" 

section, like:


pools {
 s1-pool {
 addrs = 25.0.0.2-25.0.1.255
 netmask = "255.255.254.0"
 }
}

at the moment, my updown script on the client shows the following ones 

upon launch:


updown: PLUTO_PEER_ID=s1
updown: PLUTO_ME=10.1.2.10
updown: PLUTO_IF_ID_OUT=10
updown: PLUTO_PEER_CLIENT=0.0.0.0/0
updown: PLUTO_IF_ID_IN=10
updown: PLUTO_VERSION=1.1
updown: PLUTO_REQID=1
updown: PLUTO_MY_PORT=0
updown: PLUTO_MY_PROTOCOL=0
updown: PLUTO_PEER_PORT=0
updown: PLUTO_MY_SOURCEIP4_1=25.0.0.2
updown: PLUTO_CONNECTION=s2
updown: PLUTO_PEER_PROTOCOL=0
updown: PLUTO_MY_CLIENT=0.0.0.0/0
updown: PLUTO_MY_ID=s2
updown: PLUTO_PEER=10.1.1.10
updown: PLUTO_VERB=up-client
updown: PLUTO_INTERFACE=eth0
updown: PLUTO_UNIQUEID=1
updown: PLUTO_MY_SOURCEIP=25.0.0.2
updown: PLUTO_PROTO=esp
updown: PLUTO_UDP_ENC=4500

and there is no information on 'netmask' which is specified on the server.

Thank you.

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


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





OpenPGP_signature
Description: OpenPGP digital signature

Re: [strongSwan] negative rekeying time from swanctl -l

[Noel Kuntze]

Hi,

It means rekeying was supposed to happen in the past.
Beyond, I do not know.

Kind regards
Noel

Am 31.03.21 um 12:45 schrieb Marco Berizzi:

Hello everyone,

I have encountered that the output of 'swanctl -l' sometimes returns a negative 
value on the rekeying time. Does it have any sort of special meaning?

installed 890s ago, rekeying in -684s, expires in 10s

Marco





OpenPGP_signature
Description: OpenPGP digital signature

Re: [strongSwan] IPSEC vpn(strongswan) + users in AD

[Noel Kuntze]

Hello Gregory,

Your log already gives the clues.



(15) mschap: WARNING: No Cleartext-Password configured.  Cannot create
NT-Password
(15) mschap: WARNING: No Cleartext-Password configured.  Cannot create
LM-Password
(15) mschap: Creating challenge hash with username: testuser
(15) mschap: Client is using MS-CHAPv2
(15) mschap: ERROR: FAILED: No NT/LM-Password.  Cannot perform
authentication


(EAP-)MSCHAPv2 is a Challenge-Response protocol that requires either plaintext 
passwords
or (AFAIR) MD4 hashed passwords like in the AD. The RADIUS server needs to be 
able to retrieve either the password, or
the hashes, or delegate authentication to a party that has access to that 
information.

Kind regards

Noel

Am 26.02.21 um 19:39 schrieb Gregory Edigarov:

Good day,

some clues wanted.

strongswan -> freeradius -> AD

conn ikev2-vpn
     auto=add
     compress=no
     type=tunnel
     keyexchange=ikev2
     fragmentation=yes
     forceencaps=yes
     dpdaction=clear
     dpddelay=300s
     rekey=no
     left=%any
     leftid=@mailtest.go-lamp.com
     leftcert=server-cert.pem
     leftsendcert=always
     leftsubnet=0.0.0.0/0
     right=%any
     rightid=%any
     rightauth=eap-radius
     rightsourceip=10.10.10.0/24
     rightdns=8.8.8.8,8.8.4.4
     rightsendcert=never
     eap_identity=%identity

freeradius - I could show config, but I need to do a cleanup first.

AD is out of my control

Radius request is shown below:
(15) Received Access-Request Id 95 from 127.0.0.1:42093 to
127.0.0.1:1812 length 227
(15)   User-Name = "testuser"
(15)   NAS-Port-Type = Virtual
(15)   Service-Type = Framed-User
(15)   NAS-Port = 10
(15)   NAS-Port-Id = "ikev2-vpn"
(15)   NAS-IP-Address = 185.78.235.225
(15)   Called-Station-Id = "185.78.235.225[4500]"
(15)   Calling-Station-Id = "82.117.245.149[53824]"
(15)   EAP-Message =
0x020200431a0202003e31e2af5f308985e5021868674940c015e4e22bfe0b82797c5f5f18498fcfbbcbf1e99ffaa07427826d006564696761726f76
(15)   NAS-Identifier = "strongSwan"
(15)   State = 0xb601b33cb703a9c425336eef8323aee1
(15)   Message-Authenticator = 0x39a3a2b21bdd858e031ee2064b307a51
(15) session-state: No cached attributes
(15) # Executing section authorize from file
/etc/freeradius/3.0/sites-enabled/default
(15)   authorize {
(15) policy filter_username {
(15)   if () {
(15)   if ()  -> TRUE
(15)   if ()  {
(15) if ( =~ / /) {
(15) if ( =~ / /)  -> FALSE
(15) if ( =~ /@[^@]*@/ ) {
(15) if ( =~ /@[^@]*@/ )  -> FALSE
(15) if ( =~ /\.\./ ) {
(15) if ( =~ /\.\./ )  -> FALSE
(15) if (( =~ /@/) && ( !~ /@(.+)\.(.+)$/))  {
(15) if (( =~ /@/) && ( !~
/@(.+)\.(.+)$/))   -> FALSE
(15) if ( =~ /\.$/)  {
(15) if ( =~ /\.$/)   -> FALSE
(15) if ( =~ /@\./)  {
(15) if ( =~ /@\./)   -> FALSE
(15)   } # if ()  = notfound
(15) } # policy filter_username = notfound
(15) policy filter_password {
(15)   if ( &&   ( !=
"%{string:User-Password}")) {
(15)   if ( &&   ( !=
"%{string:User-Password}"))  -> FALSE
(15) } # policy filter_password = notfound
(15) [preprocess] = ok
(15) [mschap] = noop
(15) eap: Peer sent EAP Response (code 2) ID 2 length 67
(15) eap: No EAP Start, assuming it's an on-going EAP conversation
(15) [eap] = updated
(15) files: users: Matched entry DEFAULT at line 152
(15) [files] = ok
rlm_ldap (ldap): Reserved connection (16)
(15) ldap: EXPAND (samaccountname=%{%{Stripped-User-Name}:-%{User-Name}})
(15) ldap:    --> (samaccountname=testuser)
(15) ldap: Performing search in "dc=office,dc=local" with filter
"(samaccountname=testuser)", scope "sub"
(15) ldap: Waiting for search result...
rlm_ldap (ldap): Rebinding to URL
ldap://ForestDnsZones.office.local/DC=ForestDnsZones,DC=office,DC=local
rlm_ldap (ldap): Waiting for bind result...
rlm_ldap (ldap): Rebinding to URL
ldap://DomainDnsZones.office.local/DC=DomainDnsZones,DC=office,DC=local
rlm_ldap (ldap): Waiting for bind result...
rlm_ldap (ldap): Rebinding to URL
ldap://office.local/CN=Configuration,DC=office,DC=local
rlm_ldap (ldap): Waiting for bind result...
rlm_ldap (ldap): Bind successful
rlm_ldap (ldap): Bind successful
rlm_ldap (ldap): Bind successful
(15) ldap: User object found at DN "CN=Some Name,OU=Network & Technical
support,DC=office,DC=local"
(15) ldap: Processing user attributes
(15) ldap: WARNING: No "known good" password added. Ensure the admin
user has permission to read the password attribute
(15) ldap: WARNING: PAP authentication will *NOT* work with Active
Directory (if that is what you were trying to configure)
rlm_ldap (ldap): Deleting connection (16) - Was referred to a different
LDAP server
(15) [ldap] = ok
(15) [expiration] = noop
(15) [logintime] = noop
(15)   } # authorize = updated
(15) Found Auth-Type = eap
(15) # Executing group from file /etc/freeradius/3.0/sites-enabled/default
(15)   authenticate {
(15) eap: Expiring EAP session with 

Re: [strongSwan] Performance of libipsec in strongswan ( kernel-vpp plugin )

[Noel Kuntze]

Hello Venu,

I am not aware of anything in that regard. It should be adressable though.
Tobias has actual insight to any internal roadmap (I do not).

Kind regards

Noel

Am 21.01.21 um 06:50 schrieb Venumadhav Josyula:

Hi Noel,

Thanks for the quick response. Is there something in the roadmap to address 
this case ?

Thanks,
Regards,
Venu

On Thu, 21 Jan 2021 at 10:37, Noel Kuntze 
 wrote:

Hello Venu,

That is still the case.

Kind regards

Noel

Am 21.01.21 um 05:52 schrieb Venumadhav Josyula:
 > Hi Tobias,
 >
 > In 'Issue #964', you mentioned it was not intended for high volume 
traffic. Is this still the case in lastest strongswan too. Meaning we have vpp 
based stack, where we want to use kernel-vpp plugin for the same. In other words, 
I want to know if it can be used in security gateways.
 >
 > Any pointers would be appreciated.
 >
 > Thanks,
 > Regards,
 > Venu





OpenPGP_signature
Description: OpenPGP digital signature

Re: [strongSwan] Performance of libipsec in strongswan ( kernel-vpp plugin )

[Noel Kuntze]

Hello Venu,

That is still the case.

Kind regards

Noel

Am 21.01.21 um 05:52 schrieb Venumadhav Josyula:

Hi Tobias,

In 'Issue #964', you mentioned it was not intended for high volume traffic. Is 
this still the case in lastest strongswan too. Meaning we have vpp based stack, 
where we want to use kernel-vpp plugin for the same. In other words, I want to 
know if it can be used in security gateways.

Any pointers would be appreciated.

Thanks,
Regards,
Venu




OpenPGP_signature
Description: OpenPGP digital signature

Re: [strongSwan] Facing a strange issue between Cisco ASR and strongswan v5.3

[Noel Kuntze]

Hi all,

Please provide logs as shown on the HelpRequests page[1] on the wiki.

Kind regards

Noel

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

Am 18.01.21 um 12:44 schrieb Volodymyr Litovka:

Hi George,

I don't remember exactly Cisco's commands to configure encryption, but it seems 
you config misses encryption settings for IKE negotiation. Your config on Cisco 
side should looks like the following:

! This is IKE encryption
crypto isakmp policy 10
   encryption ...
   hash ...
   group ...
   ...
! This is ESP encryption
crypto ipsec transform-set myset ...
!
crypto ipsec profile myprofile
   ...
   set transform-set myset
!
int tun151
  ...
  tunnel protection ipsec profile myprofile

and IKE encryption (isakmp policy) must match "ike" parameter in connection definition, 
while ESP encryption (ipsec transform-set) must match "esp" parameter.

Hope this'll help.

On 14.01.2021 22:38, george live wrote:

Hi all,
I am using strongswan version 5.3 on aws cloud and trying to set ipsec with a 
ciscoasr in customer site. It is not a complex scenario but the logs are 
telling me that strongswan is saying 'no proposals chosen'.

It is a ikev1, aes256, sha1 and df group 2.

Below are the configs:

Strongswan
=
config setup
    charondebug="ike 1, knl 0, cfg 0"
conn BRKTUNEL
    authby=secret
     auto=route
     dpddelay=10
     dpdtimeout=30
     dpdaction=restart
     esp=aes256-sha-modp1024
     ike=aes256-sha-modp1024
     ikelifetime=86400s
     lifetime=1h
     keyexchange=ikev1
     keyingtries=%forever
     rekey=yes
     forceencaps=yes
     # Specifics
     left=2.2.2.2            # Local private ip
     leftsubnet=%dynamic[gre]   # Local VPC Subnet
     leftid=2.2.2.2
     leftfirewall=yes
     rightfirewall=no
     right=1.1.1.1       # Remote Tunnel IP
     rightid=%any
     rightsubnet=%dynamic[gre] # Remote VPC Subnet
     type=tunnel

Customer ASR config

crypto isakmp profile abcd
description Default profile
vrf 10
keyring cust_key
match identity address 2.2.2.2
keepalive 10 retry 2
local-address 1.1.1.1
!
crypto keyring cust_key vrf 10
description Key ring for vrf 10 peers
local-address customer_ip vrf
pre-shared-key address 2.2.2.2 key x
!
crypto ipsec transform-set cust1-xform esp-aes 256 esp-sha-hmac
mode tunnel
!
crypto ipsec profile ipsec
set transform-set cust1-xform
set pfs group2
set isakmp-profile abcd
!
interface Tunnel151
description AWS
vrf forwarding 10
ip address 169.254.128.1 255.255.255.252
ip tcp adjust-mss 1379
tunnel source 1.1.1.1
tunnel destination 2.2.2.2
tunnel vrf 10
tunnel protection ipsec profile ipsec
ip virtual-reassembly

The debug logs says 'no IKE config found for 1.1.1.1...2.2.2.2, sending 
NO_PROPOSAL_CHOSEN'

Any help is appreciated.

Thanks,
George


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





OpenPGP_signature
Description: OpenPGP digital signature

Re: [strongSwan] ESP-encap port different than 4500

[Noel Kuntze]

Hi,

Set remote and local IKE ports to something else than 500 and NON-ESP markers 
are set automatically, so NAT-T is then on by default, so to say. Just start 
off with port 4510. No need to float up. :)

Kind regards

Noel

Am 08.01.21 um 15:09 schrieb Michael Schwartzkopff:

Hi,


I have two different VPN servers behind ONE NAT address. Yes, I know it
is nonsense, but it is the situation given here.


One runs with 500/4500. Everything is find. I configured the firewall to
forward packets on these port to the first VPN server.


I want to use port 510 and 4510 for the second server. I configured
charon.conf according.

On the client side I configured rightikeport=510. So the client sends
the init request from port 500 to port 510. The server recognizes the
NAT-T on both ends, sends back the response.


The clients sends third packet from port 4500 to port 4500, which fails
of course.


Is there any possibility to tell the client to use port 45100 of the
ESP-encap port?


Mit freundlichen Grüßen,





OpenPGP_signature
Description: OpenPGP digital signature

Re: [strongSwan] swanctl deadlock

[Noel Kuntze]

Hello Volodymyr,

> 1) does it mean that deadlock can happen if, for example, two swanctl 
> processes will be launched at the same time? Or this is only updown's issue 
> and in any other scenarios there will be no impact?

No, it only pertains the updown plugin.

> 2) are there ways to work around this issue in order to achieve what I'm 
> trying to achieve - detect IKE rekeying rather than downing connection to 
> avoid unnecessary changes to network?

I am not aware of any besides the workaround of doing it with a native plugin.

Kind regards

Noel

Am 18.11.20 um 10:54 schrieb Volodymyr Litovka:
> Hi Noel,
> 
> thank you. Two questions on this:
> 
> 1) does it mean that deadlock can happen if, for example, two swanctl 
> processes will be launched at the same time? Or this is only updown's issue 
> and in any other scenarios there will be no impact?
> 2) are there ways to work around this issue in order to achieve what I'm 
> trying to achieve - detect IKE rekeying rather than downing connection to 
> avoid unnecessary changes to network?
> 
> Thank you.
> 
> On 18.11.2020 11:36, Noel Kuntze wrote:
>> Hi,
>>
>> VICI acquires locks to do some stuff, which the updown script also does when 
>> it executes to save you the trouble of having to manually/externally 
>> serialize all the things you want to do in the updown script.
>> TL;DR: Don't do that, you get a deadlock with the updown script plugin.
>>
>> Kind regards
>>
>> Noel
>>
>> Am 18.11.20 um 09:32 schrieb Volodymyr Litovka:
>>> Hi colleagues,
>>>
>>> I'm using call to swanctl in updown script in order to distinguish between 
>>> deleting connection and IKE rekeying, checking for existence of IKE session 
>>> and, thus, trying to avoid unnecessary changes to the network:
>>>
>>> # if there are no [re-]established SAs for this connection, then delete 
>>> networking for this connection
>>> if [ $PLUTO_VERB = "down-client" ] || [ $PLUTO_VERB = "down-host" ] && [ -z 
>>> "$(swanctl -l -n -i ${PLUTO_CONNECTION})" ]; then
>>>   ip link set $intf down
>>>   ip link del $intf
>>> fi
>>>
>>> but this creates deadlock when I'm restarting service by 'systemctl restart 
>>> strongswan': if there are existing sessions, then first and all subsequent 
>>> calls to swanctl (from updown script) freeze infinitely, stopping charon 
>>> restart itself - progress possible only by repeatedly killing every 
>>> launched 'swanctl' using SIGKILL signal. At the same time, any call to vici 
>>> also freezes - so this isn't a problem with swanctl but with vici 
>>> interface. It doesn't matter whether I call swanctl with or without '-n' 
>>> parameter or whether I call vici using "noblock" parameter set (1) or unset 
>>> (0) ( vici.Session(sock=s).list_sas({"noblock": 1}) )
>>>
>>> This behaviour raises few questions:
>>>
>>> 1) whether vici can be called simultaneously by different processes?
>>> 2) how is it possible to avoid such deadlocks? Documentation says nothing 
>>> about number of vici 'listeners' and the basic idea to increase amount of 
>>> these listeners can't be implemented.
>>>
>>> My environment is:
>>>
>>> OS: Ubuntu 20.04.1
>>> Strongswan: 5.8.2 (5.8.2-1ubuntu3.1)
>>>
>>> Thank you.
>>>
>>> --
>>> Volodymyr Litovka
>>>   "Vision without Execution is Hallucination." -- Thomas Edison
>>>
> --
> Volodymyr Litovka
>   "Vision without Execution is Hallucination." -- Thomas Edison
> 



signature.asc
Description: OpenPGP digital signature

Re: [strongSwan] why multiple SAs for one peer?

[Noel Kuntze]

Hello Victor,

Please provide a log as shown on the HelpRequests[1] page.

Kind regards

Noel

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

Am 13.11.20 um 04:13 schrieb Victor Sudakov:
> Dear Colleagues,
> 
> What's the reason for strongSwan to create (sometimes) multiple SAs for
> a single peer? Please see the example below where the "officeru3" peer
> looks fine to me while the "officeru4" peer has an extraneous SA.
> 
> root@tunn:~# ipsec status | grep officeru3
>officeru3{2}:  ROUTED, TRANSPORT, reqid 2
>officeru3{2}:   x.x.x.x/32[gre] === y.y.y.y/32[gre]
>officeru3[27]: ESTABLISHED 108 minutes ago, 
> x.x.x.x[x.x.x.x]...y.y.y.y[y.y.y.y]
>officeru3{83}:  INSTALLED, TRANSPORT, reqid 2, ESP in UDP SPIs: c1f542b3_i 
> 0e4df460_o
>officeru3{83}:   x.x.x.x/32[gre] === y.y.y.y/32[gre]
> root@tunn:~# 
> root@tunn:~# ipsec status | grep officeru4
>officeru4{3}:  ROUTED, TRANSPORT, reqid 3
>officeru4{3}:   x.x.x.x/32[gre] === z.z.z.z/32[gre]
>officeru4[30]: ESTABLISHED 60 minutes ago, 
> x.x.x.x[x.x.x.x]...z.z.z.z[z.z.z.z]
>officeru4{82}:  INSTALLED, TRANSPORT, reqid 3, ESP in UDP SPIs: c50d4bb3_i 
> 0f33c281_o
>officeru4{82}:   x.x.x.x/32[gre] === z.z.z.z/32[gre]
>officeru4[28]: ESTABLISHED 106 minutes ago, 
> x.x.x.x[x.x.x.x]...z.z.z.z[z.z.z.z]
>officeru4{84}:  INSTALLED, TRANSPORT, reqid 3, ESP in UDP SPIs: c02ebd2f_i 
> 0a5e786d_o
>officeru4{84}:   x.x.x.x/32[gre] === z.z.z.z/32[gre]
> root@tunn:~# 
> 



signature.asc
Description: OpenPGP digital signature

Re: [strongSwan] initiate from both sides

[Noel Kuntze]

Hi,

strongSwan doesn't handle that well as of now.
It might change in the future at some point.

Kind regards

Noel

Am 13.11.20 um 09:08 schrieb Christoph Harder:
> Hello everyone,
> 
> I'm using Strongswan on FreeBSD and wanted to ask if it is possible to have a 
> tunnel initiated by both sides?
> Currently I have one side witch uses start/restart/start for the 
> start/dpd/stop actions and one side that uses trap/trap/trap.
> However since I have dynamic ips on both sides, I'm relying on dynamic dns to 
> find the other host. But propagation of the new address takes a while, which 
> results in delays after the ip of the responder changes.
> If both sides would be initiating/reinitiating the tunnels, the problem would 
> be solved because if one side can't initiate the tunnel, due to dns 
> propagation delays the other side would be able to connect. (Well, unless 
> both sides get new ips at the same time.)
> Is this kond of configuration supported?
> 
> Best regards,
> Christoph
> 



signature.asc
Description: OpenPGP digital signature

Re: [strongSwan] no private key found

[Noel Kuntze]

Hi,

Please at least provide a full log as shown on the HelpRequests[1] page.

Kind regards

Noel

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

Am 16.11.20 um 15:46 schrieb Udo Pokojski:
> Hello,
> 
> 
> I am trying to set up an IPSEC-Tunnel authenticated by certificates. The 
> directory /etc/ipsec.d looks like this:
> 
> /etc/ipsec.d# ls -lR
> .:
> total 36
> drwxr-xr-x 2 root root 4096 Nov 12  2019 aacerts
> drwxr-xr-x 2 root root 4096 Nov 12  2019 acerts
> drwxr-xr-x 2 root root 4096 Sep 28 10:36 cacerts
> drwxr-xr-x 2 root root 4096 Nov 16 14:39 certs
> drwxr-xr-x 2 root root 4096 Nov 12  2019 crls
> drwxr-xr-x 2 root root 4096 Nov 12  2019 ocspcerts
> drwxr-xr-x 2 root root 4096 Nov 12  2019 policies
> drwx-- 2 root root 4096 Nov 16 14:40 private
> drwxr-xr-x 2 root root 4096 Nov 12  2019 reqs
> 
> ./aacerts:
> total 0
> 
> ./acerts:
> total 0
> 
> ./cacerts:
> total 4
> -rw-r--r-- 1 root root 2045 Sep 28 10:36 ca-cert.pem
> 
> ./certs:
> total 16
> -rw-r--r-- 1 root root 1774 Apr  2  2020 ca-cert.pem
> -rw-r--r-- 1 root root 2339 Nov 16 15:03 office-cert.pem
> 
> ./crls:
> total 0
> 
> ./ocspcerts:
> total 0
> 
> ./policies:
> total 0
> 
> ./private:
> total 12
> -rw-r--r-- 1 root root 3243 Nov 16 14:24 office-key.pem
> 
> ./reqs:
> total 0
> 
> 
> This is the content of /etc/ipsec.secrets:
> 
> # RSA private key for this host, authenticating it to any other host
> # which knows the public part.
>  : RSA office-key.pem
> 
> This istthe configuration for the connection:
> 
> conn ikev2-rw
>     right=37.120.163.19
>     # This should match the `leftid` value on your server's configuration
>     rightid="C=DE, ... CN=server..."
>     rightsubnet=10.8.0.0/24,10.9.0.0/24
>     leftsubnet=192.168.200.0/24,192.168.20.0/24
>     rightauth=pubkey
>     leftsourceip=%config
>     leftid="C=DE, ... CN=client"
>  #   leftauth=eap-mschapv2
>     eap_identity=%identity
>     auto=start
>     dpdaction=restart
>     dpdinterval=10s
>     closeaction=restart
> 
> 
> 
> Establishing a connection fails. In the log I can these lines:
> 
> Nov 16 15:40:09 nb-ubuntu ipsec[4108]: 00[CFG]   loaded RSA private key from 
> '/etc/ipsec.d/private/office-key.pem'
> Nov 16 15:40:09 nb-ubuntu charon: 09[IKE] no private key found for 'C=DE, ... 
> CN=client'
> root@udo-nb-ubuntu:/etc/ipsec.d#
> 
> 
> The private keyfile is loaded, but the keys cannot be found. I double checked 
> that the keyfile matches the certificate.
> 
> Why is the private not found?
> 
> 
> Thanks in advance
> 
> Udo
> 



signature.asc
Description: OpenPGP digital signature

Re: [strongSwan] Charon crashes after trying to initiate 990+ IKE SAs

[Noel Kuntze]

Hi,

Please provide all information as shown on the HelpRequests[1] page, as well as 
the stacktrace.

Kind regards

Noel

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

Am 18.11.20 um 10:01 schrieb Liam Schönberg:
> Hi,
> 
> I'm encountering the situation where Charon crashes after trying to initiate 
> 990+ IKE SAs. What we're trying to do here is a stress test against our VPN 
> server.
> 
>> Nov 17 21:54:24 ip-100-84-217-47 ipsec[2175]: 13[IKE] IKE_SA CONN00988[988] 
>> established between 100.84.217.47[INIT00988]...1.2.3.4[1.2.3.4]
>> Nov 17 21:54:24 ip-100-84-217-47 charon: 13[ENC] generating AGGRESSIVE 
>> request 0 [ HASH NAT-D NAT-D ]
>> Nov 17 21:54:24 ip-100-84-217-47 charon: 13[NET] sending packet: from 
>> 100.84.217.47[10988] to 1.2.3.4[4500] (108 bytes)
>> Nov 17 21:54:24 ip-100-84-217-47 charon: 13[ENC] generating QUICK_MODE 
>> request 4075658581 [ HASH SA No KE ID ID ]
>> Nov 17 21:54:24 ip-100-84-217-47 charon: 13[NET] sending packet: from 
>> 100.84.217.47[10988] to 1.2.3.4[4500] (316 bytes)
>> Nov 17 21:54:24 ip-100-84-217-47 charon: 05[IKE] initiating Aggressive Mode 
>> IKE_SA CONN00997[997] to 1.2.3.4
>> Nov 17 21:54:24 ip-100-84-217-47 charon: 05[ENC] generating AGGRESSIVE 
>> request 0 [ SA KE No ID V V V V V ]
>> Nov 17 21:54:24 ip-100-84-217-47 charon: 05[NET] sending packet: from 
>> 100.84.217.47[10997] to 1.2.3.4[4500] (367 bytes)
>> Nov 17 21:54:24 ip-100-84-217-47 charon: 06[CFG] received stroke: add 
>> connection 'CONN00998'
>> Nov 17 21:54:24 ip-100-84-217-47 charon: 06[CFG] added configuration 
>> 'CONN00998'
>> Nov 17 21:54:24 ip-100-84-217-47 ipsec[2175]: 13[IK*** buffer overflow 
>> detected ***: /usr/lib/ipsec/charon terminated
>> Nov 17 21:54:24 ip-100-84-217-47 charon: 10[CFG] received stroke: initiate 
>> '10_akei00998'
>> Nov 17 21:54:24 ip-100-84-217-47 ipsec[2175]: reading stroke response failed
>> Nov 17 21:54:24 ip-100-84-217-47 ipsec[2175]: connecting to 
>> 'unix:///var/run/charon.ctl' failed: Connection refused
>> Nov 17 21:54:24 ip-100-84-217-47 ipsec[2175]: failed to connect to stroke 
>> socket 'unix:///var/run/charon.ctl'
>> Nov 17 21:54:24 ip-100-84-217-47 ipsec[2175]: connecting to 
>> 'unix:///var/run/charon.ctl' failed: Connection refused
>> Nov 17 21:54:24 ip-100-84-217-47 ipsec[2175]: failed to connect to stroke 
>> socket 'unix:///var/run/charon.ctl'
>> Nov 17 21:54:24 ip-100-84-217-47 ipsec[2175]: connecting to 
>> 'unix:///var/run/charon.ctl' failed: Connection refused
>> Nov 17 21:54:24 ip-100-84-217-47 ipsec[2175]: failed to connect to stroke 
>> socket 'unix:///var/run/charon.ctl'
>> Nov 17 21:54:24 ip-100-84-217-47 ipsec[2175]: charon has died -- restart 
>> scheduled (5sec)
>> Nov 17 21:54:25 ip-100-84-217-47 systemd[1]: Started Session 4 of user 
>> ubuntu.
>> Nov 17 21:54:29 ip-100-84-217-47 charon: 00[DMN] Starting IKE charon daemon 
>> (strongSwan 5.6.2, Linux 5.4.0-1029-aws, x86_64)
> 
> Could anybody tell me what I should do differently, so that it can initiate 
> up to 20,000 IKE SAs? Here's the config I'm using on the initiator side...
> 
>> config setup
>> conn %default
>>         right=1.2.3.4
>>         ikelifetime=3600s
>>         keylife=28800s
>>         rekeymargin=3m
>>         keyingtries=1
>>         keyexchange=ikev1
>>         leftauth=psk
>>         rightauth=psk
>>         ike=aes128-sha1-modp1024!
>>         esp=aes128-sha1-modp1024!
>>         authby=secret
>>         aggressive=yes
>>         rightsubnet=100.110.171.0/24
>>         auto=add
>> conn CONN1
>>         leftid=@INIT1
>>         leftsubnet=10.1.1.0/24
>>         leftikeport=10001
>>         rightikeport=4500
> 
> Any suggestions or comments would be greatly appreciated.
> 
> Best regards,
> 
> jellybeanshiba



signature.asc
Description: OpenPGP digital signature

Re: [strongSwan] swanctl deadlock

[Noel Kuntze]

Hi,

VICI acquires locks to do some stuff, which the updown script also does when it 
executes to save you the trouble of having to manually/externally serialize all 
the things you want to do in the updown script.
TL;DR: Don't do that, you get a deadlock with the updown script plugin.

Kind regards

Noel

Am 18.11.20 um 09:32 schrieb Volodymyr Litovka:
> Hi colleagues,
> 
> I'm using call to swanctl in updown script in order to distinguish between 
> deleting connection and IKE rekeying, checking for existence of IKE session 
> and, thus, trying to avoid unnecessary changes to the network:
> 
> # if there are no [re-]established SAs for this connection, then delete 
> networking for this connection
> if [ $PLUTO_VERB = "down-client" ] || [ $PLUTO_VERB = "down-host" ] && [ -z 
> "$(swanctl -l -n -i ${PLUTO_CONNECTION})" ]; then
>   ip link set $intf down
>   ip link del $intf
> fi
> 
> but this creates deadlock when I'm restarting service by 'systemctl restart 
> strongswan': if there are existing sessions, then first and all subsequent 
> calls to swanctl (from updown script) freeze infinitely, stopping charon 
> restart itself - progress possible only by repeatedly killing every launched 
> 'swanctl' using SIGKILL signal. At the same time, any call to vici also 
> freezes - so this isn't a problem with swanctl but with vici interface. It 
> doesn't matter whether I call swanctl with or without '-n' parameter or 
> whether I call vici using "noblock" parameter set (1) or unset (0) ( 
> vici.Session(sock=s).list_sas({"noblock": 1}) )
> 
> This behaviour raises few questions:
> 
> 1) whether vici can be called simultaneously by different processes?
> 2) how is it possible to avoid such deadlocks? Documentation says nothing 
> about number of vici 'listeners' and the basic idea to increase amount of 
> these listeners can't be implemented.
> 
> My environment is:
> 
> OS: Ubuntu 20.04.1
> Strongswan: 5.8.2 (5.8.2-1ubuntu3.1)
> 
> Thank you.
> 
> --
> Volodymyr Litovka
>   "Vision without Execution is Hallucination." -- Thomas Edison
> 



signature.asc
Description: OpenPGP digital signature

[strongSwan] Translating ipsec.conf to swanctl.conf: A script to do that

[Noel Kuntze]

Hello list,

I developed a script to translate ipsec.conf to swanctl.conf syntax files.
It is available in a Gitlab repo[1] and is written in Python3, has no external
dependencies and is licensed under the GPLv3.
You're free to use it.

I just added a link to it to the user wiki page.

Please let me know if there are any issues with it.

Kind regards

Noel

[1] https://gitlab.com/Thermi/ipsec2swanctl
-- 
Noel Kuntze
IT security consultant

GPG Key ID: 0x0739AD6C
Fingerprint: 3524 93BE B5F7 8E63 1372 AF2D F54E E40B 0739 AD6C



signature.asc
Description: OpenPGP digital signature

Re: [strongSwan] traffic beyond initiator yes, but no between initiator & server

[Noel Kuntze]

Hi Lejeczek,

> I do not see, not on the server nor on initiator, any tun
> devices created, unless an 'ipsec0' is such one iface. It's
> the only iface I see made by strongswan's libipsec.

Device names are arbitrary and thus not useful for identifying the type of 
interface.
the ipsec0 device is created by kernel-libipsec and is the one you should use.

You can use `ip -d l` to see the type of a network device.

>>
>>> mode = pass
> I've tried all modes available.

That doesn't make it work though. Don't set it. libipsec only supports tunnel 
mode SAs anyway.


> If I do not have a iface on the server with 10.3.9.0/24 then
> roadwarrior fails with:
> ...
> [IKE] received TS_UNACCEPTABLE notify, no CHILD_SA built
> [IKE] failed to establish CHILD_SA, keeping IKE_SA
> initiate failed: establishing CHILD_SA 'to-tinyionos' failed
> 
> Maybe I should add, in case there is something very
> different there, I'm on Centos 8 and libipsec I mention is:
> strongswan-libipsec-5.8.2-5.el8.x86_64
> 
> What's is not 'normal' in my roadwarrior config?
> 
> many thanks, L.
> 

I now see that you probably don't want to use a roadwarrior config but a 
site-to-site config.
You're just confused. Which is the reason for this weird config.
I guess you want to connect the two sides using libipsec? 

libipsec is used for roadwarrior type scenarios and thus where the negotiated 
local_ts is required to contain a local IP after
any VIPs were assigned. I don't know how strongSwan behaves if you make both 
sides request VIPs, but only configure a pool on one.
I assume negotiation should actually fail because the side without the pool 
doesn't respond (to the configuration payload (CP) request of the other side)
with a VIP.

>> [IKE] received TS_UNACCEPTABLE notify, no CHILD_SA built

The other side's log will tell you why that notify was sent.

If you actually need to use libispec on both sides, then assign the two sides 
static IPs in their LAN range using CPs and set remote_ts and local_ts to the 
corresponding host's networks.
That way the VIP will be inside the TSs and negotiation will succeed.

You probably don't want to use libipsec though but XFRM in policy mode, or 
configure a route based IPsec tunnel.

What do you actually want to do? 

Kind regards

Noel

Am 05.11.20 um 21:46 schrieb lejeczek:
> 
> 
> On 05/11/2020 17:19, Noel Kuntze wrote:
>> Hello Lejeczek,
>>
>> kernel-libipsec (which is required to be loaded for libipsec to be usable) 
>> creates a tun interface itself. You can not prescribe it to use one.
> I do not see, not on the server nor on initiator, any tun
> devices created, unless an 'ipsec0' is such one iface. It's
> the only iface I see made by strongswan's libipsec.
>>
>>> mode = pass
> I've tried all modes available.
>> That disables all IPsec processing for traffic that matches the policies. 
>> You probably don't want to do that.
>>
>>> 1) Obvious - how to make it work?
>> Completely different from what you configured. Just use a normal roadwarrior 
>> config.
> If I do not have a iface on the server with 10.3.9.0/24 then
> roadwarrior fails with:
> ...
> [IKE] received TS_UNACCEPTABLE notify, no CHILD_SA built
> [IKE] failed to establish CHILD_SA, keeping IKE_SA
> initiate failed: establishing CHILD_SA 'to-tinyionos' failed
> 
> Maybe I should add, in case there is something very
> different there, I'm on Centos 8 and libipsec I mention is:
> strongswan-libipsec-5.8.2-5.el8.x86_64
> 
> What's is not 'normal' in my roadwarrior config?
> 
> many thanks, L.
> 
>>
>> Kind regards
>>
>> Noel
>>
>> Am 05.11.20 um 17:45 schrieb lejeczek:
>>> Hi guys
>>>
>>> To start I should say I'm trying this with libipsec.
>>>
>>> I have an initiator with local 10.3.1.0/24 and a following
>>> config:
>>>
>>>
>>> connections {
>>>   to-tinyionos {
>>>     version = 2
>>>     remote_addrs = "A.B.C.D"
>>>     vips = "0.0.0.0"
>>>     local {
>>>   auth = pubkey
>>>   certs = "my.cert.der"
>>>     }
>>>     remote {
>>>   certs = "server.cert.der"
>>>     }
>>>     children {
>>>   to-tinyionos {
>>>     mark_in = %unique
>>>     mark_out = %unique
>>>     remote_ts = "10.3.9.0/24"
>>>     local_ts = "10.3.1.0/24"
>>>     #mode = "tunnel"
>>>     mode = pass
>>>   }
>>>     }
>>>   }
>>> }
>>>
>>> and there I have a server with a tun iface:
&

Re: [strongSwan] traffic beyond initiator yes, but no between initiator & server

[Noel Kuntze]

Hello Lejeczek,

kernel-libipsec (which is required to be loaded for libipsec to be usable) 
creates a tun interface itself. You can not prescribe it to use one.

> mode = pass

That disables all IPsec processing for traffic that matches the policies. You 
probably don't want to do that.

> 1) Obvious - how to make it work?

Completely different from what you configured. Just use a normal roadwarrior 
config.

Kind regards

Noel

Am 05.11.20 um 17:45 schrieb lejeczek:
> Hi guys
> 
> To start I should say I'm trying this with libipsec.
> 
> I have an initiator with local 10.3.1.0/24 and a following
> config:
> 
> 
> connections {
>   to-tinyionos {
>     version = 2
>     remote_addrs = "A.B.C.D"
>     vips = "0.0.0.0"
>     local {
>   auth = pubkey
>   certs = "my.cert.der"
>     }
>     remote {
>   certs = "server.cert.der"
>     }
>     children {
>   to-tinyionos {
>     mark_in = %unique
>     mark_out = %unique
>     remote_ts = "10.3.9.0/24"
>     local_ts = "10.3.1.0/24"
>     #mode = "tunnel"
>     mode = pass
>   }
>     }
>   }
> }
> 
> and there I have a server with a tun iface:
> 
> 17: forswan:  mtu
> 1500 qdisc fq_codel state DOWN group default qlen 500
>     link/none
>     inet 10.3.9.1/24 brd 10.3.9.255 scope global
> noprefixroute forswan
>    valid_lft forever preferred_lft forever
> 
> and server config, connection part:
> 
> 
>   fenbox {
>     version = 2
>     pools = "myclient"
>     vips = "0.0.0.0"
>     remote {
>   auth = "pubkey"
>   id = "O=client, CN=tiny.client"
>     }
>     children {
>   fenbox {
>     mark_in = %unique
>     mark_out = %unique
>     local_ts = "10.3.9.0/24"
>     remote_ts = "10.3.1.0/24"
>     #mode = transport
>     #mode = "tunnel"
>     mode = pass
>   }
>     }
>   }
> 
> 
> What I'd like to get, which I'm not for some reason, is:
> - to access IP of 10.3.9.0/24 subnet.
> From the server I can get to initiator's 10.3.1.0/24, but
> the server with 10.3.9.1 on tun iface cannot get to
> initiator's assigned 10.3.9.254.
> I have two questions:
> 1) Obvious - how to make it work?
> 2) I notice that initiators gets an IP: 10.3.9.254/32 - is
> this that subnet because how libipsec works and if yes then
> can it be controlled and changed?
> 
> many thanks, L.
> 



signature.asc
Description: OpenPGP digital signature

Re: [strongSwan] Strongswan with ECDSA certificate

[Noel Kuntze]

Hello George,

Please share a complete log as shown on the HelpRequests page on the wiki.
Use the filelogger at the bottom of it.

Kind regards

Noel

Am 05.11.20 um 20:20 schrieb george:
> Hi Strongswan users!
> 
> This is my first post. I have problems to use ECDSA 
> certificates with strongswan (did not have problems with
> RSA certificates).
> 
> Please help to solve this problem. Thanks.
> 
> ipsec.conf file 
> 
> conn ss_as_init_cert_x2_22685
>     left=172.16.58.97        
>     leftid=Userikev2-A       
>     leftsubnet=172.16.58.93/32
>     #leftsourceip=%config     
>     leftfirewall=yes          
>     leftauth=pubkey           
>     leftcert=user-cert-ikev2-A.pem
>     keyingtries=2                 
>     reauth=no                     
>     right=172.16.58.96            
>     rightauth=pubkey              
>     rightid=%any
>     rightsubnet=172.16.58.96/32
>     auto=add
>     ike=aes256-sha512-modp2048!
>     keyexchange=ikev2
>     type=tunnel
>     esp=aes256-sha512-modp2048!
>     ikelifetime=60m
>     lifetime=30m
>     margintime=1s
>     rekey=yes
>     dpdaction=none
>     dpddelay=300s
>     dpdtimeout=10s
>     mobike=no
> 
> 
> Certificate:
> 
>   Data:
>         Version: 3 (0x2)
>         Serial Number: 4 (0x4)
>     Signature Algorithm: ecdsa-with-SHA1
>         Issuer: C=US, ST=Massachusetts, L=Bedford, O=acmepacket, 
> CN=root/emailAddress=tes...@acmepacket.com
>         Validity
>             Not Before: Nov  5 18:16:38 2020 GMT
>             Not After : May 24 18:16:38 2021 GMT
>         Subject: C=US, ST=Massachusetts, O=acmepacket.com, 
> CN=Userikev2-A/emailAddress=userikev...@acmepacket.com
>         Subject Public Key Info:
>             Public Key Algorithm: id-ecPublicKey
>                 Public-Key: (256 bit)
>                 pub:
>                     04:36:43:df:ab:7a:1e:e4:33:7e:da:4c:da:42:67:
>                     02:1c:3b:d0:ef:33:91:95:45:84:50:2d:34:b6:6f:
>                     20:79:3e:a1:82:e6:e4:98:b3:56:cb:7a:b8:f3:c9:
>                     ff:0e:8c:33:a9:90:e4:55:9f:c9:28:4d:f5:15:2f:
>                     d0:78:ab:94:d8
>                 ASN1 OID: prime256v1
>         X509v3 extensions:
>             X509v3 Basic Constraints:
>                 CA:FALSE
>             X509v3 Subject Key Identifier:
>                 23:36:62:1F:64:ED:C1:45:34:8D:52:C5:07:3C:68:AE:7F:92:8F:DE
>             X509v3 Authority Key Identifier:
>                 
> keyid:1D:6A:76:68:32:A7:3B:48:35:6C:F1:3F:76:7A:06:12:F2:51:0A:2E
>                 
> DirName:/C=US/ST=Massachusetts/L=Bedford/O=acmepacket/CN=root/emailAddress=tes...@acmepacket.com
>                 serial:BD:52:8A:11:94:74:C2:20
> 
>             X509v3 Key Usage:
>                 Digital Signature, Key Encipherment
>             X509v3 Issuer Alternative Name:
>                 DNS:abc.com
>             X509v3 Subject Alternative Name:
>                 DNS:abc.com
>     Signature Algorithm: ecdsa-with-SHA1
>          30:45:02:21:00:f0:9e:68:b6:18:9a:aa:93:56:ad:74:80:d1:
>          2b:ce:9f:85:12:1b:19:17:ef:b2:10:d0:c4:14:28:18:42:79:
>          15:02:20:5d:32:32:bd:02:98:c2:28:9e:c9:10:5c:06:36:e7:
>          6d:37:5e:2c:f5:97:96:6b:54:e4:3d:63:59:8e:cb:95:d6
> 
> 
> 
> Private Key:
> 
> read EC key
> Private-Key: (256 bit)
> priv:
>     7b:7b:d0:11:9c:57:bc:86:2e:e9:29:d8:a1:54:a1:
>     32:bd:c4:4b:79:a2:ac:23:4e:7f:3e:16:88:47:4e:
>     f7:29
> pub:
>     04:36:43:df:ab:7a:1e:e4:33:7e:da:4c:da:42:67:
>     02:1c:3b:d0:ef:33:91:95:45:84:50:2d:34:b6:6f:
>     20:79:3e:a1:82:e6:e4:98:b3:56:cb:7a:b8:f3:c9:
>     ff:0e:8c:33:a9:90:e4:55:9f:c9:28:4d:f5:15:2f:
>     d0:78:ab:94:d8
> ASN1 OID: prime256v1
> writing EC key
> -BEGIN EC PRIVATE KEY-
> MHcCAQEEIHt70BGcV7yGLukp2KFUoTK9xEt5oqwjTn8+FohHTvcpoAoGCCqGSM49
> AwEHoUQDQgAENkPfq3oe5DN+2kzaQmcCHDvQ7zORlUWEUC00tm8geT6hgubkmLNW
> y3q488n/DowzqZDkVZ/JKE31FS/QeKuU2A==
> -END EC PRIVATE KEY-
> 
> 
> IPSEC Secerts file
> 
> : ECDSA user-key-ikev2-A.pem
> : ECDSA user-key-ikev2-B.pem
> 
> 
> 
> 
> CHARON OUTPUT
> 
> feature PUBKEY:ECDSA in plugin 'pem' has unmet dependency: PUBKEY:ECDSA
> Nov  5 13:57:19 00[LIB] feature PUBKEY:DSA in plugin 'pem' has unmet 
> dependency: PUBKEY:DSA
> Nov  5 13:57:19 00[LIB] feature PRIVKEY:DSA in plugin 'pem' has unmet 
> dependency: PRIVKEY:DSA
> Nov  5 13:57:19 00[LIB] feature PRIVKEY:BLISS in plugin 'pem' has unmet 
> dependency: PRIVKEY:BLISS
> Nov  5 13:57:19 00[LIB] feature CERT_DECODE:X509_OCSP_REQUEST in plugin 'pem' 
> has unmet dependency: CERT_DECODE:X509_OCSP_REQUEST
> Nov  5 13:57:19 00[LIB] feature PRF:PRF_CAMELLIA128_XCBC in plugin 'xcbc' has 
> unmet dependency: CRYPTER:CAMELLIA_CBC-16
> Nov  5 13:57:19 00[LIB] feature SIGNER:CAMELLIA_XCBC_96 in plugin 'xcbc' has 
> unmet dependency: CRYPTER:CAMELLIA_CBC-16
> Nov  5 13:57:19 00[CFG] loading ca certificates from 
> '/usr/local/etc/ipsec.d/cacerts'
> Nov  5 13:57:19 00[ASN]   file content is not binary ASN.1
> Nov  5 13:57:19 00[ASN]   -BEGIN 

Re: [strongSwan] private key not found

[Noel Kuntze]

Hello Christoph,

Yes, use pubkeys = . The man page for swanctl.conf expands on this:

>   connections..local.pubkeys []
>  Comma separated list of raw public key candidates to use for au‐
>  thentication. The public keys may use a relative path  from  the
>  swanctl pubkey directory or an absolute path.
>
>  Even though multiple local public keys could be defined in prin‐
>  ciple, only the first public key in the list is used for authen‐
>  tication.

>> The documentation isn't totally clear about it and tells me the pubkeys 
>> configuration is for raw keys (does it mean file names of pem/der encoded 
>> keys?).

Raw public keys are just simple public keys, e.g. certificates aren't raw 
public keys (because they are a public key, metadata and the signature over it 
generated by signing it with a private key).
So the file would contain a public key, encoded in DER or PEM format.

Kind regards

Noel

Am 26.10.20 um 15:57 schrieb Christoph Harder:
> Hello Noel,
> 
> just to be sure, I use pubkeys =  to specify the keys or rather the 
> pem files containing them?
> Or should the key be somehow encoded and put as string in the swanctl.conf 
> file?
> The documentation isn't totally clear about it and tells me the pubkeys 
> configuration is for raw keys (does it mean file names of pem/der encoded 
> keys?).
> 
> Thank you in advance.
> -Christoph
> 
> 
> Am 25.10.2020 um 22:03 schrieb 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)

[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] kernel traps with auto=route, and "install_routes=no" - how to view traps installed and the routes if any installed by Strongswan-Charon

[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] private key not found

[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)

[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] Intermittent drop-out of VPN connection

[Noel Kuntze]

Hi,

Configure your own side with lower reauth and rekey times than the other peer.
Currently the other peer tries to reauth which fails because you're using the 
insecure aggressive mode. strongSwan by default rejects other peers' 
authentication requests if they're using aggressive mode.
A reauthentication is basically creating a new IKE_SA from scratch, so that 
behavior applies.

Just configure your client with lower rekey and reauth times. That's simpler 
than globally enabling aggressive mode.

Kind regards

Noel

Am October 16, 2020 11:09:29 AM UTC schrieb Chris Smith 
:
>Hi,
>
>[re-sending with trimmed down charon.log to fit mailing list size
>limits.]
>
>I have a VPN connection which is generally stable, but occasionally
>(2-3 times per day) will drop out for a short period after what seems
>to be some disagreement between client and server.  The logs attached
>show an example of this, where the connection fails around 18:24:35 and
>is restored around a minute later.
>
>I’m using strongSwan 5.7.2 on the client.  I have no information or
>control over what is running on the server.
>
>I’d be grateful for any clues as to exactly what is happening and how
>to correct it.
>
>Regards,
>Chris
>—
>Chris Smith 

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: [strongSwan] Retry after failure

[noel . kuntze+strongswan-users-ml]

keyingtries

Am October 11, 2020 4:56:59 PM UTC schrieb Volodymyr Litovka :
>Colleagues,
>
>how to configure strongSwan to continuously try to reconnect in case of
>network failure?
>
>My current settings are:
>
>charon {
> close_ike_on_child_failure = yes
> retry_initiate_interval = 30
> retransmit_base = 1.2
> retransmit_limit = 30
> retransmit_timeout = 2
> retransmit_tries = 3
>}
>
>and, in case of network failure, strongSwan behaves in the following
>way
>- it tries to reestablish connection 3 times and then finally gives up:
>
>16:34:28 2020 daemon.info : 07[IKE] sending DPD request
>16:34:28 2020 daemon.info : 07[ENC] generating INFORMATIONAL request 2
>[ N(NATD_S_IP) N(NATD_D_IP) ]
>16:34:28 2020 daemon.info : 07[NET] sending packet: from
>192.168.2.212[4500] to xx.xx.xx.xx[4500] (113 bytes)
>16:34:30 2020 daemon.info : 08[IKE] retransmit 1 of request with
>message ID 2
>16:34:30 2020 daemon.info : 08[NET] sending packet: from
>192.168.2.212[4500] to xx.xx.xx.xx[4500] (113 bytes)
>16:34:32 2020 daemon.info : 09[IKE] retransmit 2 of request with
>message ID 2
>16:34:32 2020 daemon.info : 09[NET] sending packet: from
>192.168.2.212[4500] to xx.xx.xx.xx[4500] (113 bytes)
>16:34:35 2020 daemon.info : 10[IKE] retransmit 3 of request with
>message ID 2
>16:34:35 2020 daemon.info : 10[NET] sending packet: from
>192.168.2.212[4500] to xx.xx.xx.xx[4500] (113 bytes)
>16:34:39 2020 daemon.info : 11[IKE] giving up after 3 retransmits
>16:34:39 2020 daemon.info : 11[IKE] restarting CHILD_SA rc
>16:34:39 2020 daemon.info : 11[IKE] initiating IKE_SA rc[2] to
>xx.xx.xx.xx
>16:34:39 2020 daemon.info : 11[ENC] generating 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)
>]
>16:34:39 2020 daemon.info : 11[NET] sending packet: from
>192.168.2.212[500] to xx.xx.xx.xx[500] (1084 bytes)
>16:34:39 2020 daemon.info : 11[CHD] updown: Processing ''
>16:34:41 2020 daemon.info : 13[IKE] retransmit 1 of request with
>message ID 0
>16:34:41 2020 daemon.info : 13[NET] sending packet: from
>192.168.2.212[500] to xx.xx.xx.xx[500] (1084 bytes)
>16:34:43 2020 daemon.info : 14[IKE] retransmit 2 of request with
>message ID 0
>16:34:43 2020 daemon.info : 14[NET] sending packet: from
>192.168.2.212[500] to xx.xx.xx.xx[500] (1084 bytes)
>16:34:46 2020 daemon.info : 15[IKE] retransmit 3 of request with
>message ID 0
>16:34:46 2020 daemon.info : 15[NET] sending packet: from
>192.168.2.212[500] to xx.xx.xx.xx[500] (1084 bytes)
>16:34:49 2020 daemon.info : 16[IKE] giving up after 3 retransmits
>16:34:49 2020 daemon.info : 16[IKE] peer not responding, trying again
>(2/3)
>16:34:49 2020 daemon.info : 16[IKE] initiating IKE_SA rc[2] to
>xx.xx.xx.xx
>16:34:49 2020 daemon.info : 16[ENC] generating 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)
>]
>16:34:49 2020 daemon.info : 16[NET] sending packet: from
>192.168.2.212[500] to xx.xx.xx.xx[500] (1084 bytes)
>16:34:51 2020 daemon.info : 05[IKE] retransmit 1 of request with
>message ID 0
>16:34:51 2020 daemon.info : 05[NET] sending packet: from
>192.168.2.212[500] to xx.xx.xx.xx[500] (1084 bytes)
>16:34:54 2020 daemon.info : 08[IKE] retransmit 2 of request with
>message ID 0
>16:34:54 2020 daemon.info : 08[NET] sending packet: from
>192.168.2.212[500] to xx.xx.xx.xx[500] (1084 bytes)
>16:34:57 2020 daemon.info : 09[IKE] retransmit 3 of request with
>message ID 0
>16:34:57 2020 daemon.info : 09[NET] sending packet: from
>192.168.2.212[500] to xx.xx.xx.xx[500] (1084 bytes)
>16:35:00 2020 daemon.info : 06[IKE] giving up after 3 retransmits
>16:35:00 2020 daemon.info : 06[IKE] peer not responding, trying again
>(3/3)
>16:35:00 2020 daemon.info : 06[IKE] initiating IKE_SA rc[2] to
>xx.xx.xx.xx
>16:35:00 2020 daemon.info : 06[ENC] generating 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)
>]
>16:35:00 2020 daemon.info : 06[NET] sending packet: from
>192.168.2.212[500] to xx.xx.xx.xx[500] (1084 bytes)
>16:35:02 2020 daemon.info : 10[IKE] retransmit 1 of request with
>message ID 0
>16:35:02 2020 daemon.info : 10[NET] sending packet: from
>192.168.2.212[500] to xx.xx.xx.xx[500] (1084 bytes)
>16:35:05 2020 daemon.info : 11[IKE] retransmit 2 of request with
>message ID 0
>16:35:05 2020 daemon.info : 11[NET] sending packet: from
>192.168.2.212[500] to xx.xx.xx.xx[500] (1084 bytes)
>16:35:07 2020 daemon.info : 13[IKE] retransmit 3 of request with
>message ID 0
>16:35:07 2020 daemon.info : 13[NET] sending packet: from
>192.168.2.212[500] to xx.xx.xx.xx[500] (1084 bytes)
>16:35:11 2020 daemon.info : 12[IKE] giving up after 3 retransmits
>16:35:11 2020 daemon.info : 12[IKE] establishing IKE_SA failed, peer
>not responding
>
>Is there way to make it try continuously in order to establish
>connection as soon as network will be available again?
>
>In case it's essential, my environment is:
>
>- OS: OpenWRT 19.07.3
>- strongSwan: 5.8.2 (5.8.2_2)
>

Re: [strongSwan] Why no entries in route table 220

[Noel Kuntze]

Hello Leroy,

Routes in table 220 are only added when needed now (might be later, but the 
existence of any is not a suitable indicator of any success or failure, what 
the IKE daemon reports is what you should look at).

What is the actual issue?

Kind regards

Noel

Am 08.10.20 um 19:40 schrieb Leroy Tennison:
> We're on Strongswan 5.3.5 on Ubuntu 16.04 (kernel 4.0-171-generic).  I've 
> searched the web and found very little references to table 220 issues but, 
> after "ipsec start", "ipsec statusall" shows the connection (as does ip xfrm 
> policy and ip xfrm state) and table 220 is empty.  This is the first time 
> this has happened to me (admittedly, only two other IPSec setups using 
> Strongswan).  Below are the configuration files (except ipsec.secrets which 
> has one uncommented line in the form: 67.nnn.nnn.nnn : PSK  obfuscated>) with IP addresses and conn names (but nothing else) obfuscated.  
> What am I doing wrong?  Any further debugging steps I can take? Anything else 
> you need to know?  Thanks for your help.
> 
> # ipsec.conf - strongSwan IPsec configuration file
> 
> # basic configuration
> 
> config setup
>         # strictcrlpolicy=yes
>         # uniqueids = no
> 
> # Add connections here.
> 
> # Sample VPN connections
> 
> conn %default
>         authby=psk
>         auto=start
>         dpdaction=restart
>         dpddelay=30s
>         esp=aes256-sha256-ecp384
>         ike=aes256-sha256-ecp384
>         keyexchange=ikev2
>         left=67.nnn.nnn.nnn
>         leftauth=psk
>         leftfirewall=yes
>         lifetime=3h
> #        mark=77    tested with vti - didn't help
>         right=64.mmm.mmm.mmm
>         rightauth=psk
> # See strongswan.conf for retransmission settings
> 
> conn Rock-Roll-aaa-qqq
>         leftsubnet=10.xxx.aaa.0/24
>         rightsubnet=10.64.qqq.0/24
> 
> conn Rock-Roll-bbb-qqq
>         leftsubnet=10.xxx.bbb.0/24
>         rightsubnet=10.64.qqq.0/24
> 
> conn Rock-Roll-ccc-qqq
>         leftsubnet=10.xxx.ccc.0/24
>         rightsubnet=10.64.qqq.0/24
> 
> conn Rock-Roll-aaa-rrr
>         leftsubnet=10.xxx.aaa.0/24
>         rightsubnet=10.64.rrr.0/24
> 
> conn Rock-Roll-bbb-rrr
>         leftsubnet=10.xxx.bbb.0/24
>         rightsubnet=10.64.rrr.0/24
> 
> conn Rock-Roll-ccc-rrr
>         leftsubnet=10.xxx.ccc.0/24
>         rightsubnet=10.64.rrr.0/24
> 
> # strongswan.conf - strongSwan configuration file
> #
> # Refer to the strongswan.conf(5) manpage for details
> #
> # Configuration changes should be made in the included files
> 
> charon {
>         load_modular = yes
>         plugins {
>                 include strongswan.d/charon/*.conf
>         }
> #       charon.install_routes=0
>         charon.retransmit_base = 2
>         charon.retransmit_timeout = 5
>         charon.retransmit_tries = 7
> }
> 
> include strongswan.d/*.conf
> 
> ipsec statusall
> Status of IKE charon daemon (strongSwan 5.3.5, Linux 4.4.0-171-generic, i686):
>   uptime: 13 seconds, since Oct 08 12:07:47 2020
>   malloc: sbrk 1310720, mmap 0, used 305896, free 1004824
>   worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, 
> scheduled: 3
>   loaded plugins: charon test-vectors aes rc2 sha1 sha2 md4 md5 random nonce 
> x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey 
> pem openssl fips-prf gmp agent xcbc hmac gcm attr kernel-netlink resolve 
> socket-default connmark farp stroke updown eap-identity eap-sim eap-sim-pcsc 
> eap-aka eap-aka-3gpp2 eap-simaka-pseudonym eap-simaka-reauth eap-md5 eap-gtc 
> eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap eap-tnc 
> xauth-generic xauth-eap xauth-pam xauth-noauth tnc-tnccs tnccs-20 tnccs-11 
> tnccs-dynamic dhcp lookip error-notify certexpire led addrblock unity
> Listening IP addresses:
>   192.168.eee.fff
>   67.nnn.nnn.nnn
>   10.xxx.ddd.www
>   10.xxx.ddd.ttt
>   10.xxx.bbb.www
>   10.xxx.bbb.ttt
>   10.xxx.eee.www
>   10.xxx.eee.ttt
>   192.168.ppp.ttt
>   10.xxx.aaa.uuu
>   66.lll.mmm.vvv
> Connections:
> Rock-Roll-aaa-qqq:  67.nnn.nnn.nnn...64.mmm.mmm.mmm  IKEv2, dpddelay=30s
> Rock-Roll-aaa-qqq:   local:  [67.nnn.nnn.nnn] uses pre-shared key 
> authentication
> Rock-Roll-aaa-qqq:   remote: [64.mmm.mmm.mmm] uses pre-shared key 
> authentication
> Rock-Roll-aaa-qqq:   child:  10.xxx.aaa.0/24 === 10.64.qqq.0/24 TUNNEL, 
> dpdaction=restart
> Rock-Roll-bbb-qqq:   child:  10.xxx.bbb.0/24 === 10.64.qqq.0/24 TUNNEL, 
> dpdaction=restart
> Rock-Roll-ccc-qqq:   child:  10.xxx.ccc.0/24 === 10.64.qqq.0/24 TUNNEL, 
> dpdaction=restart
> Rock-Roll-aaa-rrr:   child:  10.xxx.aaa.0/24 === 10.64.rrr.0/24 TUNNEL, 
> dpdaction=restart
> Rock-Roll-bbb-rrr:   child:  10.xxx.bbb.0/24 === 10.64.rrr.0/24 TUNNEL, 
> dpdaction=restart
> Rock-Roll-ccc-rrr:   child:  10.xxx.ccc.0/24 === 10.64.rrr.0/24 TUNNEL, 
> dpdaction=restart
> Security Associations (1 up, 0 connecting):
> Rock-Roll-aaa-qqq[1]: ESTABLISHED 13 seconds ago, 
> 67.nnn.nnn.nnn[67.nnn.nnn.nnn]...64.mmm.mmm.mmm[64.mmm.mmm.mmm]
> 

Re: [strongSwan] updown - server which disconnects one roadworrior when another connects

[Noel Kuntze]

Hi,

Sorry for the mistake.

Kind regards

Noel

Am 28.09.20 um 11:52 schrieb Tobias Brunner:
> Hi,
> 
>> up-client is called for each combination of remote ts and local ts 
>> components, as is down-client, when a CHILD_sa is established/destroyed.
>> So when a CHILD_SA is rekeyed, both are called in the order the CHILD_SAs 
>> are negotiated/destroyed.
> 
> The updown script is *not* called for IKE or CHILD_SA rekeyings.
> However, if reauthentication is used with IKEv2, the script will be
> called as new CHILD_SA are created.  A down-event will be called either
> before or after the reauthentication and the corresponding up-event
> depending on whether make-before-break reauthentication is used by the
> client, see [1].
> 
> By the way, the VICI interface does expose the ike/child-rekey events.
> But reauthentication is not handled differently.
> 
> Regards,
> Tobias
> 
> [1] https://wiki.strongswan.org/projects/strongswan/wiki/ExpiryRekey
> 



signature.asc
Description: OpenPGP digital signature

Re: [strongSwan] updown - server which disconnects one roadworrior when another connects

[Noel Kuntze]

Hi,

> Is that behavior controllable somehow, configured somewhere
> - would you know?
> Or it's the user/admin which must take care of this
> 'issue/phenomena' via the 'updown' script and the script alone?

Not controllable, you need to deal with it in the script.

Kind regards

Noel

Am 28.09.20 um 11:35 schrieb lejeczek:
> 
> 
> On 28/09/2020 10:05, Noel Kuntze wrote:
>> Hi,
>>
>> up-client is called for each combination of remote ts and local ts 
>> components, as is down-client, when a CHILD_sa is established/destroyed.
>> So when a CHILD_SA is rekeyed, both are called in the order the CHILD_SAs 
>> are negotiated/destroyed.
>>
>> Kind regards
>>
>> Noel
>>
>> Am 28.09.20 um 10:58 schrieb lejeczek:
>>> Hi guys.
>>>
>>> I have a strongswan with 'updown' which controls tunnels,
>>> routes, etc. I took the script from doc examples and built
>>> upon it.
>>> What is perplexing totally to me is, that the scripts shows
>>> that when one roadwarrior is connected and another one is
>>> connecting then the server invokes 'down-client' which then
>>> removes - as the updown dictates - tunnel of already
>>> connected roadwarrior.
>>> Here is a snippet of the log from 'updown' script, a moment
>>> when new roadwarrior connects:
>>> ...
>>> RUN
>>> vti113 - down-client
>>> Mon Sep 28 09:47:20 BST 2020
>>> ip tunnel del vti113
>>> ip route del 10.3.1.12/32 dev vti113
>>>
>>> RUN
>>> vti114 - up-client
>>> Mon Sep 28 09:47:21 BST 2020
>>> ip tunnel add vti114 local X.X.X.X remote Z.Z.Z.Z mode vti
>>> key 11
>>> ip link set vti114 mtu 1400 up
>>> ...
>>>
>>> 'updown' script has nothing to do with that, right?
>>> Why would server do that 'down-client'?
>>>
>>> many thanks, L.
>>>
> Thanks man for explaining that.
> Is that behavior controllable somehow, configured somewhere
> - would you know?
> Or it's the user/admin which must take care of this
> 'issue/phenomena' via the 'updown' script and the script alone?
> 
> many thanks, L.
> 



signature.asc
Description: OpenPGP digital signature

Re: [strongSwan] Route not working as expcted

[Noel Kuntze]

Hello,

Please provide all information as listed on the HelpRequests[1] page.

Kind regards

Noel

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

Am 27.09.20 um 16:36 schrieb strongswan@it-beheer.eu:
> Hello everyone,
> 
> I am having problems getting an ip range over a tunnel that i want. And don't 
> see what i do wrong...
> 
> I have setup the following where MS1 and V1 are under my control:
> windows host (MS1) -> vpn server (/V1/)   =tunnel=   vpn server (V2) -> win 
> hosts ( x.64.48.41 (MS2) and x.64.51.113 (MS3) )
> conn A
>  left=
>  right=
>  leftsubnet=10.33.3.0/24
>  rightsubnet=x.64.48.0/21
>  and the rest
> 
> The tunnel comes up fine. I can send a ping to x.64.48.41 from MS1. But fail 
> to ping MS3.
> I bring down the tunnel and start a ping MS3. Bring up the tunnel and ping 
> reply is fine. But now i fail to ping MS2. Doing the same reverses everything 
> al the time. So it seams the the first ping that comes trough gets to be 
> working. And gets to add the route.
> 
> table 220 gives me:
> x.64.48.0/21 via  dev ens18 proto static src 10.33.3.254
> x.64.48.41 via  dev ens18 proto static src 10.33.3.254
> and got ping to MS2 working.
> 
> I tried adding
> x.64.51.113 via  dev ens18 proto static src 10.33.3.254
> 
> But the packages don't seem to be send in to the tunnel. They do arrive at V1 
> from MS1. I don't get why Strongswan add 2 routes to the table even the ip is 
> included in the subnet.
> 
> -
> I tried a setup with two other setup's but also never both pings working:
> 
> rightsubnet=x.64.48.41/32,x64.51.113/32 But with the same result.
> 
> 
> and:
> 
> Conn A
>  rightsubnet=x.64.48.41/32
> 
> Conn BA
> also=A
> rightsubnet=x.64.51.113/32
> 
> 
> Hope someone can make me a bit smarter and explain and solve my problem. 
> Tried to keep al the ip's as real as possible so hope all is clear enough.
> 
> Kind rgds, Ben
> 



signature.asc
Description: OpenPGP digital signature

Re: [strongSwan] updown - server which disconnects one roadworrior when another connects

[Noel Kuntze]

Hi,

up-client is called for each combination of remote ts and local ts components, 
as is down-client, when a CHILD_sa is established/destroyed.
So when a CHILD_SA is rekeyed, both are called in the order the CHILD_SAs are 
negotiated/destroyed.

Kind regards

Noel

Am 28.09.20 um 10:58 schrieb lejeczek:
> Hi guys.
> 
> I have a strongswan with 'updown' which controls tunnels,
> routes, etc. I took the script from doc examples and built
> upon it.
> What is perplexing totally to me is, that the scripts shows
> that when one roadwarrior is connected and another one is
> connecting then the server invokes 'down-client' which then
> removes - as the updown dictates - tunnel of already
> connected roadwarrior.
> Here is a snippet of the log from 'updown' script, a moment
> when new roadwarrior connects:
> ...
> RUN
> vti113 - down-client
> Mon Sep 28 09:47:20 BST 2020
> ip tunnel del vti113
> ip route del 10.3.1.12/32 dev vti113
> 
> RUN
> vti114 - up-client
> Mon Sep 28 09:47:21 BST 2020
> ip tunnel add vti114 local X.X.X.X remote Z.Z.Z.Z mode vti
> key 11
> ip link set vti114 mtu 1400 up
> ...
> 
> 'updown' script has nothing to do with that, right?
> Why would server do that 'down-client'?
> 
> many thanks, L.
> 



signature.asc
Description: OpenPGP digital signature

Re: [strongSwan] Connection to AWS-VPC

[Noel Kuntze]

I did it a couple of times. Not that that specific piece of information would 
help you in any way.

Am 15.09.20 um 15:40 schrieb Dominik Reusser:
> The security group settings should be fine. It does work with open swan with 
> the same credentials.
> 
> Am Di., 15. Sept. 2020 um 08:47 Uhr schrieb Aurélien Vallée 
> mailto:vallee.aurel...@gmail.com>>:
> 
> We do use strongswan successfully as VPN to connect to AWS gateways in a 
> VPC.
> Did you check the security groups to make sure strongswan traffic can 
> pass through?
> 
> On Tue, Sep 15, 2020 at 2:20 PM Dominik Reusser  > wrote:
> 
> Has anyone successfully connected to AWS VPC? My connection is 
> established and ICMP-Pakets are routed through the AWS cloud. However, UDP 
> and TCP packets - while being sent towards the AWS server (from tcp dump on 
> the client side) - do not appear in the logs of the VPC.
> 
> With a corresponding setup with OpenSwan I get a working connection. 
> However, I would prefer to use strong Swan.
> 
> If you have successfully connected to AWS VPC, could you please share 
> your configuration files?
> 
> Thanks
> Kind regards
> Dominik
> 
> 
> 
> -- 
> Aurélien Vallée
> Phone +33 9 77 19 85 61
> 



signature.asc
Description: OpenPGP digital signature

Re: [strongSwan] IKE Phase 1 and Phase 2 parameters

[Noel Kuntze]

For completeness, if you were to configure an AH CHILD_SA, you'd use the "ah=" 
parameter instead of the "esp=" parameter.

Kind regards

Noel

Am 06.09.20 um 00:16 schrieb Leroy Tennison:
> Thank you, I appreciate the reply.
> 
> Harriscomputer
> 
> *Leroy Tennison
> *Network Information/Cyber Security Specialist
> E: le...@datavoiceint.com
> P:
> 
>   
> 
> 
>   
> 
> 2220 Bush Dr
> McKinney, Texas
> 75070
> www.datavoiceint.com  
> 
> This message has been sent on behalf of a company that is part of the Harris 
> Operating Group of Constellation Software Inc.
> 
> If you prefer not to be contacted by Harris Operating Group please notify us 
> .
> 
>  
> 
> This message is intended exclusively for the individual or entity to which it 
> is addressed. This communication may contain information that is proprietary, 
> privileged or confidential or otherwise legally exempt from disclosure. If 
> you are not the named addressee, you are not authorized to read, print, 
> retain, copy or disseminate this message or any part of it. If you have 
> received this message in error, please notify the sender immediately by 
> e-mail and delete all copies of the message.
> 
>  
> 
> --
> *From:* Andreas Steffen 
> *Sent:* Saturday, September 5, 2020 12:30 AM
> *To:* Leroy Tennison ; users@lists.strongswan.org 
> 
> *Subject:* [EXTERNAL] Re: [strongSwan] IKE Phase 1 and Phase 2 parameters
>  
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> 
> Hi Leroy,
> 
> the Phase 2 crypto proposals can be set with the "esp=" parameter in
> ipsec.conf.
> 
> Best regards
> 
> Andreas
> 
> On 05.09.20 00:31, Leroy Tennison wrote:
>> I either don't know what to look for on the web or am having trouble
>> finding settings for IKE phase 1 and phase 2 negotiation.  It seems that
>> the '"ike=" ipsec.conf parameter specifies settings for Phase 1 but I'm
>> not finding anything for Phase 2 for Strongswan.  Other IPSec
>> implementations seem to use phase2alg for this but Strongswan either
>> doesn't have this setting or it has another name for it.
>>
>> Can someone explain (or send me a link to an explanation) of how these
>> are decided in Strongswan?  Thanks for your help.
>>
>> Harriscomputer
>>
>> *Leroy Tennison
>> *Network Information/Cyber Security Specialist
>> E: le...@datavoiceint.com
>> P:
>>
>> 2220 Bush Dr
>> McKinney, Texas
>> 75070
>> https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.datavoiceint.com=E,1,4UegVHmZyooZscjXFpQOeRrNuVWVHl9MV7N5mK2EefQfyvSV6JrqnT_DqdvqHsq2iqVi4U1AB4Yc-bMVDKQCrmpLzAXFqpP43vPM4-vzJA,,=1
>>   
>>
>> This message has been sent on behalf of a company that is part of the
>> Harris Operating Group of Constellation Software Inc.
>>
>> If you prefer not to be contacted by Harris Operating Group please
>> notify us 
>> .
>>
>>
>>
>> This message is intended exclusively for the individual or entity to
>> which it is addressed. This communication may contain information that
>> is proprietary, privileged or confidential or otherwise legally exempt
>> from disclosure. If you are not the named addressee, you are not
>> authorized to read, print, retain, copy or disseminate this message or
>> any part of it. If you have received this message in error, please
>> notify the sender immediately by e-mail and delete all copies of the
>> message.
>>
> ==
> Andreas Steffen andreas.stef...@strongswan.org
> strongSwan - the Open Source VPN Solution!  
> 

Re: [strongSwan] weird cisco behaviour - how to work around?

[Noel Kuntze]

Hi,

By deauthenticating existing clients, you do in fact prevent simultaneous use 
of the same ID. :)

Kind regards

Noel

Am 12.06.20 um 12:21 schrieb Volodymyr Litovka:
> Hi Noel,
> 
> under "prevention" I meant disabling of simultaneous use of same id.
> 
> And thanks for pointing to charon.retransmit* parameters - yes, this is what 
> I was looking for.
> 
> Thank you!
> 
> On 12.06.2020 12:59, Noel Kuntze wrote:
>> Hi Volodymyr,
>>
>> I disagree. That "prevention" enables a better user experience during 
>> network or software failures on the client side, as described before and by 
>> yourself already.
>>
>> In IKEv2, every packet exchange is used for dead peer detection, so you need 
>> to change the IKEv2 timeout in strongswan.conf to tweak that.
>>
>> Kind regards
>>
>> Noel
>>
>> Am 12.06.20 um 11:55 schrieb Volodymyr Litovka:
>>> Hi Noel,
>>>
>>> may be it sounds a bit strange :-) but this is kind of 
>>> errors/misconfigurations prevention. Existing connection must not be 
>>> dropped if somebody else trying to connect with same credentials.
>>>
>>> ===
>>>
>>> In such configuration, it leads to another problem - if a client's Internet 
>>> connection flapped, it will be able to reconnect in ~3m because of 
>>> described earlier behaviour.
>>>
>>> While it's possible to manage conn.dpd_delay, is it possible to manage 
>>> delay pattern of DPD messages and/or their qty? If admin (e.g. me) knows 
>>> and understands what he is doing, this can solve an issue, shortening time 
>>> to detection of dead peer.
>>>
>>> Thanks.
>>>
>>> On 12.06.2020 11:18, Noel Kuntze wrote:
>>>> Hi Volodymyr,
>>>>
>>>> I'd configure your RADIUS server to use DAE and allow new connections, 
>>>> thus simply disconnecting existing clients with the same account when a 
>>>> client authenticates as that account.
>>>>
>>>> Kind regards
>>>>
>>>> Noel
>>>>
>>>> Am 11.06.20 um 22:41 schrieb Volodymyr Litovka:
>>>>> Colleagues, hi,
>>>>>
>>>>> as always, the most magic things happens with those, who claims the best 
>>>>> security solutions in the Universe :-\
>>>>>
>>>>> Faced a very strange behaviour when using IPSec between Strongswan 
>>>>> (server) and Cisco (client). On Cisco I'm using the tunnel configuration:
>>>>>
>>>>>> interface Tunnel1
>>>>>>  ip address negotiated
>>>>>>  ip mtu 1400
>>>>>>  ip tcp adjust-mss 1360
>>>>>>  tunnel source GigabitEthernet1
>>>>>>  tunnel mode ipsec ipv4
>>>>>>  tunnel destination y.y.y.y
>>>>>>  tunnel protection ipsec profile NEW-tun
>>>>>>
>>>>> and things are ok to some degree: when I shutting down the tunnel, Cisco 
>>>>> IOS clears all states inside (both ike sa and ike session), while sending 
>>>>> to the peer only request to close Child SA:
>>>>>
>>>>>> Jun 11 21:48:58 newton charon-systemd[3040]: received DELETE for ESP 
>>>>>> CHILD_SA with SPI fb709251
>>>>> causing Strongswan to delete Child SA but to keep IKE SA active:
>>>>>
>>>>>> root@newton:/etc/strongswan.d# swanctl --list-sas
>>>>>> ikev2-eap-mschapv2: #1, ESTABLISHED, IKEv2, 865999d54ba73a0c_i 
>>>>>> 63a1831a36835a29_r*
>>>>>>   local  'newton.sq' @ y.y.y.y[4500]
>>>>>>   remote '192.168.1.161' @ x.x.x.x[4500] EAP: 'doka...@gmail.com' 
>>>>>> [172.29.24.2]
>>>>>>   AES_GCM_16-256/PRF_HMAC_SHA2_256/MODP_2048
>>>>>>   established 246s ago, rekeying in 10188s
>>>>>>   active:  IKE_DPD
>>>>>>
>>>>> I'm using Radius to authenticate users and manage simultaneous use of 
>>>>> sessions with same id. Thus, the problem with this issue is that 
>>>>> Strongswan don't send Accounting-Stop record until DPD will find it 
>>>>> finally closed and during this period connection looks as active, 
>>>>> preventing reconnection.
>>>>>
>>>>> Even after I reduced dpd_delay to 10s, full cleanup happens in about 3 
>>>>> minutes after Child SA was closed:
>>>>>
>>>>>> 21

Re: [strongSwan] weird cisco behaviour - how to work around?

[Noel Kuntze]

Hi Volodymyr,

I disagree. That "prevention" enables a better user experience during network 
or software failures on the client side, as described before and by yourself 
already.

In IKEv2, every packet exchange is used for dead peer detection, so you need to 
change the IKEv2 timeout in strongswan.conf to tweak that.

Kind regards

Noel

Am 12.06.20 um 11:55 schrieb Volodymyr Litovka:
> Hi Noel,
> 
> may be it sounds a bit strange :-) but this is kind of 
> errors/misconfigurations prevention. Existing connection must not be dropped 
> if somebody else trying to connect with same credentials.
> 
> ===
> 
> In such configuration, it leads to another problem - if a client's Internet 
> connection flapped, it will be able to reconnect in ~3m because of described 
> earlier behaviour.
> 
> While it's possible to manage conn.dpd_delay, is it possible to manage delay 
> pattern of DPD messages and/or their qty? If admin (e.g. me) knows and 
> understands what he is doing, this can solve an issue, shortening time to 
> detection of dead peer.
> 
> Thanks.
> 
> On 12.06.2020 11:18, Noel Kuntze wrote:
>> Hi Volodymyr,
>>
>> I'd configure your RADIUS server to use DAE and allow new connections, thus 
>> simply disconnecting existing clients with the same account when a client 
>> authenticates as that account.
>>
>> Kind regards
>>
>> Noel
>>
>> Am 11.06.20 um 22:41 schrieb Volodymyr Litovka:
>>> Colleagues, hi,
>>>
>>> as always, the most magic things happens with those, who claims the best 
>>> security solutions in the Universe :-\
>>>
>>> Faced a very strange behaviour when using IPSec between Strongswan (server) 
>>> and Cisco (client). On Cisco I'm using the tunnel configuration:
>>>
>>>> interface Tunnel1
>>>>  ip address negotiated
>>>>  ip mtu 1400
>>>>  ip tcp adjust-mss 1360
>>>>  tunnel source GigabitEthernet1
>>>>  tunnel mode ipsec ipv4
>>>>  tunnel destination y.y.y.y
>>>>  tunnel protection ipsec profile NEW-tun
>>>>
>>> and things are ok to some degree: when I shutting down the tunnel, Cisco 
>>> IOS clears all states inside (both ike sa and ike session), while sending 
>>> to the peer only request to close Child SA:
>>>
>>>> Jun 11 21:48:58 newton charon-systemd[3040]: received DELETE for ESP 
>>>> CHILD_SA with SPI fb709251
>>> causing Strongswan to delete Child SA but to keep IKE SA active:
>>>
>>>> root@newton:/etc/strongswan.d# swanctl --list-sas
>>>> ikev2-eap-mschapv2: #1, ESTABLISHED, IKEv2, 865999d54ba73a0c_i 
>>>> 63a1831a36835a29_r*
>>>>   local  'newton.sq' @ y.y.y.y[4500]
>>>>   remote '192.168.1.161' @ x.x.x.x[4500] EAP: 'doka...@gmail.com' 
>>>> [172.29.24.2]
>>>>   AES_GCM_16-256/PRF_HMAC_SHA2_256/MODP_2048
>>>>   established 246s ago, rekeying in 10188s
>>>>   active:  IKE_DPD
>>>>
>>> I'm using Radius to authenticate users and manage simultaneous use of 
>>> sessions with same id. Thus, the problem with this issue is that Strongswan 
>>> don't send Accounting-Stop record until DPD will find it finally closed and 
>>> during this period connection looks as active, preventing reconnection.
>>>
>>> Even after I reduced dpd_delay to 10s, full cleanup happens in about 3 
>>> minutes after Child SA was closed:
>>>
>>>> 21:48:58 newton: 09[IKE]  received DELETE for ESP 
>>>> CHILD_SA with SPI fb709251
>>>> 21:48:58 newton: 09[IKE]  closing CHILD_SA carlo{1} 
>>>> with SPIs cfd87900_i [...]
>>>> 21:48:58 newton: 09[IKE]  sending DELETE for ESP 
>>>> CHILD_SA with SPI cfd87900
>>>> 21:48:58 newton: 09[CHD]  CHILD_SA carlo{1} state 
>>>> change: INSTALLED => DELETING
>>>> 21:48:58 newton: 09[IKE]  CHILD_SA closed
>>>> 21:48:58 newton: 09[CHD]  CHILD_SA carlo{1} state 
>>>> change: DELETING => DESTROYING
>>>> 21:49:22 newton: 16[IKE]  sending DPD request
>>>> 21:49:22 newton: 16[IKE]  queueing IKE_DPD task
>>>> 21:49:22 newton: 16[IKE]    activating IKE_DPD task
>>>> 21:49:26 newton: 05[IKE]  retransmit 1 of request 
>>>> with message ID 8
>>>> 21:49:34 newton: 09[IKE]  retransmit 2 of request 
>>>> with message ID 8
>>>> 21:49:47 newton: 12[IKE]  retransmit 3 of request 
>>>> with message ID 8
>>>> 21:50:10 newton: 05[IKE]  retransmit 4 of request 
>

Re: [strongSwan] weird cisco behaviour - how to work around?

[Noel Kuntze]

Hi Volodymyr,

I'd configure your RADIUS server to use DAE and allow new connections, thus 
simply disconnecting existing clients with the same account when a client 
authenticates as that account.

Kind regards

Noel

Am 11.06.20 um 22:41 schrieb Volodymyr Litovka:
> Colleagues, hi,
> 
> as always, the most magic things happens with those, who claims the best 
> security solutions in the Universe :-\
> 
> Faced a very strange behaviour when using IPSec between Strongswan (server) 
> and Cisco (client). On Cisco I'm using the tunnel configuration:
> 
>> interface Tunnel1
>>  ip address negotiated
>>  ip mtu 1400
>>  ip tcp adjust-mss 1360
>>  tunnel source GigabitEthernet1
>>  tunnel mode ipsec ipv4
>>  tunnel destination y.y.y.y
>>  tunnel protection ipsec profile NEW-tun
>>
> and things are ok to some degree: when I shutting down the tunnel, Cisco IOS 
> clears all states inside (both ike sa and ike session), while sending to the 
> peer only request to close Child SA:
> 
>> Jun 11 21:48:58 newton charon-systemd[3040]: received DELETE for ESP 
>> CHILD_SA with SPI fb709251
> causing Strongswan to delete Child SA but to keep IKE SA active:
> 
>> root@newton:/etc/strongswan.d# swanctl --list-sas
>> ikev2-eap-mschapv2: #1, ESTABLISHED, IKEv2, 865999d54ba73a0c_i 
>> 63a1831a36835a29_r*
>>   local  'newton.sq' @ y.y.y.y[4500]
>>   remote '192.168.1.161' @ x.x.x.x[4500] EAP: 'doka...@gmail.com' 
>> [172.29.24.2]
>>   AES_GCM_16-256/PRF_HMAC_SHA2_256/MODP_2048
>>   established 246s ago, rekeying in 10188s
>>   active:  IKE_DPD
>>
> I'm using Radius to authenticate users and manage simultaneous use of 
> sessions with same id. Thus, the problem with this issue is that Strongswan 
> don't send Accounting-Stop record until DPD will find it finally closed and 
> during this period connection looks as active, preventing reconnection.
> 
> Even after I reduced dpd_delay to 10s, full cleanup happens in about 3 
> minutes after Child SA was closed:
> 
>> 21:48:58 newton: 09[IKE]  received DELETE for ESP 
>> CHILD_SA with SPI fb709251
>> 21:48:58 newton: 09[IKE]  closing CHILD_SA carlo{1} 
>> with SPIs cfd87900_i [...]
>> 21:48:58 newton: 09[IKE]  sending DELETE for ESP 
>> CHILD_SA with SPI cfd87900
>> 21:48:58 newton: 09[CHD]  CHILD_SA carlo{1} state 
>> change: INSTALLED => DELETING
>> 21:48:58 newton: 09[IKE]  CHILD_SA closed
>> 21:48:58 newton: 09[CHD]  CHILD_SA carlo{1} state 
>> change: DELETING => DESTROYING
>> 21:49:22 newton: 16[IKE]  sending DPD request
>> 21:49:22 newton: 16[IKE]  queueing IKE_DPD task
>> 21:49:22 newton: 16[IKE]    activating IKE_DPD task
>> 21:49:26 newton: 05[IKE]  retransmit 1 of request with 
>> message ID 8
>> 21:49:34 newton: 09[IKE]  retransmit 2 of request with 
>> message ID 8
>> 21:49:47 newton: 12[IKE]  retransmit 3 of request with 
>> message ID 8
>> 21:50:10 newton: 05[IKE]  retransmit 4 of request with 
>> message ID 8
>> 21:50:52 newton: 07[IKE]  retransmit 5 of request with 
>> message ID 8
>> 21:52:07 newton: 06[IKE]  giving up after 5 retransmits
>> 21:52:07 newton: 06[CFG]  sending RADIUS 
>> Accounting-Request to server '127.0.0.1'
>> 21:52:08 newton: 06[CFG]  received RADIUS 
>> Accounting-Response from server '127.0.0.1'
>> 21:52:08 newton: 06[IKE]  IKE_SA ikev2-eap-mschapv2[1] 
>> state change: ESTABLISHED => DESTROYING
> So, the question is: are there ways to be more aggressive in detecting closed 
> connections, e.g. :
> - is it possible to destroy IKE SA if there are no Child SAs anymore?
> - or, may be, change parameters of DPD messages retransmission? - qty of 
> messages, fixed delay between messages, smth else?
> 
> Any other ways to work around this problem?
> 
> Thank you.
> 
> --
> Volodymyr Litovka
>   "Vision without Execution is Hallucination." -- Thomas Edison
> 



signature.asc
Description: OpenPGP digital signature

Re: [strongSwan] Unable to connect to client - no matching peer config found

[Noel Kuntze]

Hi Liong,

Okay, for that you need an IP in 192.168.40.32/30 on a local interface.

Kind regards

Noel

Am 10.06.20 um 07:38 schrieb Liong Kok Foo:
> Hi Noel,
> 
> Awesome! Thanks for the guidance.
> 
> [root@uatvpngateway strongswan]# strongswan status
> Security Associations (1 up, 0 connecting):
>  net-net[3]: ESTABLISHED 8 minutes ago, 
> 10.15.66.10[192.168.40.34]...1.2.3.4[1.2.3.4]
>  net-net{3}:  INSTALLED, TUNNEL, reqid 2, ESP SPIs: ce157096_i ca47d3e2_o
>  net-net{3}:   192.168.40.32/30 === 192.168.118.0/24
> 
> The final thing I did was change leftsubnet=192.168.40.32/30.
> 
> Now I need to get the route working which is another problem to be solved.
> 
> Cheers!
> 
> On 10/6/2020 12:48 pm, Noel Kuntze wrote:
>> Hi Liong,
>>
>> I'm pretty sure you can solve this little puzzle by yourself. The values are 
>> already there.
>>
>> Kind regards
>>
>> Noel
>>
>> Am 10.06.20 um 06:20 schrieb Liong Kok Foo:
>>> Hi Noel,
>>>
>>> The client side is not allowing connection from my side as it is not using 
>>> the IP they want. I have removed the alias and changed the 
>>> leftid=192.168.40.34
>>>
>>> Jun 10 12:03:59 uatvpngateway charon[20916]: 06[IKE] maximum IKE_SA 
>>> lifetime 86298s
>>> Jun 10 12:03:59 uatvpngateway charon[20916]: 06[CFG] looking for a child 
>>> config for 192.168.40.32/30 === 192.168.118.0/24
>>> Jun 10 12:03:59 uatvpngateway charon[20916]: 06[CFG] proposing traffic 
>>> selectors for us:
>>> Jun 10 12:03:59 uatvpngateway charon[20916]: 06[CFG]  10.15.66.0/24
>>> Jun 10 12:03:59 uatvpngateway charon[20916]: 06[CFG] proposing traffic 
>>> selectors for other:
>>> Jun 10 12:03:59 uatvpngateway charon[20916]: 06[CFG]  192.168.118.0/24
>>> Jun 10 12:03:59 uatvpngateway charon[20916]: 06[IKE] traffic selectors 
>>> 192.168.40.32/30 === 192.168.118.0/24 unacceptable
>>> Jun 10 12:03:59 uatvpngateway charon[20916]: 06[IKE] failed to establish 
>>> CHILD_SA, keeping IKE_SA
>>> Jun 10 12:03:59 uatvpngateway charon[20916]: 06[ENC] generating IKE_AUTH 
>>> response 1 [ IDr AUTH N(AUTH_LFT) N(TS_UNACCEPT) ]
>>> Jun 10 12:03:59 uatvpngateway charon[20916]: 06[NET] sending packet: from 
>>> 10.15.66.10[500] to 1.2.3.4[500] (144 bytes)
>>>
>>> Any idea? Or is this not possible to be done?
>>>
>>>
>>> *Liong Kok Foo*
>>> Team Lead, IT Infra
>>>
>>> REVENUE GROUP OF COMPANIES
>>> Email : liong.kok@revenue.com.my <mailto:liong.kok....@revenue.com.my>
>>> TEL : +60 3-9212 0505  (ext 1004)
>>> FAX : +60 3-6242 8785
>>> ADD : Wisma Revenue Group, No. 12, Jalan Udang Harimau 2, Kepong Business 
>>> Park, 51200. Kuala Lumpur
>>> WEB : www.revenue.com.my <http://www.revenue.com.my/> 
>>> (http://www.revenue.com.my/)
>>> WEB : www.revpay.com.my <http://www.revpay.com.my/> 
>>> (http://www.revpay.com.my/)
>>>
>>> On 10/6/2020 11:31 am, Noel Kuntze wrote:
>>>> Hello Liong,
>>>>
>>>>>> You see, the client have their VPN setup such that we MUST connect to 
>>>>>> them from IP 192.168.40.34. Our network IP is 10.15.66.0/24. This is the 
>>>>>> reason why we had to use Strongswan and NAT to do this.
>>>>>>
>>>> Your host is behind NAT, so the other peer won't ever see it. Also, that 
>>>> IP address is probably not routed to you by the next hop router. That's 
>>>> why you don't get any response for packets sent from the IP address 
>>>> 192.168.40.34.
>>>>
>>>> You need to set leftid to the address. That will probably do it.
>>>>
>>>>>> Jun 10 11:02:32 uatvpngateway charon[20200]: 13[IKE] no IKE config found 
>>>>>> for 10.15.66.10...1.2.3.4, sending NO_PROPOSAL_CHOSEN
>>>> Yes, of course, because you sent left to 192.168.40.34, instead of the 
>>>> correct value of 10.15.66.10. Stop hitting yourself.
>>>>
>>>>> I created an alias eth0:0 192.168.40.34 for this server.
>>>> That doesn't help you at all. Also, aliases are deprecated for > 20 years 
>>>> already. Aliases are a crutch for using ifconfig with several IP addresses 
>>>> per interface.
>>>> ifconfig and route are deprecated for more than 20 years already, too.
>>>>
>>>> Kind regards
>>>>
>>>> Noel
>>>>
>>>> Am 10.06.20 um 05:12 schrieb Liong K

Re: [strongSwan] Unable to connect to client - no matching peer config found

[Noel Kuntze]

Hi Liong,

I'm pretty sure you can solve this little puzzle by yourself. The values are 
already there.

Kind regards

Noel

Am 10.06.20 um 06:20 schrieb Liong Kok Foo:
> Hi Noel,
> 
> The client side is not allowing connection from my side as it is not using 
> the IP they want. I have removed the alias and changed the 
> leftid=192.168.40.34
> 
> Jun 10 12:03:59 uatvpngateway charon[20916]: 06[IKE] maximum IKE_SA lifetime 
> 86298s
> Jun 10 12:03:59 uatvpngateway charon[20916]: 06[CFG] looking for a child 
> config for 192.168.40.32/30 === 192.168.118.0/24
> Jun 10 12:03:59 uatvpngateway charon[20916]: 06[CFG] proposing traffic 
> selectors for us:
> Jun 10 12:03:59 uatvpngateway charon[20916]: 06[CFG]  10.15.66.0/24
> Jun 10 12:03:59 uatvpngateway charon[20916]: 06[CFG] proposing traffic 
> selectors for other:
> Jun 10 12:03:59 uatvpngateway charon[20916]: 06[CFG]  192.168.118.0/24
> Jun 10 12:03:59 uatvpngateway charon[20916]: 06[IKE] traffic selectors 
> 192.168.40.32/30 === 192.168.118.0/24 unacceptable
> Jun 10 12:03:59 uatvpngateway charon[20916]: 06[IKE] failed to establish 
> CHILD_SA, keeping IKE_SA
> Jun 10 12:03:59 uatvpngateway charon[20916]: 06[ENC] generating IKE_AUTH 
> response 1 [ IDr AUTH N(AUTH_LFT) N(TS_UNACCEPT) ]
> Jun 10 12:03:59 uatvpngateway charon[20916]: 06[NET] sending packet: from 
> 10.15.66.10[500] to 1.2.3.4[500] (144 bytes)
> 
> Any idea? Or is this not possible to be done?
> 
> 
> *Liong Kok Foo*
> Team Lead, IT Infra
> 
> REVENUE GROUP OF COMPANIES
> Email : liong.kok@revenue.com.my <mailto:liong.kok@revenue.com.my>
> TEL : +60 3-9212 0505  (ext 1004)
> FAX : +60 3-6242 8785
> ADD : Wisma Revenue Group, No. 12, Jalan Udang Harimau 2, Kepong Business 
> Park, 51200. Kuala Lumpur
> WEB : www.revenue.com.my <http://www.revenue.com.my/> 
> (http://www.revenue.com.my/)
> WEB : www.revpay.com.my <http://www.revpay.com.my/> 
> (http://www.revpay.com.my/)
> 
> On 10/6/2020 11:31 am, Noel Kuntze wrote:
>> Hello Liong,
>>
>>>> You see, the client have their VPN setup such that we MUST connect to them 
>>>> from IP 192.168.40.34. Our network IP is 10.15.66.0/24. This is the reason 
>>>> why we had to use Strongswan and NAT to do this.
>>>>
>> Your host is behind NAT, so the other peer won't ever see it. Also, that IP 
>> address is probably not routed to you by the next hop router. That's why you 
>> don't get any response for packets sent from the IP address 192.168.40.34.
>>
>> You need to set leftid to the address. That will probably do it.
>>
>>>> Jun 10 11:02:32 uatvpngateway charon[20200]: 13[IKE] no IKE config found 
>>>> for 10.15.66.10...1.2.3.4, sending NO_PROPOSAL_CHOSEN
>> Yes, of course, because you sent left to 192.168.40.34, instead of the 
>> correct value of 10.15.66.10. Stop hitting yourself.
>>
>>> I created an alias eth0:0 192.168.40.34 for this server.
>> That doesn't help you at all. Also, aliases are deprecated for > 20 years 
>> already. Aliases are a crutch for using ifconfig with several IP addresses 
>> per interface.
>> ifconfig and route are deprecated for more than 20 years already, too.
>>
>> Kind regards
>>
>> Noel
>>
>> Am 10.06.20 um 05:12 schrieb Liong Kok Foo:
>>> Hi Noel,
>>>
>>> Thanks changed the rightid and it is going somewhere.
>>>
>>> However, I am stuck in another error.
>>>
>>> Jun 10 11:02:19 uatvpngateway charon[20200]: 11[IKE] retransmit 3 of 
>>> request with message ID 0
>>> Jun 10 11:02:19 uatvpngateway charon[20200]: 11[NET] sending packet: from 
>>> 192.168.40.34[500] to 1.2.3.4[500] (464 bytes)
>>> Jun 10 11:02:32 uatvpngateway charon[20200]: 13[NET] received packet: from 
>>> 1.2.3.4[500] to 10.15.66.10[500] (384 bytes)
>>> Jun 10 11:02:32 uatvpngateway charon[20200]: 13[ENC] parsed IKE_SA_INIT 
>>> request 0 [ SA KE No N(FRAG_SUP) ]
>>> Jun 10 11:02:32 uatvpngateway charon[20200]: 13[CFG] looking for an IKEv2 
>>> config for 10.15.66.10...1.2.3.4
>>> Jun 10 11:02:32 uatvpngateway charon[20200]: 13[IKE] no IKE config found 
>>> for 10.15.66.10...1.2.3.4, sending NO_PROPOSAL_CHOSEN
>>> Jun 10 11:02:32 uatvpngateway charon[20200]: 13[ENC] generating IKE_SA_INIT 
>>> response 0 [ N(NO_PROP) ]
>>> Jun 10 11:02:32 uatvpngateway charon[20200]: 13[NET] sending packet: from 
>>> 10.15.66.10[500] to 1.2.3.4[500] (36 bytes)
>>> Jun 10 11:02:43 uatvpngateway charon[20200]: 14[IKE] retransmit 4 of 
>>> request with message ID 0
>>> Jun 10 11:02:43 uatvpngate

Re: [strongSwan] Unable to connect to client - no matching peer config found

[Noel Kuntze]

Hi Liong,

> Jun  9 17:14:32 uatvpngateway charon: 07[CFG] looking for peer configs 
> matching 10.15.66.10[%any]...1.2.3.4[1.2.3.4]

rightid=1.2.3.4

Kind regards

Noel

Am 09.06.20 um 11:27 schrieb Liong Kok Foo:
> Hi,
> 
> I am new to strongswan and have not had much experience setting up VPN 
> connection.
> 
> I need to setup a new VPN connection to a client but just cannot seems to get 
> it working.
> 
> Here are the information provided by client:
> 
> IKEv2 (Phase 1) Proposal 
> Available for ping (Yes/No)   No
> IKE Mode (Aggressive/Main)Main
> IKE Authentication method Pre-shared key
> IKE Pre-shared keyxx
> IKE Group Group 14
> IKE Encryption    AES-256
> IKE AuthenticationSHA2-256
> IKE Lifetime (seconds)86400
> Life Time (KB)86400
>  IPsec (Phase 2) Proposal 
> IPsec Group   Group 14
> IPsec ProtocolESP
> IPsec Encryption  AES-256
> IPsec Authentication  SHA2-256
> IPsec Lifetime (seconds)  3600
> Life Time (KB)28800
> Enable Perfect Forward SecrecyYes
> PFS / DH-groupYes/Gp-14
> Encapsulation ModeTunnel
> IP addresses carried in tunnel (Private IP address, IP range assigned by 
> client) Crypto ACL
> Source (Encryption Domain)192.168.40.33/30(DR)
> 192.168.40.34/30(UAT)
> Port  Any
> VPN DPD always enabledEnabled
> To disable monitoring ICMP echo requests (or pings) à by right to determine 
> if a VPN tunnel is up however for this case it’s dropping the VPN 
> connections.Disabled
> To disable a proxy-ID negotiation, it is used during phase 2 of Internet Key 
> Exchange (IKE) Virtual Private Network (VPN) negotiations.   Disabled
> NAT traversal (TCP4500)   Disabled
> 
> 
> Here is my configuration file:
> 
> IPsec.conf
> 
> # ipsec.conf - strongSwan IPsec configuration file
> 
> # basic configuration
> 
> config setup
> 
> conn %default
>     ikelifetime=1440m
>     keylife=60m
>     rekeymargin=3m
>     keyingtries=1
>     authby=secret
>     keyexchange=ikev2
>     mobike=no
> 
> conn net-net
>     left=10.15.66.10
>     leftsubnet=10.15.66.0/24
>     leftid=@me
>     leftfirewall=yes
>     right=1.2.3.4 (client public IP changed)
>     rightsubnet=192.168.118.0/24
>     rightid=@client
>     ike=aes256-sha2_256-modp2048!
>     esp=aes256-sha2_256-modp2048!
>     auto=start
> 
> 
> ipsec.secrets:
> 
> # ipsec.secrets - strongSwan IPsec secrets file
> @me @client : PSK "xx"
> 
> 
> Here is a part of the message log:
> 
> Jun  9 17:14:32 uatvpngateway charon: 06[NET] received packet: from 
> 1.2.3.4[500] to 10.15.66.10[500] (384 bytes)
> Jun  9 17:14:32 uatvpngateway charon: 06[ENC] parsed IKE_SA_INIT request 0 [ 
> SA KE No N(FRAG_SUP) ]
> Jun  9 17:14:32 uatvpngateway charon: 06[IKE] 1.2.3.4 is initiating an IKE_SA
> Jun  9 17:14:32 uatvpngateway charon: 06[CFG] selected proposal: 
> IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
> Jun  9 17:14:32 uatvpngateway charon: 06[ENC] generating IKE_SA_INIT response 
> 0 [ SA KE No N(FRAG_SUP) N(MULT_AUTH) ]
> Jun  9 17:14:32 uatvpngateway charon: 06[NET] sending packet: from 
> 10.15.66.10[500] to 1.2.3.4[500] (392 bytes)
> Jun  9 17:14:32 uatvpngateway charon: 07[NET] received packet: from 
> 1.2.3.4[500] to 10.15.66.10[500] (448 bytes)
> Jun  9 17:14:32 uatvpngateway charon: 07[ENC] parsed IKE_AUTH request 1 [ IDi 
> N(INIT_CONTACT) AUTH N(MSG_ID_SYN_SUP) SA TSi TSr ]
> Jun  9 17:14:32 uatvpngateway charon: 07[CFG] looking for peer configs 
> matching 10.15.66.10[%any]...1.2.3.4[1.2.3.4]
> Jun  9 17:14:32 uatvpngateway charon: 07[CFG] no matching peer config found
> Jun  9 17:14:32 uatvpngateway charon: 07[ENC] generating IKE_AUTH response 1 
> [ N(AUTH_FAILED) ]
> Jun  9 17:14:32 uatvpngateway charon: 07[NET] sending packet: from 
> 10.15.66.10[500] to 1.2.3.4[500] (80 bytes)
> 
> Would appreciate if anyone can help to provide guidance on getting this 
> working.
> 
> Thanks
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>Virus-free. www.avast.com 
> 
> 
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>



signature.asc
Description: OpenPGP digital signature

Re: [strongSwan] [HELP]:swanctl in context of strongswan

[Noel Kuntze]

Hi Kuna,

>  I want to check above network ping but the ping is blocked at  my internal 
> network so I can not 
> ping to node b.

That statement is pretty ambiguous and without corresponding explanation. Keep 
in mind that your own interpretation of your collected data is flawed because 
you yourself don't understand it (copy & paste > prose). If you want help, 
please provide all data/logs as shown on the HelpRequests[1] page.

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

Kind regards

Noel

Am 23.05.20 um 21:22 schrieb Kunal Chauhan:
> Hi Team,
> 
> 1. I want to use check traffic and tunnenling  concept to connect to node b 
> as shown below:
>  
>  node A(IPv6 machine) -- >NAT64(IPv6 to IPv4 conversion) >>> 
> tunnelnode   b(security gateway.Ipv4 machine) 
>  I want to check above network ping but the ping is blocked at  my internal 
> network so I can not 
> ping to node b.
>    please guide for the same as I can understand the concept better.
> 2. is the use of swanctl will be useful here
> 
> 
> 
> Thanks
> Kuna
> 
> -- 
> 



signature.asc
Description: OpenPGP digital signature

Re: [strongSwan] Effect of xfrm_acq_expires mismatch retransmit timeout?

[Noel Kuntze]

Hello Micahel,

xfrm_acq_expires is the time the kernel holds an acquire event before it drops 
it.
The kernel only sends one acquire event for a policy, not several ones. When it 
receives packets with a matching policy but without a corresponding IPsec SA,
it checks if it already sent an acquire event. If an acquire event was not 
reacted to within $xfrm_acq_expires seconds, that acquire event is forgotten 
about by the kernel.
So basically xfrm_acq_expires is the minimum time between two acquire events 
for a policy.

Kind regards

Noel

Am 29.05.20 um 15:41 schrieb Michael Schwartzkopff:
> Hi,
> 
> what would be the effect if the charon.plugins.xfrm_acq_expires does not
> fit the charon.retransmit_* options?
> 
> I tried to understand what the xfrm_acq_expires exactrly does, but the
> docs in the internet are very limited. As far as I understood, it sets a
> timer when the SPI times out. Every time, traffic is seens for a SPI,
> the timer is reset (?)
> 
> If the total retransmit timeout is larger than the xfrm_acq_expired,
> could it happen that the SPI timed out before charon times out and the
> encrypted communication breaks?
> 
> Or is there any good timing diagram for encrytped traffic though the kernel?
> 
> 
> Mit freundlichen Grüßen,
> 



signature.asc
Description: OpenPGP digital signature

Re: [strongSwan] Duplicate IKE_SA?

[Noel Kuntze]

Hello Michael,

It might be that both sides use auto=route or auto=start and initiated in 
parallel and uniqueids=no is set, so duplicate SAs are not deleted.

That is pure speculation though. ;)

Kind regards

Noel

Am 31.05.20 um 09:44 schrieb Michael Schwartzkopff:
> Hi,
> 
> 
> we have a central gateway and several remote gateways. The setup should
> be very simple, all fixed IP Addresses, PSK authentication.
> 
> When I look to the status of the connections, I see that EVERY IKE_SA
> exists duplicate. The expiry times are far from being close to the timeout.
> 
> 
> Sample output of statusall:
> 
> Connections:
>    VPN_a:  192.0.2.128...192.0.2.1  IKEv2, dpddelay=10s
>    VPN_a:   local:  [192.0.2.1] uses pre-shared key authentication
>    VPN_a:   remote: [192.0.2.128] uses pre-shared key authentication
>    VPN_a:   child:  dynamic === 192.0.2.128/32 TUNNEL, dpdaction=hold
> 
> Security Associations (4 up, 0 connecting):
>    VPN_a[502011]: ESTABLISHED 47 minutes ago,
> 192.0.2.128[192.0.2.128]...192.0.2.1[192.0.2.1]
>    VPN_a[502011]: IKEv2 SPIs: 93fea54e631018b3_i e19e477bde676b42_r*,
> rekeying disabled
>    VPN_a[502011]: IKE proposal:
> AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
>    VPN_a{502324}:  INSTALLED, TUNNEL, reqid 3, ESP SPIs: c2a96e2c_i
> c36e31d1_o
>    VPN_a{502324}:  AES_CBC_256/HMAC_SHA2_256_128, 3182 bytes_i (74 pkts,
> 15s ago), 7655 bytes_o (110 pkts, 0s ago), rekeying disabled
>    VPN_a{502324}:   192.0.2.128/32 === 192.0.2.1/32
>    VPN_a[502009]: ESTABLISHED 66 minutes ago,
> 192.0.2.128[192.0.2.128]...192.0.2.1[192.0.2.1]
>    VPN_a[502009]: IKEv2 SPIs: 40ab1a098c160549_i ded33f2f40286969_r*,
> rekeying disabled
>    VPN_a[502009]: IKE proposal:
> AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
>    VPN_a{502323}:  INSTALLED, TUNNEL, reqid 3, ESP SPIs: c2b8ec27_i
> cbabcc83_o
>    VPN_a{502323}:  AES_CBC_256/HMAC_SHA2_256_128, 2226 bytes_i (51 pkts,
> 15s ago), 4681 bytes_o (72 pkts, 0s ago), rekeying disabled
>    VPN_a{502323}:   192.0.2.128/32 === 192.0.2.1/32
> 
> 
> Any ideas, why the gateways set up two IKE SAs?
> 
> 
> Mit freundlichen Grüßen,
> 



signature.asc
Description: OpenPGP digital signature

Re: [strongSwan] Storngswan and freeradius

[Noel Kuntze]

Hello,

Yes, you can do that. Looks like you still need to install the package 
(whichever that is) for the eap-radius plugin.
See the FAQ[1].

[1] https://wiki.strongswan.org/projects/strongswan/wiki/FAQ#Plugin-is-missing

Kind regards

Noel

Am 27.05.20 um 10:17 schrieb Клеусов Владимир Сергеевич:
> Hi,
> I design such a system:
> 1) strongSwan
> 2) freeradius (TTTLS/PAP). Connected to LDAP
> 3) microtik
> 
> Theoretically, it is possible to configure the configuration like this ? 
> Strongswan connects to freeRADIUS and authorizes users. Users from LDAP.
> 
> Attempts to configure via eap-radius lead to an error
> 
> 
> charon[42383]: 14[CFG] selected peer config "IKEv1"
> charon[42383]: 14[CFG] no XAuth method found for ‘radius'
> 
> In ipsec.conf
>   eap_identity=%identity
> 
> keyexchange=ikev1
> leftauth=psk
> rightauth=psk
> rightauth2=xauth-radius
> auto=add
> 
> In /etc/strongswan.d/charon/eap-radius.conf
> eap-radius {
> accounting = yes
> load = yes
> 
> servers {
> freeradius {
> 
> address = 10.15.12.43
> auth_port = 1812
> acct_port = 1813
> sockets = 10
> secret = blabla
> nas_identifier = vpn
> }
> }
> }
>  In cat /etc/strongswan.d/charon/xauth-eap.conf
> xauth-eap {
> backend = radius
> load = yes
> }
> 
> In 
> 



signature.asc
Description: OpenPGP digital signature

Re: [strongSwan] Multiple connections with the same policy

[Noel Kuntze]

Hi,

You can't have duplicate/identical policies. At all. There's generally 
something broken in your setup.

Kind regards

Noel

Am 28.05.20 um 18:56 schrieb korsar...@gmail.com:
> Hello,
> I have 2 endpoints with 2 IP addresses on the each side. I established 2 
> connections between them with the same policy to make failover with main and 
> backup link.
> Incoming traffic goes through one link but outgoing through the another one. 
> This should not be a problem but it is
> 
> It looks like this:
> conn1: #197, ESTABLISHED, IKEv2, 482f9b76fa33814b_i 28d890a8f075c0dc_r*
>   local  '1.1.1.1' @ 1.1.1.1[500]
>   remote '2.2.2.2' @ 2.2.2.2[500]
>   AES_CBC-256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024
>   established 7s ago
>   to-varus: #19, reqid 2, INSTALLED, TUNNEL, ESP:AES_CBC-256/HMAC_SHA2_256_128
>     installed 7s ago
>     in  c4837279,   1068 bytes,    17 packets, 0s ago
>     out 50b38cfc,   0 bytes,   0 packets, 7s ago    <---
>     local  10.8.1.2/32
>     remote 172.20.1.233/32
> conn2: #196, ESTABLISHED, IKEv2, cbecb3fd1afb94d8_i* 8148f7fab37e9e6c_r
>   local  '3.3.3.3' @ 3.3.3.3[4500]
>   remote '4.4.4.4' @ 4.4.4.4[4500]
>   AES_CBC-256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024
>   established 45s ago
>   to-varus2: #18, reqid 2, INSTALLED, TUNNEL, 
> ESP:AES_CBC-256/HMAC_SHA2_256_128
>     installed 45s ago
>     in  c4afe7b8,  0 bytes, 0 packets    <-
>     out 50b38cf6,   1776 bytes,    28 packets, 0s ago
>     local  10.8.1.2/32
>     remote 172.20.1.233/32
> 
> Is there any way to set up priority for SA or make them work together?
> 
> 
> ipsec.conf:
> 
> config setup
> conn %default
> conn conn1
>   left=1.1.1.1
>   leftsubnet=10.8.1.2/32
>   right=2.2.2.2
>   rightsubnet=172.20.1.233/32
> conn conn2
>   left=3.3.3.3
>   leftsubnet=10.8.1.2/32
>   right=4.4.4.4
>   rightsubnet=172.20.1.233/32



signature.asc
Description: OpenPGP digital signature

Re: [strongSwan] Help to diagnose connection problem with Cisco ASA5585X

[Noel Kuntze]

Hi,

The other peer has some problem with it. Review its logs.
> received NO_PROPOSAL_CHOSEN notify, no CHILD_SA built

Kind regards

Noel

Am 09.05.20 um 16:20 schrieb Jim Geurts:
> Hi,
> 
> I'm new to the world of strongswan and vpns in general, so I apologize if 
> this is answered elsewhere. I inherited a strongSwan box running Linux 
> strongSwan U5.7.2/K4.14.177-139.253.amzn2.x86_64. The other end is a Cisco 
> ASA5585X. The connection was up and running a few days ago, but I've been 
> trying to get auto=route working (it was previously auto=start) and that 
> caused the tunnel to go up/down a couple times. Now the tunnel will not 
> establish a connection. To me, it seems like it's the phase 2 establishment 
> that is failing, but I'm curious if someone could help clear up what is going 
> on or which part is failing?
> 
> My understanding (waiting for verification) is that the configured settings 
> for the tunnel from the cisco side are:
> 
> Phase 1
>   Encryption algorithm: AES-256
>   Hash algorithm: SHA-512
>   DH Group: 14
>   Lifetime: 28800 (seconds)
> 
> Phase 2:
>   Mode: IKE V2 Tunnel
>   ESP Encryption algorithm: AES-256
>   ESP Hash algorithm: SHA-512
>   PFS: DH Group 14
>   Lifetime: 3600 (seconds)
> 
> I have the following ipsec.conf file for the tunnel:
> 
> config setup
>         # strictcrlpolicy=yes
>         # uniqueids = no
>         charondebug="ike 2, knl 2,esp 2, cfg 2, chd 2, lib 2, net 2"
> 
> conn %default
>         ikelifetime=480m
>         keylife=60m
>         rekeymargin=3m
>         keyingtries=1
>         keyexchange=ikev1
>         authby=secret
> 
> conn FOO
>         leftid=205.251.242.103
>         left=172.30.101.187
>         leftsubnet=205.251.242.103/32 
>         leftupdown=/tmp/vpn/firewall-rules.sh
>         right=176.32.98.166
>         rightsubnet=104.40.92.107/32 
>         ike=aes256-sha512-modp2048!
>         keyexchange=ikev2
>         esp=aes256-sha2_512-modp2048!
>         rekeymargin=9m
>         type=tunnel
>         compress=no
>         authby=secret
>         auto=route
>         keyingtries=%forever
>         forceencaps=yes
>         mobike=no
> 
> 
> ipsec statusall gives the following:
> 
> Status of IKE charon daemon (strongSwan 5.7.2, Linux 
> 4.14.177-139.253.amzn2.x86_64, x86_64):
>   uptime: 19 hours, since May 08 18:56:20 2020
>   malloc: sbrk 1884160, mmap 0, used 828960, free 1055200
>   worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, 
> scheduled: 0
>   loaded plugins: charon pkcs11 tpm aesni aes des rc2 sha2 sha1 md4 md5 mgf1 
> random nonce x509 revocation constraints acert pubkey pkcs1 pkcs7 pkcs8 
> pkcs12 pgp dnskey sshkey pem openssl gcrypt fips-prf gmp curve25519 chapoly 
> xcbc cmac hmac ctr ccm gcm curl attr kernel-netlink resolve socket-default 
> farp stroke vici updown eap-identity eap-sim eap-aka eap-aka-3gpp 
> eap-aka-3gpp2 eap-md5 eap-gtc eap-mschapv2 eap-dynamic eap-radius eap-tls 
> eap-ttls eap-peap xauth-generic xauth-eap xauth-pam xauth-noauth dhcp led 
> duplicheck unity counters
> Listening IP addresses:
>   172.30.101.187
> Connections:
>          FOO:  172.30.101.187...176.32.98.166  IKEv2
>          FOO:   local:  [205.251.242.103] uses pre-shared key authentication
>          FOO:   remote: [176.32.98.166] uses pre-shared key authentication
>          FOO:   child:  205.251.242.103/32  === 
> 104.40.92.107/32  TUNNEL
> Routed Connections:
>          FOO{1}:  ROUTED, TUNNEL, reqid 1
>          FOO{1}:   205.251.242.103/32  === 
> 104.40.92.107/32 
> Security Associations (0 up, 0 connecting):
>   none
> 
> 
> Sending traffic to 104.40.92.107 does not bring the tunnel up. If I try to 
> bring the tunnel up manually using ipsec up FOO, I get the following:
> 
> initiating IKE_SA FOO[1] to 176.32.98.166
> generating 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) ]
> sending packet: from 172.30.101.187[500] to 176.32.98.166[500] (464 bytes)
> received packet: from 176.32.98.166[500] to 172.30.101.187[500] (599 bytes)
> parsed IKE_SA_INIT response 0 [ SA KE No V V N(NATD_S_IP) N(NATD_D_IP) 
> CERTREQ N(FRAG_SUP) V ]
> received Cisco Delete Reason vendor ID
> received Cisco Copyright (c) 2009 vendor ID
> received FRAGMENTATION vendor ID
> selected proposal: 
> IKE:AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_2048
> local host is behind NAT, sending keep alives
> received 1 cert requests for an unknown ca
> authentication of '205.251.242.103' (myself) with pre-shared key
> establishing CHILD_SA FOO{2}
> generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr AUTH SA TSi TSr 
> N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
> sending packet: from 172.30.101.187[4500] to 176.32.98.166[4500] (304 bytes)
> received packet: from 176.32.98.166[4500] to 172.30.101.187[4500] (208 bytes)
> parsed 

Re: [strongSwan] ISAKMP packet ignored with right=%any ?

[Noel Kuntze]

Hi,

Make sure the iptables chain policies are all set to Accept.
Flushing the ruleset does not reset the chain policies.

Kind regards

Noel

Am 28.04.20 um 15:18 schrieb Philippe Marrot:
> Not firewall issue, I tried without and other static site to ste tunnels are 
> working.



signature.asc
Description: OpenPGP digital signature

Re: [strongSwan] NAT-T, SNAT/DNAT and TCP checksum incorrect on peer VPN gateway (site-to-site)

[Noel Kuntze]

Hello Narendra,

There is no specific, dedicated tool, other than just trying large packets by, 
for example, using the -s flag for ping.

No, MTU problems can not cause TCP checksum errors. That is likely a false 
lead. It might be caused by RX and TX checksum offloading though. Check the 
sizes first though and specifically, just getting google.com. That page is 
quite small and should work fine. Loading a picture from Instagram probably 
fails. PMTUD didn't work with Instagram's CDN last time I checked.

Kind regards

Noel

Am 21.04.20 um 22:39 schrieb Narendra Joshi:
> Noel Kuntze  writes:
> 
>> Hi,
>> Those are likely all false leads.  It's likely to be an MTU/MSS problem, 
>> which is described on the wiki[1]. 
> Thank you very much for the quick response. I will follow the instructions 
> provided in the wiki.
> Is there a tool that I can use to verify that it is MTU because of which 
> there is a failure to connect? I noticed incorrect values for the TCP 
> checksum on the host in the peer's subnet using `tcpdump`. Moreover, ICMP 
> seems to be working without any packet loss at all. I can imagine that ICMP 
> packets won't be large enough to reach the MTU value (probably). Can MTU 
> cause TCP checksum failures? My networking knowledge is definitely limited 
> here.
> 
>> Kind regards
>> Noel
>> [1] 
>> https://wiki.strongswan.org/projects/strongswan/wiki/ForwardingAndSplitTunneling#MTUMSS-issues
>> Am 21.04.20 um 20:38 schrieb Narendra Joshi:
>>> Hi,  I have setup an IPSec gateway on a virtual instance in a VPC using a 
>>> cloud provider. The cloud provider has Elastic IPs that aren't attached to 
>>> any network interface on the virtual instance so strongSwan uses NAT-T. 
>>> Also I need to do SNAT/DNAT for mapping my side of the subnet that is 
>>> advertised to my VPN peer.   I have found that this setup causes very 
>>> frequent TCP checksum failures. There are so frequent that an HTTP request 
>>> fails ~50% of the time because TCP connect times out.  It would be great if 
>>> anyone who has faced something similar before can help me understand what 
>>> is happening and how it can be avoided. Here is an image of the setup I 
>>> have:   Best regards, 
>>
> 



signature.asc
Description: OpenPGP digital signature

Re: [strongSwan] NAT-T, SNAT/DNAT and TCP checksum incorrect on peer VPN gateway (site-to-site)

[Noel Kuntze]

Hi,

Those are likely all false leads.
It's likely to be an MTU/MSS problem, which is described on the wiki[1].

Kind regards

Noel

[1] 
https://wiki.strongswan.org/projects/strongswan/wiki/ForwardingAndSplitTunneling#MTUMSS-issues

Am 21.04.20 um 20:38 schrieb Narendra Joshi:
> Hi,
> 
> I have setup an IPSec gateway on a virtual instance in a VPC using a cloud 
> provider. The cloud provider has Elastic IPs that aren't attached to any 
> network interface on the virtual instance so strongSwan uses NAT-T. Also I 
> need to do SNAT/DNAT for mapping my side of the subnet that is advertised to 
> my VPN peer.
> 
> I have found that this setup causes very frequent TCP checksum failures. 
> There are so frequent that an HTTP request fails ~50% of the time because TCP 
> connect times out.  It would be great if anyone who has faced something 
> similar before can help me understand what is happening and how it can be 
> avoided.
> 
> Here is an image of the setup I have:
> 
> 
> Best regards,



signature.asc
Description: OpenPGP digital signature

Re: [strongSwan] ikeV1 tunnel established but packets are not routed. V2 works.

[Noel Kuntze]

Hi,

Nope, that's wrong.
You need to enumerate all combinations of subnets so you have a specific 
CHILD_SA for each pair.
IKEv1 can only handle one subnet per side in a single CHILD_SA.

Kind regards

Noel

Am 07.04.20 um 16:38 schrieb Makarand Pradhan:
> Good morning All,
> 
> Following up on the issue. We need to manually add the route for ikev1. 
> 
> Would very much appreciate any pointers. Am kind of stuck on ikev1.
> 
> Kind rgds,
> Makarand Pradhan
> Senior Software Engineer.
> iS5 Communications Inc.
> 5895 Ambler Dr,
> Mississauga, Ontario
> L4W 5B7
> Main Line: +1-844-520-0588 Ext. 129
> Direct Line: +1-289-724-2296
> Cell: +1-226-501-5666
> Fax:+1-289-401-5206
> Email: makarandprad...@is5com.com
> Website: www.iS5Com.com
> 
>  
> Confidentiality Notice: 
> This message is intended only for the named recipients. This message may 
> contain information that is confidential and/or exempt from disclosure under 
> applicable law. Any dissemination or copying of this message by anyone other 
> than a named recipient is strictly prohibited. If you are not a named 
> recipient or an employee or agent responsible for delivering this message to 
> a named recipient, please notify us immediately, and permanently destroy this 
> message and any copies you may have. Warning: Email may not be secure unless 
> properly encrypted.
> 
> -Original Message-
> From: Makarand Pradhan 
> Sent: March 20, 2020 1:50 PM
> To: Noel Kuntze ; 
> users@lists.strongswan.org
> Subject: RE: [strongSwan] ikeV1 tunnel established but packets are not 
> routed. V2 works.
> 
> Tx for the clarification. All information per the wiki is attached.
> 
> Kind rgds,
> Makarand Pradhan
> Senior Software Engineer.
> iS5 Communications Inc.
> 5895 Ambler Dr,
> Mississauga, Ontario
> L4W 5B7
> Main Line: +1-844-520-0588 Ext. 129
> Direct Line: +1-289-724-2296
> Cell: +1-226-501-5666
> Fax:+1-289-401-5206
> Email: makarandprad...@is5com.com
> Website: www.iS5Com.com
> 
>  
> Confidentiality Notice:
> This message is intended only for the named recipients. This message may 
> contain information that is confidential and/or exempt from disclosure under 
> applicable law. Any dissemination or copying of this message by anyone other 
> than a named recipient is strictly prohibited. If you are not a named 
> recipient or an employee or agent responsible for delivering this message to 
> a named recipient, please notify us immediately, and permanently destroy this 
> message and any copies you may have. Warning: Email may not be secure unless 
> properly encrypted.
> 
> -Original Message-
> From: Noel Kuntze 
> Sent: March 20, 2020 1:21 PM
> To: Makarand Pradhan ; users@lists.strongswan.org
> Subject: Re: [strongSwan] ikeV1 tunnel established but packets are not 
> routed. V2 works.
> 
> Please send all the data I asked for.
> And especially the output of `ipsec statusall`.
> strongSwan installs all required routes by default.
> 
> Am 20.03.20 um 18:17 schrieb Makarand Pradhan:
>> One quick question before I send all the logs. Maybe the tunnel is working 
>> as expected. Can you pl go through the set up below to confirm that, there 
>> is indeed an issue here:
>>
>> Scenario:
>> PC1 - Router1 - Router2 - Tunnel - Router3 - Router4 - PC2
>> PC1 IP: 10.10.9.3, Network: 10.10.9.0/24
>> PC2 IP: 192.168.9.3, Network: 192.168.9.0/24
>> Tunnel: Raptor2(91.0.0.3) to (91.0.0.2)Raptor3 Tunnel is established:
>>>>   m1[6]: ESTABLISHED 13 minutes ago, 
>>>> 91.0.0.3[91.0.0.3]...91.0.0.2[91.0.0.2]
>>>>   m1{7}:   10.10.9.0/24 === 192.168.9.0/24
>> Routing table on Router 2:
>> root@t1024rdb:~# ip ro
>> 91.0.0.0/8 dev fm1-mac1.0555  proto kernel  scope link  src 91.0.0.3
>> 192.168.9.0/24 via 91.0.0.2 dev fm1-mac1.0555
>>
>> With this the packets are encrypted as they pass the tunnel:
>> 22:41:05.941919 IP 10.10.9.3 > 192.168.9.3: ICMP echo request, id 
>> 1278, seq 3, length 64
>> 22:41:05.942123 IP 91.0.0.3 > 91.0.0.2: ESP(spi=0xc1442109,seq=0x3), 
>> length 132
>> 22:41:05.943440 IP 91.0.0.2 > 91.0.0.3: ESP(spi=0xc468b8a2,seq=0x3), 
>> length 132
>> 22:41:05.943612 IP 192.168.9.3 > 10.10.9.3: ICMP echo reply, id 1278, 
>> seq 3, length 64
>>
>> Question:
>> Do I need to have the route "192.168.9.0/24 via 91.0.0.2" when I am running 
>> v1? 
>> With this route, the packets get encrypted.
>>
>> If this is the desired behaviour then we do not have an issue.
>>
>> Would appreciate if someone can confirm if v1 needs the route addition. V2 
>&g

Re: [strongSwan] Strongswan client support for the XAUTH_PASSCODE attribute

[Noel Kuntze]

Hi,

AFAIR it doesn't/can't. I'm not sure though. You'd have to check.

Kind regards

Noel

Am 01.04.20 um 19:26 schrieb mnli...@frimail.net:
> Hi,
> 
> But the NetworkManager plugin could prompt for a passcode couldn't it?
> 
> Best regards,
> 
> /Mikael
> 
> On 2020-04-01 19:19, Noel Kuntze wrote:
>> Hi,
>>
>> Yw.
>>
>> There's also no support for dynamic prompting for EAP credentials.
>> I envisioned to implement that using VICI some time later. It'd be the 
>> natural choice.
>> Switching to IKEv2 won't solve the problem for you right now.
>>
>> Kind regards
>>
>> Noel
>>
>> Am 01.04.20 um 19:10 schrieb Mikael Nordstrom:
>>> OK,
>>>
>>> Thanks anyway for the quick reply.
>>>
>>> The Juniper has IKEv2 support and the RSA SecurID box has a built-in radius 
>>> server
>>> so maybe that is the way to go with this.
>>>
>>> Thanks again,
>>>
>>> /Mikael
>>>
>>> On 2020-04-01 18:30, Noel Kuntze wrote:
>>>> Hi,
>>>>
>>>> There's just no frontend to ask dynamically for such credentials yet. 
>>>> You'd need to implement that, then you can dynamically prompt for the 
>>>> passcode (after hooking up X_CODE the same way as X_USER is). Other than 
>>>> that, there are no provisions for X_CODE or anything else. The code base 
>>>> wouldn't be extended particularly for X_CODE because IKEv1 is deprecated.
>>>>
>>>> Kind regards
>>>>
>>>> Noel
>>>>
>>>> Am 01.04.20 um 18:22 schrieb MN Lists:
>>>>> Hi,
>>>>>
>>>>> This is my first message to the list so sorry in advance if the answer is 
>>>>> obvious or well-known.
>>>>> Also, sorry if my terminology is messed up, hopefully you will understand 
>>>>> my issue.
>>>>>
>>>>> I have a Juniper ScreenOS gateway that does IKEv1 VPNs with RSA and then 
>>>>> XAuth authentication
>>>>> towards an RSA SecurID box. SecurID is an MFA implementation with 
>>>>> hardware tokens that display
>>>>> a new 6-digit number every 60 seconds.
>>>>>
>>>>> Clients can connect to it from Mac OS X with a client called NCP Secure 
>>>>> Entry and from Windows
>>>>> with the Shrewsoft client. In the past vpnc on Linux was working but as 
>>>>> it has not been developed
>>>>> since a long time and doesn't support newer algorithms, I'm looking for 
>>>>> an alternative and
>>>>> Strongswan looks promising.
>>>>>
>>>>> So far I have been able to get IKE phase1 up but it fails on XAuth. It 
>>>>> looks as if the gateway
>>>>> is sending a request for X_USER and X_CODE but charon is responding with 
>>>>> just X_USER. Here is
>>>>> a log excerpt:
>>>>>
>>>>> apr 01 17:48:08 phoenix charon-debug[21177]: 02[IKE] authentication of 
>>>>> 'gw.example.com' with RSA_EMSA_PKCS1_NULL successful
>>>>> apr 01 17:48:08 phoenix charon-debug[21177]: 02[IKE] activating new tasks
>>>>> apr 01 17:48:08 phoenix charon-debug[21177]: 02[IKE] nothing to initiate
>>>>> apr 01 17:48:11 phoenix charon-debug[21177]: 07[NET] received packet: 
>>>>> from 212.112.174.86[4500] to 172.20.33.34[4500] (92 bytes)
>>>>> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE] next IV for MID 
>>>>> 3123281050 => 16 bytes @ 0x7f0304001ed0
>>>>> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE]0: 51 2C 54 DC D7 
>>>>> 31 2D 5F 5D 84 00 10 81 42 88 2B  Q,T..1-_]B.+
>>>>> apr 01 17:48:11 phoenix charon-debug[21177]: 07[ENC] parsed TRANSACTION 
>>>>> request 3123281050 [ HASH CPRQ(X_TYPE X_USER X_CODE) ]
>>>>> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE] Hash => 32 bytes @ 
>>>>> 0x7f03040026b0
>>>>> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE]0: 87 1C CA 53 F3 
>>>>> 1A 81 40 E3 68 E8 78 EA 1C CF CE  ...S...@.h.x
>>>>> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE]   16: B3 53 17 C6 8C 
>>>>> 1B E7 F3 CA DD 50 DC F7 60 97 DD  .SP..`..
>>>>> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE] next IV for MID 
>>>>> 3123281050 => 16 bytes @ 0x7f02f8005600
>>>>> apr 01 17:48:11 phoenix charon-debug[211

Re: [strongSwan] Strongswan client support for the XAUTH_PASSCODE attribute

[Noel Kuntze]

Hi,

Yw.

There's also no support for dynamic prompting for EAP credentials.
I envisioned to implement that using VICI some time later. It'd be the natural 
choice.
Switching to IKEv2 won't solve the problem for you right now.

Kind regards

Noel

Am 01.04.20 um 19:10 schrieb Mikael Nordstrom:
> OK,
> 
> Thanks anyway for the quick reply.
> 
> The Juniper has IKEv2 support and the RSA SecurID box has a built-in radius 
> server
> so maybe that is the way to go with this.
> 
> Thanks again,
> 
> /Mikael
> 
> On 2020-04-01 18:30, Noel Kuntze wrote:
>> Hi,
>>
>> There's just no frontend to ask dynamically for such credentials yet. You'd 
>> need to implement that, then you can dynamically prompt for the passcode 
>> (after hooking up X_CODE the same way as X_USER is). Other than that, there 
>> are no provisions for X_CODE or anything else. The code base wouldn't be 
>> extended particularly for X_CODE because IKEv1 is deprecated.
>>
>> Kind regards
>>
>> Noel
>>
>> Am 01.04.20 um 18:22 schrieb MN Lists:
>>> Hi,
>>>
>>> This is my first message to the list so sorry in advance if the answer is 
>>> obvious or well-known.
>>> Also, sorry if my terminology is messed up, hopefully you will understand 
>>> my issue.
>>>
>>> I have a Juniper ScreenOS gateway that does IKEv1 VPNs with RSA and then 
>>> XAuth authentication
>>> towards an RSA SecurID box. SecurID is an MFA implementation with hardware 
>>> tokens that display
>>> a new 6-digit number every 60 seconds.
>>>
>>> Clients can connect to it from Mac OS X with a client called NCP Secure 
>>> Entry and from Windows
>>> with the Shrewsoft client. In the past vpnc on Linux was working but as it 
>>> has not been developed
>>> since a long time and doesn't support newer algorithms, I'm looking for an 
>>> alternative and
>>> Strongswan looks promising.
>>>
>>> So far I have been able to get IKE phase1 up but it fails on XAuth. It 
>>> looks as if the gateway
>>> is sending a request for X_USER and X_CODE but charon is responding with 
>>> just X_USER. Here is
>>> a log excerpt:
>>>
>>> apr 01 17:48:08 phoenix charon-debug[21177]: 02[IKE] authentication of 
>>> 'gw.example.com' with RSA_EMSA_PKCS1_NULL successful
>>> apr 01 17:48:08 phoenix charon-debug[21177]: 02[IKE] activating new tasks
>>> apr 01 17:48:08 phoenix charon-debug[21177]: 02[IKE] nothing to initiate
>>> apr 01 17:48:11 phoenix charon-debug[21177]: 07[NET] received packet: from 
>>> 212.112.174.86[4500] to 172.20.33.34[4500] (92 bytes)
>>> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE] next IV for MID 
>>> 3123281050 => 16 bytes @ 0x7f0304001ed0
>>> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE]0: 51 2C 54 DC D7 
>>> 31 2D 5F 5D 84 00 10 81 42 88 2B  Q,T..1-_]B.+
>>> apr 01 17:48:11 phoenix charon-debug[21177]: 07[ENC] parsed TRANSACTION 
>>> request 3123281050 [ HASH CPRQ(X_TYPE X_USER X_CODE) ]
>>> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE] Hash => 32 bytes @ 
>>> 0x7f03040026b0
>>> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE]0: 87 1C CA 53 F3 
>>> 1A 81 40 E3 68 E8 78 EA 1C CF CE  ...S...@.h.x
>>> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE]   16: B3 53 17 C6 8C 
>>> 1B E7 F3 CA DD 50 DC F7 60 97 DD  .SP..`..
>>> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE] next IV for MID 
>>> 3123281050 => 16 bytes @ 0x7f02f8005600
>>> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE]0: 33 C2 3E 9C 64 
>>> 14 4C 87 85 C2 1B 26 45 84 2D FF  3.>.d.L
>>> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE] Hash => 32 bytes @ 
>>> 0x7f0304001ed0
>>> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE]0: CB A7 62 8F 3F 
>>> E0 98 7B 92 75 7F AE 70 B6 E4 0C  ..b.?..{.u..p...
>>> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE]   16: 9E B8 66 14 91 
>>> 79 63 45 5C 9E B1 EF FD B3 5F B9  ..f..ycE\._.
>>> apr 01 17:48:11 phoenix charon-debug[21177]: 07[ENC] generating TRANSACTION 
>>> response 3123281050 [ HASH CPRP(X_USER) ]
>>>
>>> Relevant swanctl authentication and secret sections are:
>>>
>>> connections {
>>> conn1 {
>>> local-2 {
>>> auth = xauth-generic
>>> xauth_id = xauthuser
>>> }
>>> }
>>> }
>>>
>>> secrets {
>>> xauth-1 {
>>> id-1 = xauthuser
>>> secret = 1234556677
>>> }
>>>
>>> Is this a well known deficiency in strongswan or is there some 
>>> configuration that can make
>>> this work?
>>>
>>> I'm happy to supply any further information that could help resolve this.
>>>
>>> Many thanks,
>>> /Mikael
>>>
>>



signature.asc
Description: OpenPGP digital signature

Re: [strongSwan] Strongswan client support for the XAUTH_PASSCODE attribute

[Noel Kuntze]

Hi,

There's just no frontend to ask dynamically for such credentials yet. You'd 
need to implement that, then you can dynamically prompt for the passcode (after 
hooking up X_CODE the same way as X_USER is). Other than that, there are no 
provisions for X_CODE or anything else. The code base wouldn't be extended 
particularly for X_CODE because IKEv1 is deprecated.

Kind regards

Noel

Am 01.04.20 um 18:22 schrieb MN Lists:
> Hi,
> 
> This is my first message to the list so sorry in advance if the answer is 
> obvious or well-known.
> Also, sorry if my terminology is messed up, hopefully you will understand my 
> issue.
> 
> I have a Juniper ScreenOS gateway that does IKEv1 VPNs with RSA and then 
> XAuth authentication
> towards an RSA SecurID box. SecurID is an MFA implementation with hardware 
> tokens that display
> a new 6-digit number every 60 seconds.
> 
> Clients can connect to it from Mac OS X with a client called NCP Secure Entry 
> and from Windows
> with the Shrewsoft client. In the past vpnc on Linux was working but as it 
> has not been developed
> since a long time and doesn't support newer algorithms, I'm looking for an 
> alternative and
> Strongswan looks promising.
> 
> So far I have been able to get IKE phase1 up but it fails on XAuth. It looks 
> as if the gateway
> is sending a request for X_USER and X_CODE but charon is responding with just 
> X_USER. Here is
> a log excerpt:
> 
> apr 01 17:48:08 phoenix charon-debug[21177]: 02[IKE] authentication of 
> 'gw.example.com' with RSA_EMSA_PKCS1_NULL successful
> apr 01 17:48:08 phoenix charon-debug[21177]: 02[IKE] activating new tasks
> apr 01 17:48:08 phoenix charon-debug[21177]: 02[IKE] nothing to initiate
> apr 01 17:48:11 phoenix charon-debug[21177]: 07[NET] received packet: from 
> 212.112.174.86[4500] to 172.20.33.34[4500] (92 bytes)
> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE] next IV for MID 
> 3123281050 => 16 bytes @ 0x7f0304001ed0
> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE]0: 51 2C 54 DC D7 31 
> 2D 5F 5D 84 00 10 81 42 88 2B  Q,T..1-_]B.+
> apr 01 17:48:11 phoenix charon-debug[21177]: 07[ENC] parsed TRANSACTION 
> request 3123281050 [ HASH CPRQ(X_TYPE X_USER X_CODE) ]
> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE] Hash => 32 bytes @ 
> 0x7f03040026b0
> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE]0: 87 1C CA 53 F3 1A 
> 81 40 E3 68 E8 78 EA 1C CF CE  ...S...@.h.x
> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE]   16: B3 53 17 C6 8C 1B 
> E7 F3 CA DD 50 DC F7 60 97 DD  .SP..`..
> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE] next IV for MID 
> 3123281050 => 16 bytes @ 0x7f02f8005600
> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE]0: 33 C2 3E 9C 64 14 
> 4C 87 85 C2 1B 26 45 84 2D FF  3.>.d.L
> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE] Hash => 32 bytes @ 
> 0x7f0304001ed0
> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE]0: CB A7 62 8F 3F E0 
> 98 7B 92 75 7F AE 70 B6 E4 0C  ..b.?..{.u..p...
> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE]   16: 9E B8 66 14 91 79 
> 63 45 5C 9E B1 EF FD B3 5F B9  ..f..ycE\._.
> apr 01 17:48:11 phoenix charon-debug[21177]: 07[ENC] generating TRANSACTION 
> response 3123281050 [ HASH CPRP(X_USER) ]
> 
> Relevant swanctl authentication and secret sections are:
> 
> connections {
> conn1 {
> local-2 {
> auth = xauth-generic
> xauth_id = xauthuser
> }
> }
> }
> 
> secrets {
> xauth-1 {
> id-1 = xauthuser
> secret = 1234556677
> }
> 
> Is this a well known deficiency in strongswan or is there some configuration 
> that can make
> this work?
> 
> I'm happy to supply any further information that could help resolve this.
> 
> Many thanks,
> /Mikael
> 



signature.asc
Description: OpenPGP digital signature

Re: [strongSwan] failed to configure VPN behind my router

[Noel Kuntze]

Hi,

Some things:
1) Your tunnel only protects traffic between exactly two IP addresses 
(XXX.XXX.166.2/32 and 10.10.10.1/32), which is probably not what you want.

Looks like the remote peer narrows the TS to the IP addresses instead of the 
networks you want.
Did you configure the exact networks you require?
2) The iptables/nftables rules also pertain the function of the VPN.
Please provide all data as shown on the HelpRequests[1] page.

Kind regards

Noel

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

Am 30.03.20 um 11:42 schrieb jl.bous...@laposte.net:
> Hello
> I need to configure a VPN server for road warriors devices
> RW establishes the tunnel and then a local process of the server hosting the 
> stongswan must access to the rw device.
> RW config is preset, i can only change the VPN server IP @ to reach.
> My VPN server is behind my internet acces router with nat and Port forwarding 
> of ports 500/4500
> I must do a stupide error but I cannot make it run
> I looked at samples, i tried both ipsec.conf and swanctl.conf
> with Ipsec.conf , I always fail with no "matching peer config found"
> with swanwctl, I found a way to establish the tunnel, keep alive are 
> exchanged but tunnel seems not be well configured
> (for that I must add my public IP in the local-ts  local_ts  =  
> 192.168.1.55,XXX.XXX.166.2)
> I would appreciate your help
> 
> Peer1  - AccessRouter1wNAT  ==    MyAccessRouterwithNAT 
> === ServerStrongSwan  
>                     @PUB1                    My@Pub   
>  192.168.1.1(Defgwy)                             192.168.1.55
>                                   
>                  Port Foward (500,4500) =>
>     <===    HTTPS over Tunnel 
> ===
> 
> 
> # ipsec.conf - strongSwan IPsec configuration file
> config setup
>     charondebug="all"
> conn %default
>     ikelifetime=60m
>     keylife=20m
>     rekeymargin=3m
>     keyingtries=1
>     keyexchange=ikev2
>     authby=secret
> conn Peervpn
>     right=%any
>     rightsubnet=10.10.10.0/28
> 
>     #My@PUB=XXX.XXX.166.2    # don't know what to do with my @ Pub
>      
>     left=192.168.1.55
>     leftfirewall=yes
>     leftsubnet=192.168.1.0/24
> 
>     ah=aes256-sha256-modp2048
>     esp=aes256-sha256-modp2048
>     ike=aes256-sha256-modp2048
>     auto=add
> 
> ipsec.secrets:
> # This file holds shared secrets or RSA private keys for authentication.
> 10.10.10.1 : PSK myterriblesecretwithpeer1
> myPeer1 : PSK myterriblesecretwithpeer1
> 
> sudo ipsec statusall
> Status of IKE charon daemon (strongSwan 5.5.1, Linux 4.19.66-v7+, armv7l):
>   uptime: 6 seconds, since Mar 30 09:45:02 2020
>   malloc: sbrk 1216512, mmap 0, used 215368, free 1001144
>   worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, 
> scheduled: 0
>   loaded plugins: charon aes rc2 sha2 sha1 md5 random nonce x509 revocation 
> constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl 
> fips-prf gmp agent xcbc hmac gcm attr kernel-netlink resolve socket-default 
> connmark stroke vici updown
> Listening IP addresses:
>   192.168.1.55
>   2a01:cb10:593:cf00:137:62f2:f7e8:274c
>   10.6.0.1
> Connections:
>  Peervpn:  192.168.1.55...%any  IKEv2
>  Peervpn:   local:  [192.168.1.55] uses pre-shared key authentication
>  Peervpn:   remote: uses pre-shared key authentication
>  Peervpn:   child:  192.168.1.0/24 === 10.10.10.0/28 TUNNEL
> Security Associations (0 up, 0 connecting):  none
> 
> sudo swanctl --log
> 10[NET] received packet: from 80.14.87.221[58694] to 192.168.1.55[500] (464 
> bytes)
> 10[ENC] 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) ]
> 10[IKE] 80.14.87.221 is initiating an IKE_SA
> 10[IKE] local host is behind NAT, sending keep alives
> 10[IKE] remote host is behind NAT
> 10[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) 
> N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(MULT_AUTH) ]
> 10[NET] sending packet: from 192.168.1.55[500] to 80.14.87.221[58694] (464 
> bytes)
> 14[NET] received packet: from 80.14.87.221[58698] to 192.168.1.55[4500] (304 
> bytes)
> 14[ENC] parsed IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr AUTH CPRQ(ADDR 
> DNS) SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(MULT_AUTH) N(EAP_ONLY) 
> N(MSG_ID_SYN_SUP) ]
> 14[CFG] looking for peer configs matching 
> 

Re: [strongSwan] Site-to-site VPN configuration help

[Noel Kuntze]

> Wed, 2020-03-25 15:08 14[CFG] <3> looking for pre-shared key peer configs 
> matching x.x.x.x...y.y.y.y[172.20.0.10]
> Wed, 2020-03-25 15:08 14[IKE] <3> no peer config found 

> rightid=aws 

Wrong id. The remote peer sends 172.20.0.10 as its own id, not 'aws'.

Am 25.03.20 um 16:13 schrieb Dafydd Tomos:
> On 25/03/2020 14:50, Noel Kuntze wrote:
>>> server-to-aws:  10.100.15.1...y.y.y.y  IKEv1, dpddelay=15s
>>>   I ended up adding an interface for 10.100.15.1 as that what appears to be 
>>> required.
>> The conn is configured for x.x.x.x, not 10.100.15.1. strongSwan doesn't need 
>> such an address.
>> Set left=x.x.x.x.
>>
> Ah thanks. That's what I did originally in fact. The log now shows it looping 
> around those proposing traffic selectors. Before this change it was trying to 
> connect. Now it says 0 connecting.
> 
> Status of IKE charon daemon (strongSwan 5.5.1, Linux 4.9.0-11-amd64, x86_64):
>   uptime: 5 seconds, since Mar 25 15:07:42 2020
>   malloc: sbrk 2297856, mmap 0, used 418656, free 1879200
>   worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, 
> scheduled: 0
>   loaded plugins: charon aesni aes rc2 sha2 sha1 md5 random nonce x509 
> revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 p
> gp dnskey sshkey pem openssl fips-prf gmp agent xcbc hmac gcm attr 
> kernel-netlink resolve socket-default connmark stroke updown
> Listening IP addresses:
>   x.x.x.x
>   10.100.15.1
> Connections:
> server-to-aws:  x.x.x.x...y.y.y.y  IKEv1, dpddelay=15s
> server-to-aws:   local:  [server] uses pre-shared key authentication
> server-to-aws:   remote: [aws] uses pre-shared key authentication
> server-to-aws:   child:  10.100.15.0/24 === 172.21.0.0/16 172.22.0.0/16 
> TUNNEL, dpdaction=restart
> Security Associations (0 up, 0 connecting):
>   none
> 
> 
> Wed, 2020-03-25 15:08 13[IKE] <3> y.y.y.y is initiating a Main Mode IKE_SA
> Wed, 2020-03-25 15:08 13[IKE] <3> IKE_SA (unnamed)[3] state change: CREATED 
> => CONNECTING
> Wed, 2020-03-25 15:08 13[CFG] <3> selecting proposal:
> Wed, 2020-03-25 15:08 13[CFG] <3>   proposal matches
> Wed, 2020-03-25 15:08 13[CFG] <3> received proposals: 
> IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1536
> Wed, 2020-03-25 15:08 13[CFG] <3> configured proposals: 
> IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1536, IKE:AES_
> CBC_128/AES_CBC_192/AES_CBC_256/AES_CTR_128/AES_CTR_192/AES_CTR_256/CAMELLIA_CBC_128/CAMELLIA_CBC_192/CAMELLIA_CBC_256/3DES_CBC
> /HMAC_SHA2_256_128/HMAC_SHA2_384_192/HMAC_SHA2_512_256/AES_XCBC_96/AES_CMAC_96/HMAC_MD5_96/HMAC_SHA1_96/PRF_AES128_XCBC/PRF_AES
> 128_CMAC/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_HMAC_MD5/PRF_HMAC_SHA1/ECP_256/ECP_384/ECP_521/ECP_256_BP/ECP_384_BP/ECP_512_BP/MODP_3072/MODP_4096/MODP_8192/MODP_2048/MODP_2048_256/MODP_1024,
>  
> IKE:AES_CCM_16_128/AES_CCM_16_192/AES_CCM_16_256/AES_GCM_16_128/AES_GCM_16_192/AES_GCM_16_256/AES_CCM_8_128/AES_CCM_8_192/AES_CCM_8_256/AES_CCM_12_128/AES_CCM_12_192/AES_CCM_12_256/AES_GCM_8_128/AES_GCM_8_192/AES_GCM_8_256/AES_GCM_12_128/AES_GCM_12_192/AES_GCM_12_256/PRF_AES128_XCBC/PRF_AES128_CMAC/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_HMAC_MD5/PRF_HMAC_SHA1/ECP_256/ECP_384/ECP_521/ECP_256_BP/ECP_384_BP/ECP_512_BP/MODP_3072/MODP_4096/MODP_8192/MODP_2048/MODP_2048_256/MODP_1024
> Wed, 2020-03-25 15:08 13[CFG] <3> selected proposal: 
> IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1536
> Wed, 2020-03-25 15:08 13[IKE] <3> sending XAuth vendor ID
> Wed, 2020-03-25 15:08 13[IKE] <3> sending DPD vendor ID
> Wed, 2020-03-25 15:08 13[IKE] <3> sending FRAGMENTATION vendor ID
> Wed, 2020-03-25 15:08 13[IKE] <3> sending NAT-T (RFC 3947) vendor ID
> Wed, 2020-03-25 15:08 13[ENC] <3> generating ID_PROT response 0 [ SA V V V V ]
> Wed, 2020-03-25 15:08 13[NET] <3> sending packet: from x.x.x.x[500] to 
> y.y.y.y[500] (164 bytes)
> Wed, 2020-03-25 15:08 10[NET] <3> received packet: from y.y.y.y[500] to 
> x.x.x.x[500] (316 bytes)
> Wed, 2020-03-25 15:08 10[ENC] <3> parsed ID_PROT request 0 [ KE No NAT-D 
> NAT-D ]
> Wed, 2020-03-25 15:08 10[LIB] <3> size of DH secret exponent: 1535 bits
> Wed, 2020-03-25 15:08 10[IKE] <3> remote host is behind NAT
> Wed, 2020-03-25 15:08 10[ENC] <3> generating ID_PROT response 0 [ KE No NAT-D 
> NAT-D ]
> Wed, 2020-03-25 15:08 10[NET] <3> sending packet: from x.x.x.x[500] to 
> y.y.y.y[500] (332 bytes)
> Wed, 2020-03-25 15:08 14[NET] <3> received packet: from y.y.y.y[4500] to 
> x.x.x.x[4500] (108 bytes)
> Wed, 2020-03-25 15:08 14[ENC] <3> parsed ID_PROT request 0 [ ID HASH 
> N(INITIAL_CON

Re: [strongSwan] Site-to-site VPN configuration help

[Noel Kuntze]

> server-to-aws:  10.100.15.1...y.y.y.y  IKEv1, dpddelay=15s 
>  I ended up adding an interface for 10.100.15.1 as that what appears to be 
> required. 

The conn is configured for x.x.x.x, not 10.100.15.1. strongSwan doesn't need 
such an address.
Set left=x.x.x.x.

Am 25.03.20 um 15:47 schrieb Dafydd Tomos:
> Status output  and debug below (anonymised, but consistent)
> 
> 
> Status of IKE charon daemon (strongSwan 5.5.1, Linux 4.9.0-11-amd64, x86_64):
>   uptime: 4 seconds, since Mar 25 14:45:06 2020
>   malloc: sbrk 1892352, mmap 0, used 417440, free 1474912
>   worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, 
> scheduled: 1
>   loaded plugins: charon aesni aes rc2 sha2 sha1 md5 random nonce x509 
> revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 p
> gp dnskey sshkey pem openssl fips-prf gmp agent xcbc hmac gcm attr 
> kernel-netlink resolve socket-default connmark stroke updown
> Listening IP addresses:
>   x.x.x.x
>   10.100.15.1
> Connections:
> server-to-aws:  10.100.15.1...y.y.y.y  IKEv1, dpddelay=15s
> server-to-aws:   local:  [server] uses pre-shared key authentication
> server-to-aws:   remote: [aws] uses pre-shared key authentication
> server-to-aws:   child:  10.100.15.0/24 === 172.21.0.0/16 172.22.0.0/16 
> TUNNEL, dpdaction=restart
> Security Associations (0 up, 1 connecting):
> server-to-aws[1]: CONNECTING, 10.100.15.1[%any]...y.y.y.y[%any]
> server-to-aws[1]: IKEv1 SPIs: f8ad92b2d16ea9a4_i* _r
> server-to-aws[1]: Tasks queued: QUICK_MODE
> server-to-aws[1]: Tasks active: ISAKMP_VENDOR ISAKMP_CERT_PRE MAIN_MODE 
> ISAKMP_CERT_POST ISAKMP_NATD
> 
> 
> Wed, 2020-03-25 14:41 00[DMN] Starting IKE charon daemon (strongSwan 5.5.1, 
> Linux 4.9.0-11-amd64, x86_64)
> Wed, 2020-03-25 14:41 00[LIB] plugin 'aesni': loaded successfully
> Wed, 2020-03-25 14:41 00[LIB] plugin 'aes': loaded successfully
> Wed, 2020-03-25 14:41 00[LIB] plugin 'rc2': loaded successfully
> Wed, 2020-03-25 14:41 00[LIB] plugin 'sha2': loaded successfully
> Wed, 2020-03-25 14:41 00[LIB] plugin 'sha1': loaded successfully
> Wed, 2020-03-25 14:41 00[LIB] plugin 'md5': loaded successfully
> Wed, 2020-03-25 14:41 00[LIB] plugin 'random': loaded successfully
> Wed, 2020-03-25 14:41 00[LIB] plugin 'nonce': loaded successfully
> Wed, 2020-03-25 14:41 00[LIB] plugin 'x509': loaded successfully
> Wed, 2020-03-25 14:41 00[LIB] plugin 'revocation': loaded successfully
> Wed, 2020-03-25 14:41 00[LIB] plugin 'constraints': loaded successfully
> Wed, 2020-03-25 14:41 00[LIB] plugin 'pubkey': loaded successfully
> Wed, 2020-03-25 14:41 00[LIB] plugin 'pkcs1': loaded successfully
> Wed, 2020-03-25 14:41 00[LIB] plugin 'pkcs7': loaded successfully
> Wed, 2020-03-25 14:41 00[LIB] plugin 'pkcs8': loaded successfully
> Wed, 2020-03-25 14:41 00[LIB] plugin 'pkcs12': loaded successfully
> Wed, 2020-03-25 14:41 00[LIB] plugin 'pgp': loaded successfully
> Wed, 2020-03-25 14:41 00[LIB] plugin 'dnskey': loaded successfully
> Wed, 2020-03-25 14:41 00[LIB] plugin 'sshkey': loaded successfully
> Wed, 2020-03-25 14:41 00[LIB] plugin 'pem': loaded successfully
> Wed, 2020-03-25 14:41 00[LIB] plugin 'openssl': loaded successfully
> Wed, 2020-03-25 14:41 00[LIB] plugin 'fips-prf': loaded successfully
> Wed, 2020-03-25 14:41 00[LIB] plugin 'gmp': loaded successfully
> Wed, 2020-03-25 14:41 00[LIB] plugin 'agent': loaded successfully
> Wed, 2020-03-25 14:41 00[LIB] plugin 'xcbc': loaded successfully
> Wed, 2020-03-25 14:41 00[LIB] plugin 'hmac': loaded successfully
> Wed, 2020-03-25 14:41 00[LIB] plugin 'gcm': loaded successfully
> Wed, 2020-03-25 14:41 00[LIB] plugin 'attr': loaded successfully
> Wed, 2020-03-25 14:41 00[LIB] plugin 'kernel-netlink': loaded successfully
> Wed, 2020-03-25 14:41 00[LIB] plugin 'resolve': loaded successfully
> Wed, 2020-03-25 14:41 00[LIB] plugin 'socket-default': loaded successfully
> Wed, 2020-03-25 14:41 00[LIB] plugin 'connmark': loaded successfully
> Wed, 2020-03-25 14:41 00[LIB] plugin 'stroke': loaded successfully
> Wed, 2020-03-25 14:41 00[LIB] plugin 'updown': loaded successfully
> Wed, 2020-03-25 14:41 00[KNL] known interfaces and IP addresses:
> Wed, 2020-03-25 14:41 00[KNL]   lo
> Wed, 2020-03-25 14:41 00[KNL] 127.0.0.1
> Wed, 2020-03-25 14:41 00[KNL] ::1
> Wed, 2020-03-25 14:41 00[KNL]   eth0
> Wed, 2020-03-25 14:41 00[KNL]   eth1
> Wed, 2020-03-25 14:41 00[KNL]   bond0
> Wed, 2020-03-25 14:41 00[KNL] x.x.x.x
> Wed, 2020-03-25 14:41 00[KNL] 10.100.15.1
> Wed, 2020-03-25 14:41 00[LIB] feature PUBKEY:DSA in plugin 'pem' has unmet 
> dependency: PUBKEY:DSA
> Wed, 2020-03-25 14:41 00[LIB] feature PRIVKEY:DSA in plugin 'pem' has unmet 
> dependency: PRIVKEY:DSA
> Wed, 2020-03-25 14:41 00[LIB] feature PRIVKEY:BLISS in plugin 'pem' has unmet 
> dependency: PRIVKEY:BLISS
> Wed, 2020-03-25 14:41 00[LIB] feature CERT_DECODE:OCSP_REQUEST in plugin 
> 'pem' has unmet dependency: CERT_DECODE:OCSP_REQUEST
> Wed, 2020-03-25 14:41 00[LIB] feature 

Re: [strongSwan] Site-to-site VPN configuration help

[Noel Kuntze]

Hi,

Configure debug logging as shown on the HelpRequests[1] page and post it.

Kind regards

Noel

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

Am 25.03.20 um 15:13 schrieb Dafydd Tomos:
> Hi,
> 
> I am using strongSwan to connect to a supplier's VPN, but am having trouble 
> understanding the IP network ranges required.
> 
> The server I'm connecting from is a Debian server with strongswan 5.5.1. It 
> has one public IP in a /29 so has one interface (bond0 using eth0/eth1). 
> There are iptables rules for incoming traffic, nothing for outgoing. I ended 
> up adding an interface for 10.100.15.1 as that what appears to be required.
> 
> The 3rd party has supplied details for a Fortigate VPN. I have an AWS VPN 
> endpoint IP along with the usual encryption details, using a PSK. It wants  
> AES256 + SHA256 + DH Group 5
> 
> It lists two 'encryption domain' IP ranges for their side. It also provides 
> an encryption domain for our side. Here's the ipsec.conf, anonymised
> 
> 
> config setup
>     # strictcrlpolicy=yes
>     # uniqueids = no
>     charondebug="all"
>     uniqueids=yes
>     strictcrlpolicy=no
> 
> conn server-to-aws
>     authby=secret
>     type=tunnel
>     auto=start
>     compress=no
> 
>     leftid=server
> # I tried these first
> #   left=x.x.x.x (public IP of our server)
> #   leftsubnet=x.x.x.x/29
>     left=10.100.15.1
>     leftsubnet=10.100.15.0/24 (encryption domain for our side, mandated 
> by 3rd party)
>     leftfirewall=no
> 
>     right=y.y.y.y (public VPN endpoint of 3rd party)
>     rightid=aws
>     rightsubnet=172.21.0.0/16, 172.22.0.0/16 (encryption domain of 3rd 
> party)
>     keyexchange=ikev1
>     ike=aes256-sha256-modp1536
>     esp=aes256-sha256-modp1536
>     ikelifetime=24h
>     lifetime=24h
>     dpddelay=15
>     dpdtimeout=30
> 
> Here's the log, anonymised with the same IPs
> 
> Mar 25 14:03:55  charon: 00[DMN] Starting IKE charon daemon (strongSwan 
> 5.5.1, Linux 4.9.0-11-amd64, x86_64)
> Mar 25 14:03:55  charon: 00[CFG] loading ca certificates from 
> '/etc/ipsec.d/cacerts'
> Mar 25 14:03:55  charon: 00[CFG] loading aa certificates from 
> '/etc/ipsec.d/aacerts'
> Mar 25 14:03:55  charon: 00[CFG] loading ocsp signer certificates from 
> '/etc/ipsec.d/ocspcerts'
> Mar 25 14:03:55  charon: 00[CFG] loading attribute certificates from 
> '/etc/ipsec.d/acerts'
> Mar 25 14:03:55  charon: 00[CFG] loading crls from '/etc/ipsec.d/crls'
> Mar 25 14:03:55  charon: 00[CFG] loading secrets from '/etc/ipsec.secrets'
> Mar 25 14:03:55  charon: 00[CFG] expanding file expression 
> '/var/lib/strongswan/ipsec.secrets.inc' failed
> Mar 25 14:03:55  charon: 00[CFG]   loaded IKE secret for 10.100.15.1 y.y.y.y
> Mar 25 14:03:55  charon: 00[CFG]   loaded IKE secret for x.x.x.x y.y.y.y
> Mar 25 14:03:55  charon: 00[LIB] loaded plugins: charon aesni aes rc2 sha2 
> sha1 md5 random nonce x509 revocation constrai
> nts pubkey pkcs1 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp 
> agent xcbc hmac gcm attr kernel-netlink resolve
> socket-default ck stroke updown
> Mar 25 14:03:55  charon: 00[LIB] dropped capabilities, running as uid 0, gid 0
> Mar 25 14:03:55  charon: 00[JOB] spawning 16 worker threads
> Mar 25 14:03:55  charon: 16[CFG] received stroke: add connection 
> 'server-to-aws'
> Mar 25 14:03:55  charon: 16[CFG] added configuration 'server-to-aws'
> Mar 25 14:03:55  charon: 07[CFG] received stroke: initiate 'server-to-aws'
> Mar 25 14:03:55  charon: 07[IKE] initiating Main Mode IKE_SA server-to-aws[1] 
> to y.y.y.y
> Mar 25 14:03:55  charon: 07[ENC] generating ID_PROT request 0 [ SA V V V V V ]
> Mar 25 14:03:55  charon: 07[NET] sending packet: from 10.100.15.1[500] to 
> y.y.y.y[500] (252 bytes)
> Mar 25 14:03:59  charon: 12[IKE] sending retransmit 1 of request message ID 
> 0, seq 1
> Mar 25 14:03:59  charon: 12[NET] sending packet: from 10.100.15.1[500] to 
> y.y.y.y[500] (252 bytes)
> Mar 25 14:04:06  charon: 11[IKE] sending retransmit 2 of request message ID 
> 0, seq 1
> Mar 25 14:04:06  charon: 11[NET] sending packet: from 10.100.15.1[500] to 
> y.y.y.y[500] (252 bytes)
> Mar 25 14:04:15  charon: 07[NET] received packet: from y.y.y.y[500] to 
> x.x.x.x[500] (292 bytes)
> Mar 25 14:04:15  charon: 07[ENC] parsed ID_PROT request 0 [ SA V V V V V V V 
> V V V ]
> Mar 25 14:04:15  charon: 07[IKE] no IKE config found for x.x.x.x...y.y.y.y, 
> sending NO_PROPOSAL_CHOSEN
> Mar 25 14:04:15  charon: 07[ENC] generating INFORMATIONAL_V1 request 
> 852369688 [ N(NO_PROP) ]
> Mar 25 14:04:15  charon: 07[NET] sending packet: from x.x.x.x[500] to 
> y.y.y.y[500] (40 bytes)
> Mar 25 14:04:16  snmpd[1797]: error on subcontainer 'ia_addr' insert (-1)
> Mar 25 14:04:18  charon: 10[NET] received packet: from y.y.y.y[500] to 
> x.x.x.x[500] (292 bytes)
> Mar 25 14:04:18  charon: 10[ENC] parsed ID_PROT request 0 [ SA V V V V V V V 
> V V V ]
> Mar 25