10456 questions

12456 answers

19379 comments

21880 members

0 votes
656 views 28 comments
by

i want to use ipsec between an RUTX11 and an fortigate firewall.

First thing i saw in the logfiles: the RUTX11 tries to reauthenticate with IKEv2. As far as i know, reauthentication should be used only with IKEv1. IKEv2 should use rekeeing only. thats also the default config at the forrtigate, so i set "reauth=no" under cutom options. i think that should be changed in the default config.

After that, i cant see any errors in the logfile. the router is trying to bring up the ipsec connection directly after boot. the tunnel is up for 1 second, and directly after that its down again. the router is doing that for the next 10-30 minutes. after that the tunnel is online and stable. i dont know whats wrong with the configuration that the tunnel is not coming directly online after the first try.

i hope someone can help. Logfiles frome one unsuccessfull connection and one successful connection after a lot of minutes can be found here: https://drive.google.com/file/d/1KADd2SlQ75_u_Uyw4ACtwzuFwAXdP0y0/view?usp=sharing

BTW: why cant we upload logfiles here?!? 12000 characters are not enough for logfiles.

1 Answer

0 votes
by

Hello.

Make sure both devices have the latest firmware

Try to configure the IPsec connection with another parameters.

You can download some configuration examples with fortigate here, hope this helps

Best regards.

by

Both devices are up to date.

i tried so much configurations, nearly every one.. ikev1 v2 with a lot of different settings, nothing worked.

what i know: i have already one running RUT240. it connects via ikev2. its working fine. the rutx11 does not work. i was seting up a second rut240 with the same local adress and ipsec settings from the rutx11, it works! So that must be a problem with the rutx11.

i dont know if its a general firmwareissue or just an issue with interface, which creates the configfile. the webinterface for the ipsec setup looks completely different between the rutx11 and rut240

i found that at the start of the fortigate logfile:

ike 1:abd468380fd0f729/0000000000000000:259233: responder received SA_INIT msg
ike 1:abd468380fd0f729/0000000000000000:259233: received notify type NAT_DETECTION_SOURCE_IP
ike 1:abd468380fd0f729/0000000000000000:259233: received notify type NAT_DETECTION_DESTINATION_IP
ike 1:abd468380fd0f729/0000000000000000:259233: received notify type FRAGMENTATION_SUPPORTED
ike 1:abd468380fd0f729/0000000000000000:259233: received notify type SIGNATURE_HASH_ALGORITHMS
ike 1:abd468380fd0f729/0000000000000000:259233: received notify type 16406
ike 1:abd468380fd0f729/0000000000000000:259233: ignoring unauthenticated notify payload (16406)
ike 1:abd468380fd0f729/0000000000000000:259233: incoming proposal:
ike 1:abd468380fd0f729/0000000000000000:259233: proposal id = 1:
ike 1:abd468380fd0f729/0000000000000000:259233:   protocol = IKEv2:
ike 1:abd468380fd0f729/0000000000000000:259233:      encapsulation = IKEv2/none
ike 1:abd468380fd0f729/0000000000000000:259233:         type=ENCR, val=AES_CBC (key_len = 256)

maybe it will help

by

Me again,

we need support for that RUTX11. Is it possible to get an professional support for that devices with SLAs, Tickets and so on?

For that problem with the vpn connection between the RUTX11 and our Fortigate:

Here is a working configuration from one RUT240:

And here the configuration from  the RUTX11 which is not working:

Note:

The RUT240 uses AES128, because AES256 is so much slower on that little router. The RUT240 is also working with AES256, we selectes AES128 only because of performance issues.

We would like to replace 30 of our Lancom routers with a different product, but without vpn the RUTX11 its useless.

by

Try to just add the line "sleep 20" using vi /etc/init.d/ipsec command on your RUTX11.

by

Like that?

I tested it with that config, same problem.

by
Angelo,

Are you sure about your connection_ok.txt ? Doesn't look much different from connection_fail.txt.

I have an IKEv2 connection from a RUTX11 firmware 02.06 and another strongswan, albeit with different parameters (X.509, DH groups), it works as expected.

Regards.
by
Im shure with that logfile.

i resetet the router more then once. i know that the logfile from the router looks like the tunnel is up, but it is not. The tunnel is up for maximum 1 second and directly down again.

I think it must be something with the RUTX11, because the RUT240 is working fine with that settings.
by
Could this be an issue with the random number generator ? Is the RUTX11 in a "noisy" environment with a lot of interrupts/activity ?

Could you check with: cat /proc/sys/kernel/random/entropy_avail immediately after reboot and report the value ?

@teltonika: Is there a way to increase the debug level of the daemon: IKE, KNL, LIB, NET ... ?

And detailed logs from the Fortigate may also help.

Regards,
by

Here is the logfile from the fortigate. https://drive.google.com/file/d/1FKtt3FrsKzonAQgpD83ykiZpooWGio3l/view?usp=sharing

I noticed something at the beginning and something at the end of the logfile, im not shure if that is normal.

ike 1:abd468380fd0f729/0000000000000000:259233: responder received SA_INIT msg
ike 1:abd468380fd0f729/0000000000000000:259233: received notify type NAT_DETECTION_SOURCE_IP
ike 1:abd468380fd0f729/0000000000000000:259233: received notify type NAT_DETECTION_DESTINATION_IP
ike 1:abd468380fd0f729/0000000000000000:259233: received notify type FRAGMENTATION_SUPPORTED
ike 1:abd468380fd0f729/0000000000000000:259233: received notify type SIGNATURE_HASH_ALGORITHMS
ike 1:abd468380fd0f729/0000000000000000:259233: received notify type 16406
ike 1:abd468380fd0f729/0000000000000000:259233: ignoring unauthenticated notify payload (16406)
ike 1:abd468380fd0f729/0000000000000000:259233: incoming proposal:
ike 1:abd468380fd0f729/0000000000000000:259233: proposal id = 1:
ike 1:abd468380fd0f729/0000000000000000:259233:   protocol = IKEv2:

ike 1:vpn_RT1052001_0:259234: dec XXX
ike 1:vpn_RT1052001_0:259234: received informational request
ike 1:vpn_RT1052001_0:259234: processing delete request (proto 1)
ike 1:vpn_RT1052001_0:259234: deleting IKE SA d73329d566569e04/730ae2e6beec7e93
ike 1:vpn_RT1052001_0:259234: schedule delete of IKE SA d73329d566569e04/730ae2e6beec7e93
ike 1:vpn_RT1052001_0:259234: enc XXX
ike 1:vpn_RT1052001_0:259234: out XXX
ike 1:vpn_RT1052001_0:259234: sent IKE msg (INFORMATIONAL_RESPONSE): XXX.XXX.XXX.XXX:4500->XXX.XXX.XXX.XXX:1024, len=76, id=d73329d566569e04/730ae2e6beec7e93
ike 1: comes XXX.XXX.XXX.XXX:1024->XXX.XXX.XXX.XXX:4500,ifindex=22....
ike 1: IKEv2 exchange=INFORMATIONAL id=abd468380fd0f729/cb1ae50b1e5fdbf1:00000003 len=76
ike 1: in XXX
ike 1:vpn_RT1052001_0:259233: dec XXX
ike 1:vpn_RT1052001_0:259233: received informational request
ike 1:vpn_RT1052001_0:259233: processing delete request (proto 1)
ike 1:vpn_RT1052001_0:259233: deleting IKE SA abd468380fd0f729/cb1ae50b1e5fdbf1
ike 1:vpn_RT1052001_0:259233: schedule delete of IKE SA abd468380fd0f729/cb1ae50b1e5fdbf1
ike 1:vpn_RT1052001_0:259233: enc XXX
ike 1:vpn_RT1052001_0:259233: out XXX
ike 1:vpn_RT1052001_0:259233: sent IKE msg (INFORMATIONAL_RESPONSE): XXX.XXX.XXX.XXX:4500->XXX.XXX.XXX.XXX:1024, len=76, id=abd468380fd0f729/cb1ae50b1e5fdbf1:00000003

by

From the Fortigate logs: ike 1:vpn_RT1052001:259233:vpn_RT1052001:844254:         PFS is disabled

Is this the expected configuration ?

About ike 1:abd468380fd0f729/0000000000000000:259233: ignoring unauthenticated notify payload (16406): just a warning about a vendor id payload, you can ignore it.

by
PFS should be aktive. On the forrtigate site it is aktive.

I cant see an option for that on the RUTX11...
by
Proposal Settings->Phase 2->PFS Group, make sure that it is not set to No PFS.
by
its set to 1536... I think thats a bug in the webinterface.
by

Angelo,

Could you test the connections to the fortigate again. After that, download the troubleshoot file, you can find it in the menu System->Administration->Troubleshoot, the file will be sent to me via private messages. Don't reset or reboot the device before downloading the troubleshoot file. 

Regards.

by

I tested it with a older firmware, still the same situation, but the logfile looks different. But first: someone asked if the router is in an noisy enviroment -> Not it isn't. i tested it over LTE and local WAN (VDSL)...

Phase 2 settings:

Here is the new logfile with the Firmware 2.05.2:

Fri Jan 15 16:24:20 2021 daemon.info ipsec: 14[CFG] received stroke: initiate 'FWS-FWS_c'
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 14[IKE] initiating IKE_SA FWS-FWS_c[71] to XXX.XXX.XXX.XXX
Fri Jan 15 16:24:20 2021 authpriv.info ipsec: 14[IKE] initiating IKE_SA FWS-FWS_c[71] to XXX.XXX.XXX.XXX
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 14[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) ]
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 14[NET] sending packet: from XXX.XXX.XXX.XXX[500] to XXX.XXX.XXX.XXX[500] (862 bytes)
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 11[NET] received packet: from XXX.XXX.XXX.XXX[500] to XXX.XXX.XXX.XXX[500] (360 bytes)
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 11[ENC] parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ]
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 11[CFG] selected proposal: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 01[KNL] interface tmp.radio1 deleted
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 11[IKE] local host is behind NAT, sending keep alives
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 11[IKE] authentication of 'Test0001' (myself) with pre-shared key
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 11[IKE] establishing CHILD_SA FWS-FWS_c{36}
Fri Jan 15 16:24:20 2021 authpriv.info ipsec: 11[IKE] establishing CHILD_SA FWS-FWS_c{36}
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 11[ENC] generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_6_ADDR) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 11[NET] sending packet: from XXX.XXX.XXX.XXX[4500] to XXX.XXX.XXX.XXX[4500] (380 bytes)
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 06[NET] received packet: from XXX.XXX.XXX.XXX[4500] to XXX.XXX.XXX.XXX[4500] (204 bytes)
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 06[ENC] parsed IKE_AUTH response 1 [ IDr AUTH N(MSG_ID_SYN_SUP) SA TSi TSr ]
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 06[IKE] authentication of 'XXX.XXX.XXX.XXX' with pre-shared key successful
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 06[IKE] IKE_SA FWS-FWS_c[71] established between XXX.XXX.XXX.XXX[Test0001]...XXX.XXX.XXX.XXX[XXX.XXX.XXX.XXX]
Fri Jan 15 16:24:20 2021 authpriv.info ipsec: 06[IKE] IKE_SA FWS-FWS_c[71] established between XXX.XXX.XXX.XXX[Test0001]...XXX.XXX.XXX.XXX[XXX.XXX.XXX.XXX]
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 06[IKE] scheduling rekeying in -834s
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 06[IKE] maximum IKE_SA lifetime -294s
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 06[CFG] selected proposal: ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 06[IKE] CHILD_SA FWS-FWS_c{36} established with SPIs c0c2a3a8_i aa0f04e5_o and TS 172.19.52.0/24 === 172.16.0.0/12
Fri Jan 15 16:24:20 2021 authpriv.info ipsec: 06[IKE] CHILD_SA FWS-FWS_c{36} established with SPIs c0c2a3a8_i aa0f04e5_o and TS 172.19.52.0/24 === 172.16.0.0/12
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 06[CHD] updown: uci: Entry not found
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 06[CHD] updown: uci: Invalid argument
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 06[CHD] updown: uci: Invalid argument
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 06[CHD] updown: sh: l2tp: unknown operand
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 06[CHD] updown: sh: server: unknown operand
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 08[KNL] interface tmp.radio1 deleted

Fri Jan 15 16:24:20 2021 local0.notice vpn: + XXX.XXX.XXX.XXX 172.16.0.0/12 == XXX.XXX.XXX.XXX -- XXX.XXX.XXX.XXX == 172.19.52.0/24
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 10[IKE] initiating IKE_SA FWS-FWS_c[72] to XXX.XXX.XXX.XXX
Fri Jan 15 16:24:20 2021 authpriv.info ipsec: 10[IKE] initiating IKE_SA FWS-FWS_c[72] to XXX.XXX.XXX.XXX
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 10[ENC] generating CREATE_CHILD_SA request 2 [ SA No KE ]
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 10[NET] sending packet: from XXX.XXX.XXX.XXX[4500] to XXX.XXX.XXX.XXX[4500] (844 bytes)
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 11[NET] received packet: from XXX.XXX.XXX.XXX[4500] to XXX.XXX.XXX.XXX[4500] (348 bytes)
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 11[ENC] parsed CREATE_CHILD_SA response 2 [ SA No KE ]
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 11[CFG] selected proposal: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 11[IKE] scheduling rekeying in -760s
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 11[IKE] maximum IKE_SA lifetime -220s
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 11[IKE] IKE_SA FWS-FWS_c[72] rekeyed between XXX.XXX.XXX.XXX[Test0001]...XXX.XXX.XXX.XXX[XXX.XXX.XXX.XXX]
Fri Jan 15 16:24:20 2021 authpriv.info ipsec: 11[IKE] IKE_SA FWS-FWS_c[72] rekeyed between XXX.XXX.XXX.XXX[Test0001]...XXX.XXX.XXX.XXX[XXX.XXX.XXX.XXX]
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 11[IKE] deleting IKE_SA FWS-FWS_c[71] between XXX.XXX.XXX.XXX[Test0001]...XXX.XXX.XXX.XXX[XXX.XXX.XXX.XXX]
Fri Jan 15 16:24:20 2021 authpriv.info ipsec: 11[IKE] deleting IKE_SA FWS-FWS_c[71] between XXX.XXX.XXX.XXX[Test0001]...XXX.XXX.XXX.XXX[XXX.XXX.XXX.XXX]
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 11[IKE] sending DELETE for IKE_SA FWS-FWS_c[71]
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 11[ENC] generating INFORMATIONAL request 3 [ D ]
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 07[IKE] deleting IKE_SA FWS-FWS_c[72] between XXX.XXX.XXX.XXX[Test0001]...XXX.XXX.XXX.XXX[XXX.XXX.XXX.XXX]
Fri Jan 15 16:24:20 2021 authpriv.info ipsec: 07[IKE] deleting IKE_SA FWS-FWS_c[72] between XXX.XXX.XXX.XXX[Test0001]...XXX.XXX.XXX.XXX[XXX.XXX.XXX.XXX]
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 11[NET] sending packet: from XXX.XXX.XXX.XXX[4500] to XXX.XXX.XXX.XXX[4500] (76 bytes)
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 07[IKE] sending DELETE for IKE_SA FWS-FWS_c[72]
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 07[ENC] generating INFORMATIONAL request 0 [ D ]
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 07[NET] sending packet: from XXX.XXX.XXX.XXX[4500] to XXX.XXX.XXX.XXX[4500] (76 bytes)
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 05[NET] received packet: from XXX.XXX.XXX.XXX[4500] to XXX.XXX.XXX.XXX[4500] (76 bytes)
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 05[ENC] parsed INFORMATIONAL response 3 [ ]
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 05[IKE] IKE_SA deleted
Fri Jan 15 16:24:20 2021 authpriv.info ipsec: 05[IKE] IKE_SA deleted
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 08[NET] received packet: from XXX.XXX.XXX.XXX[4500] to XXX.XXX.XXX.XXX[4500] (76 bytes)
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 08[ENC] parsed INFORMATIONAL response 0 [ ]
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 08[IKE] IKE_SA deleted
Fri Jan 15 16:24:20 2021 authpriv.info ipsec: 08[IKE] IKE_SA deleted
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 08[CHD] updown: uci: Entry not found
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 08[CHD] updown: uci: Invalid argument
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 08[CHD] updown: uci: Invalid argument
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 08[CHD] updown: sh: l2tp: unknown operand
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 08[CHD] updown: sh: server: unknown operand

Fri Jan 15 16:24:21 2021 local0.notice vpn: - XXX.XXX.XXX.XXX 172.16.0.0/12 == XXX.XXX.XXX.XXX -- XXX.XXX.XXX.XXX == 172.19.52.0/24

Is that an old bug which was fixed in the version 2.06 and 2.06 has a new bug? Or is it the same bug without logging that in 2.06?

by

About the "noisy" environment: this is to assure there is enough interrupts to fill the entropy pool. Hard to find/diagnose, had to switch to an hardware random number generator.

From the logs above:

Fri Jan 15 16:24:20 2021 daemon.info ipsec: 06[IKE] scheduling rekeying in -834s
Fri Jan 15 16:24:20 2021 daemon.info ipsec: 06[IKE] maximum IKE_SA lifetime -294s

A negative lifetime ? How strange! Is this just a display bug ? Or something is really wrong here. This can explain why the SA is deleted immediately after being established. Is your device time synchonized with an NTP server ?

I suggest you increase the log level of the ipsec daemon to try to see what is going on here. Unfortunately the value is hardcoded  in /etc/init.d/ipsec, you'll have to edit the file and set default = 4 (at line 430 in version 02.06) other versions look at

swan_xappend "  syslog {"        
        swan_xappend "    identifier = ipsec"
        swan_xappend "    daemon {"            
        swan_xappend "      default = 1" 

The updown issue is another subject.

Regards,

 

by

i compared that to the RUT240. RUT240 Logfile:

Fri Jan 15 21:12:17 2021 daemon.info ipsec: 11[IKE] scheduling reauthentication in 28244s
Fri Jan 15 21:12:17 2021 daemon.info ipsec: 11[IKE] maximum IKE_SA lifetime 28784s

I also checked the time on the RUTX11. originaly it was set to timezone Europe/Berlin... which means UTC+1

I set that to UTC, like the RUT240. In the console the RUTX11 says no that the timezone is GMT. Strange enough, but the time is now ok and it still does not connect. Bute it could be something with the time.

RUT240 date:

RUTX11 date:

i testet higher lifetimes for phase 1 and phase 2 on both sites, that didnt change anything in the logfile. It still shows a negative lifetime. I also checked the time on the fortigate. the fortigate is sycnced with GMT+1, so on the commandline the fortigate is one hour ahead.

by
So the lifetime is correct on the RUT240 but completely wrong on the RUTX11. But why ? ...

Please increase the debug level as indicated above, and reboot. The answer will probably be there.
by

LOL. Got it.

You need to write 8h for lifetime, not only 8. I thought that that lifetimesettings are always a value in hours, because of that grey example.

Now the logfile is ok:

Fri Jan 15 23:38:43 2021 daemon.info ipsec: 08[CFG] received stroke: add connection 'passth_FWS_ph2'
Fri Jan 15 23:38:43 2021 daemon.info ipsec: 08[CFG] added configuration 'passth_FWS_ph2'
Fri Jan 15 23:38:43 2021 daemon.info ipsec: 10[CFG] received stroke: route 'passth_FWS_ph2'
Fri Jan 15 23:38:43 2021 authpriv.info ipsec_starter[28635]: 'passth_FWS_ph2' shunt PASS policy installed
Fri Jan 15 23:38:43 2021 authpriv.info ipsec_starter[28635]:
Fri Jan 15 23:38:43 2021 daemon.info ipsec: 13[CFG] received stroke: add connection 'FWS-FWS_c'
Fri Jan 15 23:38:43 2021 daemon.info ipsec: 13[CFG] added configuration 'FWS-FWS_c'
Fri Jan 15 23:38:43 2021 daemon.info ipsec: 01[CFG] received stroke: initiate 'FWS-FWS_c'
Fri Jan 15 23:38:43 2021 daemon.info ipsec: 01[IKE] initiating IKE_SA FWS-FWS_c[1] to XXX.XXX.XXX.XXX
Fri Jan 15 23:38:43 2021 authpriv.info ipsec: 01[IKE] initiating IKE_SA FWS-FWS_c[1] to XXX.XXX.XXX.XXX
Fri Jan 15 23:38:43 2021 daemon.info ipsec: 01[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) ]
Fri Jan 15 23:38:43 2021 daemon.info ipsec: 01[NET] sending packet: from XXX.XXX.XXX.XXX[500] to XXX.XXX.XXX.XXX[500] (904 bytes)
Fri Jan 15 23:38:44 2021 daemon.info ipsec: 05[NET] received packet: from XXX.XXX.XXX.XXX[500] to XXX.XXX.XXX.XXX[500] (360 bytes)
Fri Jan 15 23:38:44 2021 daemon.info ipsec: 05[ENC] parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ]
Fri Jan 15 23:38:44 2021 daemon.info ipsec: 05[CFG] selected proposal: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536
Fri Jan 15 23:38:44 2021 daemon.info ipsec: 05[IKE] local host is behind NAT, sending keep alives
Fri Jan 15 23:38:44 2021 daemon.info ipsec: 05[IKE] authentication of 'Test0001' (myself) with pre-shared key
Fri Jan 15 23:38:44 2021 daemon.info ipsec: 05[IKE] establishing CHILD_SA FWS-FWS_c{1}
Fri Jan 15 23:38:44 2021 authpriv.info ipsec: 05[IKE] establishing CHILD_SA FWS-FWS_c{1}
Fri Jan 15 23:38:44 2021 daemon.info ipsec: 05[ENC] generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_6_ADDR) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
Fri Jan 15 23:38:44 2021 daemon.info ipsec: 05[NET] sending packet: from XXX.XXX.XXX.XXX[4500] to XXX.XXX.XXX.XXX[4500] (380 bytes)
Fri Jan 15 23:38:44 2021 daemon.info ipsec: 07[NET] received packet: from XXX.XXX.XXX.XXX[4500] to XXX.XXX.XXX.XXX[4500] (204 bytes)
Fri Jan 15 23:38:44 2021 daemon.info ipsec: 07[ENC] parsed IKE_AUTH response 1 [ IDr AUTH N(MSG_ID_SYN_SUP) SA TSi TSr ]
Fri Jan 15 23:38:44 2021 daemon.info ipsec: 07[IKE] authentication of 'XXX.XXX.XXX.XXX' with pre-shared key successful
Fri Jan 15 23:38:44 2021 daemon.info ipsec: 07[IKE] IKE_SA FWS-FWS_c[1] established between XXX.XXX.XXX.XXX[Test0001]...XXX.XXX.XXX.XXX[XXX.XXX.XXX.XXX]
Fri Jan 15 23:38:44 2021 authpriv.info ipsec: 07[IKE] IKE_SA FWS-FWS_c[1] established between XXX.XXX.XXX.XXX[Test0001]...XXX.XXX.XXX.XXX[XXX.XXX.XXX.XXX]
Fri Jan 15 23:38:44 2021 daemon.info ipsec: 07[IKE] scheduling rekeying in 27988s
Fri Jan 15 23:38:44 2021 daemon.info ipsec: 07[IKE] maximum IKE_SA lifetime 28528s
Fri Jan 15 23:38:44 2021 daemon.info ipsec: 07[CFG] selected proposal: ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ
Fri Jan 15 23:38:44 2021 daemon.info ipsec: 07[IKE] CHILD_SA FWS-FWS_c{1} established with SPIs c2dc7010_i aa0f0ccd_o and TS XXX.XXX.XXX.XXX === XXX.XXX.XXX.XXX
Fri Jan 15 23:38:44 2021 authpriv.info ipsec: 07[IKE] CHILD_SA FWS-FWS_c{1} established with SPIs c2dc7010_i aa0f0ccd_o and TS XXX.XXX.XXX.XXX === XXX.XXX.XXX.XXX
Fri Jan 15 23:38:44 2021 local0.notice vpn: + XXX.XXX.XXX.XXX XXX.XXX.XXX.XXX == XXX.XXX.XXX.XXX -- XXX.XXX.XXX.XXX == XXX.XXX.XXX.XXX

by
Good to know. It worked after 10-30 mn ?
by
its coming directly online, like it should be.
by
Does someone know if Autokey Keep Alive is enabled in phase 2 by default?
by
It is, AFAIK. But better to check the logs or do a  tcpdump.
by

i checked that thing with ikev2 reauth....

fortigate does not use reauthentication with ikev2, which is correct. Teltonika uses reauth, which is not the best solution. reauth should only be used with ikev1. with ikev2, only rekeying should be active. otherwhise every 8 hours the tunnel will be down for some seconds. i fixed that with the custom option reauth=0 at the moment.

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

In my opinion that should be fixed in the firmware

by
Thank you for information. I will inform our HQ about your proposal.
by
And about the UI: it should at least catch the case where IKE lifetime < 2 * margintime, or have a field to choose the unit.
by

And when whe are already talking about things that will never happen: Lets implement multi-core use for VPN crypto... at the moment it uses only one core for that and is limited to 50-55mbit/s with aes 256. Thats to slow for a new product. we are talking about 100mbit and 250mbit wan uplinks, that is not unusual....

BTW, fortigate already has the field to chose the unit:

by
Wireguard ? About twice the throughput ... and much simpler than ipsec.
by
we will not use wireguard.

I think we will drop the test with the teltonikas, they are simply to slow for professional use. If they could handle more than 100mbit/s ipsec, we would give them a try. But at the moment i would say that this i something for an homeoffice workplace, or realy small office with one or 2 pcs, or something for enthusiasts / private use.

I think we will use the fortigate 40F in our ofsite locations. much more power and also realy cheap.