Skip to main content
systemgeek
systemgeek
Visitor III
May 13, 2025
Solved

Dialup IPSec VPN issues with Phase 1

  • May 13, 2025
  • 2 replies
  • 3424 views

FortiGate - 7.6.3

FortiClient - 7.2.9 (Windows and Mac)

 

I have been working with Support for weeks now with no success so hoping I can get help here.

Fortigate config:

config vpn ipsec phase1-interface
edit "OpsIPSecVPN"
set type dynamic
set interface "port1"
set ike-version 2
set peertype any
set net-device disable
set mode-cfg enable
set proposal des-sha512 aes256-sha512
set comments "VPN: OpsIPSecVPN -- Created by VPN wizard"
set dhgrp 14
set wizard-type dialup-forticlient
set nattraversal disable
set network-overlay enable
set network-id 0
set transport tcp
set fortinet-esp enable
set assign-ip-from name
set dns-mode auto
set ipv4-split-include "OpsIPSecVPN_split"
set ipv4-name "VPN_PCI_Operations_us2"
set save-password enable
set client-auto-negotiate enable
set client-keep-alive enable
set psksecret ENC ***

 

FortiClient config:

<connection>
<name>us2-LOACAL2</name>
<type>manual</type>
<ike_settings>
<keep_fqdn_resolution_consistency>0</keep_fqdn_resolution_consistency>
<version>2</version>
<eap_method>0</eap_method>
<sso_enabled>0</sso_enabled>
<ike_saml_port>0</ike_saml_port>
<use_external_browser>0</use_external_browser>
<fido_auth>0</fido_auth>
<prompt_certificate>0</prompt_certificate>
<description></description>
<server>vpn.example.com</server>
<authentication_method>Preshared Key</authentication_method>
<auth_key></auth_key>
<auth_data>
<preshared_key>Enc ********</preshared_key>
<certificate></certificate>
</auth_data>
<mode>aggressive</mode>
<dhgroup>14</dhgroup>
<key_life>86400</key_life>
<localid></localid>
<nat_traversal>0</nat_traversal>
<networkid>0</networkid>
<sase_mode>0</sase_mode>
<mode_config>1</mode_config>
<enable_local_lan>0</enable_local_lan>
<enable_ike_fragmentation>0</enable_ike_fragmentation>
<dpd>1</dpd>
<xauth>
<enabled>1</enabled>
<prompt_username>0</prompt_username>
<username>Enc XXXXXXXXX</username>
<password>Enc *********</password>
</xauth>
<proposals>
<proposal>DES|SHA512</proposal>
<proposal>AES256|SHA256</proposal>
</proposals>
<fgt>0</fgt>
</ike_settings>
<ipsec_settings>
<remote_networks></remote_networks>
<dhgroup>14</dhgroup>
<key_life_type>seconds</key_life_type>
<key_life_seconds>86400</key_life_seconds>
<key_life_Kbytes>5120</key_life_Kbytes>
<replay_detection>0</replay_detection>
<pfs>1</pfs>
<use_vip>1</use_vip>
<virtualip>
<type>modeconfig</type>
<ip></ip>
<mask></mask>
<dnsserver></dnsserver>
</virtualip>
<proposals>
<proposal>DES|SHA512</proposal>
<proposal>AES256|SHA256</proposal>
</proposals>
<ipv4_split_exclude_networks></ipv4_split_exclude_networks>
</ipsec_settings>
<on_connect>
<script>
<os>mac</os>
<script>$null</script>
</script>
</on_connect>
<on_disconnect>
<script>
<os>mac</os>
<script>$null</script>
</script>
</on_disconnect>
<tags>
<allowed></allowed>
<prohibited></prohibited>
</tags>
<host_check_fail_warning></host_check_fail_warning>
<keep_running>0</keep_running>
<disclaimer_msg>$null</disclaimer_msg>
<ui>
<show_passcode>0</show_passcode>
<show_remember_password>0</show_remember_password>
<show_alwaysup>0</show_alwaysup>
<show_autoconnect>0</show_autoconnect>
<save_username>0</save_username>
<save_password>0</save_password>
</ui>
</connection>
</connections>
</ipsecvpn>

Regardless of Encryption - Authentication on either side I get "no proposal chosen" "Negotiate SA Error".  Whats more interesting is what the Client seems to be sending to the FortiGate:

2025-05-13 14:53:35.412782 ike V=root:0:6bbf3efb5a59b188/0000000000000000:690: incoming proposal:
2025-05-13 14:53:35.412945 ike V=root:0:6bbf3efb5a59b188/0000000000000000:690: proposal id = 1:
2025-05-13 14:53:35.412951 ike V=root:0:6bbf3efb5a59b188/0000000000000000:690: protocol = IKEv2:
2025-05-13 14:53:35.413111 ike V=root:0:6bbf3efb5a59b188/0000000000000000:690: encapsulation = IKEv2/none
2025-05-13 14:53:35.413117 ike V=root:0:6bbf3efb5a59b188/0000000000000000:690: type=ENCR, val=AES_CBC (key_len = 256)
2025-05-13 14:53:35.413279 ike V=root:0:6bbf3efb5a59b188/0000000000000000:690: type=INTEGR, val=AUTH_HMAC_SHA2_512_256
2025-05-13 14:53:35.413284 ike V=root:0:6bbf3efb5a59b188/0000000000000000:690: type=PRF, val=PRF_HMAC_SHA
2025-05-13 14:53:35.413445 ike V=root:0:6bbf3efb5a59b188/0000000000000000:690: type=PRF, val=PRF_HMAC_SHA2_512
2025-05-13 14:53:35.413451 ike V=root:0:6bbf3efb5a59b188/0000000000000000:690: type=PRF, val=PRF_HMAC_SHA2_384
2025-05-13 14:53:35.413611 ike V=root:0:6bbf3efb5a59b188/0000000000000000:690: type=PRF, val=PRF_HMAC_SHA2_256
2025-05-13 14:53:35.413616 ike V=root:0:6bbf3efb5a59b188/0000000000000000:690: type=DH_GROUP, val=MODP2048.
2025-05-13 14:53:35.413950 ike V=root:0:6bbf3efb5a59b188/0000000000000000:690: proposal id = 2:
2025-05-13 14:53:35.414123 ike V=root:0:6bbf3efb5a59b188/0000000000000000:690: protocol = IKEv2:
2025-05-13 14:53:35.414128 ike V=root:0:6bbf3efb5a59b188/0000000000000000:690: encapsulation = IKEv2/none
2025-05-13 14:53:35.414299 ike V=root:0:6bbf3efb5a59b188/0000000000000000:690: type=ENCR, val=AES_CBC (key_len = 256)
2025-05-13 14:53:35.414304 ike V=root:0:6bbf3efb5a59b188/0000000000000000:690: type=INTEGR, val=AUTH_HMAC_SHA2_256_128
2025-05-13 14:53:35.414474 ike V=root:0:6bbf3efb5a59b188/0000000000000000:690: type=PRF, val=PRF_HMAC_SHA
2025-05-13 14:53:35.414478 ike V=root:0:6bbf3efb5a59b188/0000000000000000:690: type=PRF, val=PRF_HMAC_SHA2_512
2025-05-13 14:53:35.414483 ike V=root:0:6bbf3efb5a59b188/0000000000000000:690: type=PRF, val=PRF_HMAC_SHA2_384
2025-05-13 14:53:35.414487 ike V=root:0:6bbf3efb5a59b188/0000000000000000:690: type=PRF, val=PRF_HMAC_SHA2_256
2025-05-13 14:53:35.414492 ike V=root:0:6bbf3efb5a59b188/0000000000000000:690: type=DH_GROUP, val=MODP2048.

 

The first part of that incoming proposal says IKEv2 with AES_CBC key length 256, SHA512.  But where is DES since thats the first option in the client.  The proposal from the FortiGate does say val=DES_CBC.

 

To me this is say that the ForitClient is ignoring the config when sending the proposal.

 

Has anyone else seen this????

 

 

Best answer by funkylicious

i assume that you are trying to do ipsec w/ tcp and ikev2.

try using at least FortiClient 7.4.1 which would support this setup and choose only 1 set of params for phase1, dont enable/configure multiple options.

 

have a look at this also, https://community.fortinet.com/t5/Support-Forum/FortiClient-Remote-Access-IPsec-over-TCP-not-working/td-p/383618 

2 replies

funkylicious
SuperUser
funkyliciousAnswer
SuperUser
May 13, 2025

i assume that you are trying to do ipsec w/ tcp and ikev2.

try using at least FortiClient 7.4.1 which would support this setup and choose only 1 set of params for phase1, dont enable/configure multiple options.

 

have a look at this also, https://community.fortinet.com/t5/Support-Forum/FortiClient-Remote-Access-IPsec-over-TCP-not-working/td-p/383618 

"jack of all trades, master of none"
systemgeek
systemgeekAuthor
Visitor III
May 14, 2025

I read through that doc you posted.  I can say that with FortiOS 7.6.3 FCT 7.2.9 and 7.4.3 setting the Encapsulation on the client to IKE UDP port 4500 gets a response on the FGT.  The same is true with Auto.  However, IPSec over TCP never makes it to the FGT.  I think its doing a retransmission when set to IPSec over TCP.

 

I do not know anything about FCT 7.4.8 which was mentioned in that doc.

funkylicious
SuperUser
funkylicious
SuperUser
May 14, 2025

FortiOS 7.4.8 is to be available this month if i understood correctly

"jack of all trades, master of none"
fcb
fcb
Visitor III
February 27, 2026

I get that this post is a little dated, but did you ever find a solution as I am also receiving: "no proposal chosen" "Negotiate SA Error" , BUT only on two of the four tunnels I have configured and I (and I think you too) are getting this because the traffic fro the FTC is not matching any of the Gate configured tunnels, but it should be.

 

I have gotten here because we have to migrate from IKEv1 to v2 - IKEv1 had a mechanism that would allow multiple dial-up IPSEC tunnels on the same physical interface/IP, but IKEv2 does not have this natively.. In my case, I have four tunnels across two ISP's/IP's/Interfaces and two of my tunnels are working perfectly on IKEv2, but they are working because they were the first tunnels configured on my interface(s) because in both of my cases it's the second tunnel hat was created on each of my two interfaces that's not working... This is expected with any firewall using IKEv2nd multiple tunnels configured on a single IP/Interface.

 

One thing your debugs didn't show as if your getting this where you can see FortiClient providing the networkid:

 

2026-02-27 08:51:30.615860 ike V=root:0: comes 1.1.1.11024->22.2.2.2:500,ifindex=31,vrf=0,len=465....
2026-02-27 08:51:30.615920 ike V=root:0: IKEv2 exchange=SA_INIT id=b9b75672829af722/0000000000000000 len=465
2026-02-27 08:51:30.615956 ike 0: in B9B75672829AF72200000000000000002120220800000000000001D12200005C0200002C010100040300000C0100000C800E01000300000802000006030000080300000D00000008040000050000002C020100040300000C0100000C800E01000300000802000007030000080300000E0000000804000005280000C800050000029FF9C75D9CBA3D5D29FC598635CBEB0863428AC430E596153BA9BCD990C0A531F4FEE056448328C1911C9EEDE272A2570B3E8F1C0EA837CEBCD0ADF125FCDFC3D5F890BD084479B822942278DB18D35B9D66B6B3D8D4543634624E0446078B45E178EA7B71E114218572EF911B3D9C8D3682ACE2FBD22A94E6836AD282525CFB2296A1899AE3B56F6EB16E071E1B46518A5AE2A140983FE9150A423192D82E5570413A808A4E6C7FD58DAF60C8378B4079E3AFFF24328893BC4A7E22E4C28B2B000014BA53312D331E15C9C637E4DB3A88070C2B0000144C53427B6D465D1B337BB755A37A7FEF2B000014B4F01CA951E9DA8D0BAFBBD34AD3044E29000014C1DC4350476B98A429B91781914CA43E2900001C000040041C6DA878346BF2143998ED1F0E4057E4FC1C160A2900001C0000400522C7C771572094FB6BE3531F146913EEBB84B08F000000090000F05004
2026-02-27 08:51:30.615988 ike V=root:0:b9b75672829af722/0000000000000000:803712: responder received SA_INIT msg
2026-02-27 08:51:30.616000 ike V=root:0:b9b75672829af722/0000000000000000:803712: VID forticlient connect license 4C53427B6D465D1B337BB755A37A7FEF
2026-02-27 08:51:30.616013 ike V=root:0:b9b75672829af722/0000000000000000:803712: VID Fortinet Endpoint Control B4F01CA951E9DA8D0BAFBBD34AD3044E
2026-02-27 08:51:30.616024 ike V=root:0:b9b75672829af722/0000000000000000:803712: VID Forticlient EAP Extension C1DC4350476B98A429B91781914CA43E
2026-02-27 08:51:30.616035 ike V=root:0:b9b75672829af722/0000000000000000:803712: received notify type NAT_DETECTION_SOURCE_IP
2026-02-27 08:51:30.616045 ike V=root:0:b9b75672829af722/0000000000000000:803712: received notify type NAT_DETECTION_DESTINATION_IP
2026-02-27 08:51:30.616055 ike V=root:0:b9b75672829af722/0000000000000000:803712: received notify type VPN_NETWORK_ID
2026-02-27 08:51:30.616065 ike V=root:0:b9b75672829af722/0000000000000000:803712: NETWORK ID : 4
2026-02-27 08:51:30.616078 ike V=root:0:b9b75672829af722/0000000000000000:803712: incoming proposal:
2026-02-27 08:51:30.616088 ike V=root:0:b9b75672829af722/0000000000000000:803712: proposal id = 1:
2026-02-27 08:51:30.616099 ike V=root:0:b9b75672829af722/0000000000000000:803712: protocol = IKEv2:

<networkid>1</networkid>

 

Like I said, I get that this post is dated, but nay feedback is appreciated

funkylicious
SuperUser
funkylicious
SuperUser
February 28, 2026

maybe its related to network id on the ipsec config for ikev2

"jack of all trades, master of none"
fcb
fcb
Visitor III
February 28, 2026

First off, I know these posts/debugs are long and at times painful but I greatly appreciate the feedback, especially around the "local_gateway" setting in the Proposal of phase1-interface....

 

So, if you are to believe the following Technical Tip  article that was modified last week, in my use case, where I have multiple configured tunnels on the same interface, you must either use certificate-based authentication, or Fortinet's proprietary "networkid" and "network-overlay"  parameters on the gate, as well as <networkid><number><\networkid> that is to be configured in FortiClient's XML. 

 

https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-configure-Network-ID-for-distinguishing/ta-p/429840

 

Here is the debug output from one of my tunnels that work, but I believe it's NOT working because it's matched the "network id", it's working because it was the first tunnel configured on this interface, and the IKE proposals are matching.

Working Tunnel

DR-Edge-400F-01 (root) # 2026-02-26 21:55:25.394297 ike V=root:0: comes 42.0.24.7:1123->12.13.14.15:500,ifindex=31,vrf=0,len=465....
2026-02-26 21:55:25.394346 ike V=root:0: IKEv2 exchange=SA_INIT id=8577b5ec7416df43/0000000000000000 len=465
2026-02-26 21:55:25.394392 ike 0: in 8577B5EC7416DF4300000000000000002120220800000000000001D12200005C0200002C010100040300000C0100000C800E0100030000080200000603300000C0100000C800E0100030
2026-02-26 21:55:25.394426 ike V=root:0:8577b5ec7416df43/0000000000000000:802388: responder received SA_INIT msg
2026-02-26 21:55:25.394438 ike V=root:0:8577b5ec7416df43/0000000000000000:802388: VID forticlient connect license 4C53427B6D465D1B337BB755A37A7FEF
2026-02-26 21:55:25.394450 ike V=root:0:8577b5ec7416df43/0000000000000000:802388: VID Fortinet Endpoint Control B4F01CA951E9DA8D0BAFBBD34AD3044E
2026-02-26 21:55:25.394460 ike V=root:0:8577b5ec7416df43/0000000000000000:802388: VID Forticlient EAP Extension C1DC4350476B98A429B91781914CA43E
2026-02-26 21:55:25.394471 ike V=root:0:8577b5ec7416df43/0000000000000000:802388: received notify type NAT_DETECTION_SOURCE_IP
2026-02-26 21:55:25.394481 ike V=root:0:8577b5ec7416df43/0000000000000000:802388: received notify type NAT_DETECTION_DESTINATION_IP
2026-02-26 21:55:25.394492 ike V=root:0:8577b5ec7416df43/0000000000000000:802388: received notify type VPN_NETWORK_ID
2026-02-26 21:55:25.394502 ike V=root:0:8577b5ec7416df43/0000000000000000:802388: NETWORK ID : 2 FTC is sending the network ID to the gate which has the same id on that tunne.
2026-02-26 21:55:25.394516 ike V=root:0:8577b5ec7416df43/0000000000000000:802388: incoming proposal:
2026-02-26 21:55:25.394527 ike V=root:0:8577b5ec7416df43/0000000000000000:802388: proposal id = 1:
2026-02-26 21:55:25.394535 ike V=root:0:8577b5ec7416df43/0000000000000000:802388: protocol = IKEv2:
2026-02-26 21:55:25.394543 ike V=root:0:8577b5ec7416df43/0000000000000000:802388: encapsulation = IKEv2/none
2026-02-26 21:55:25.394552 ike V=root:0:8577b5ec7416df43/0000000000000000:802388: type=ENCR, val=AES_CBC (key_len = 256)
2026-02-26 21:55:25.394564 ike V=root:0:8577b5ec7416df43/0000000000000000:802388: type=INTEGR, val=AUTH_HMAC_SHA2_384_192
2026-02-26 21:55:25.394572 ike V=root:0:8577b5ec7416df43/0000000000000000:802388: type=PRF, val=PRF_HMAC_SHA2_384
2026-02-26 21:55:25.394580 ike V=root:0:8577b5ec7416df43/0000000000000000:802388: type=DH_GROUP, val=MODP1536.
2026-02-26 21:55:25.394590 ike V=root:0:8577b5ec7416df43/0000000000000000:802388: proposal id = 2:
2026-02-26 21:55:25.394599 ike V=root:0:8577b5ec7416df43/0000000000000000:802388: protocol = IKEv2:
2026-02-26 21:55:25.394606 ike V=root:0:8577b5ec7416df43/0000000000000000:802388: encapsulation = IKEv2/none
2026-02-26 21:55:25.394614 ike V=root:0:8577b5ec7416df43/0000000000000000:802388: type=ENCR, val=AES_CBC (key_len = 256)
2026-02-26 21:55:25.394625 ike V=root:0:8577b5ec7416df43/0000000000000000:802388: type=INTEGR, val=AUTH_HMAC_SHA2_512_256
2026-02-26 21:55:25.394633 ike V=root:0:8577b5ec7416df43/0000000000000000:802388: type=PRF, val=PRF_HMAC_SHA2_512
2026-02-26 21:55:25.394643 ike V=root:0:8577b5ec7416df43/0000000000000000:802388: type=DH_GROUP, val=MODP1536.
2026-02-26 21:55:25.394657 ike V=root:0:8577b5ec7416df43/0000000000000000:802388: matched proposal id 1
2026-02-26 21:55:25.394668 ike V=root:0:8577b5ec7416df43/0000000000000000:802388: proposal id = 1:
2026-02-26 21:55:25.394679 ike V=root:0:8577b5ec7416df43/0000000000000000:802388: protocol = IKEv2:
2026-02-26 21:55:25.394685 ike V=root:0:8577b5ec7416df43/0000000000000000:802388: encapsulation = IKEv2/none
2026-02-26 21:55:25.394692 ike V=root:0:8577b5ec7416df43/0000000000000000:802388: type=ENCR, val=AES_CBC (key_len = 256)
2026-02-26 21:55:25.394698 ike V=root:0:8577b5ec7416df43/0000000000000000:802388: type=INTEGR, val=AUTH_HMAC_SHA2_384_192
2026-02-26 21:55:25.394706 ike V=root:0:8577b5ec7416df43/0000000000000000:802388: type=PRF, val=PRF_HMAC_SHA2_384
2026-02-26 21:55:25.394713 ike V=root:0:8577b5ec7416df43/0000000000000000:802388: type=DH_GROUP, val=MODP1536.
2026-02-26 21:55:25.394719 ike V=root:0:8577b5ec7416df43/0000000000000000:802388: lifetime=86400
2026-02-26 21:55:25.394730 ike V=root:0:8577b5ec7416df43/0000000000000000:802388: SA proposal chosen, matched gateway vpn.Dsegra.user
2026-02-26 21:55:25.394743 ike V=root:0:vpn.Dsegra.user:vpn.Dsegra.user: created connection: 0x560f179b9b60 31 12.13.14.15->42.0.24.7:1123.
2026-02-26 21:55:25.394752 ike V=root:0:vpn.Dsegra.user: HA start as master
2026-02-26 21:55:25.394762 ike V=root:0:vpn.Dsegra.user:802388: processing notify type NAT_DETECTION_SOURCE_IP
2026-02-26 21:55:25.394789 ike V=root:0:vpn.Dsegra.user:802388: processing NAT-D payload
2026-02-26 21:55:25.394800 ike V=root:0:vpn.Dsegra.user:802388: NAT detected: PEER
2026-02-26 21:55:25.394808 ike V=root:0:vpn.Dsegra.user:802388: process NAT-D
2026-02-26 21:55:25.394814 ike V=root:0:vpn.Dsegra.user:802388: processing notify type NAT_DETECTION_DESTINATION_IP
2026-02-26 21:55:25.394830 ike V=root:0:vpn.Dsegra.user:802388: processing NAT-D payload
2026-02-26 21:55:25.394838 ike V=root:0:vpn.Dsegra.user:802388: NAT detected: PEER
2026-02-26 21:55:25.394844 ike V=root:0:vpn.Dsegra.user:802388: process NAT-D
2026-02-26 21:55:25.394851 ike V=root:0:vpn.Dsegra.user:802388: FEC vendor ID received FEC but IP not set
2026-02-26 21:55:25.394858 ike 0:vpn.Dsegra.user:802388: FCT EAP 2FA extension vendor ID received
2026-02-26 21:55:25.394879 ike V=root:0:vpn.Dsegra.user:802388: responder preparing SA_INIT msg
2026-0

 

 

So this is why I'm wondering if I need to add that "remote_gateway" to the tunnel that's not working.. I did just notice that part of my debug from my first post got cut off, but see below  that FTC connects and proposes "network id 4" but the Gate does not match on this, or any proposal, and produces the following:

 

000000000000:803712: NETWORK ID : 4 FTC proposed ID 4
2026-02-27 08:51:30.616078 ike V=root:0:b9b75672829af722/0000000000000000:803712: incoming proposal:
2026-02-27 08:51:30.616088 ike V=root:0:b9b75672829af722/0000000000000000:803712: proposal id = 1:
2026-02-27 08:51:30.616099 ike V=root:0:b9b75672829af722/0000000000000000:803712: protocol = IKEv2:
2026-02-27 08:51:30.616106 ike V=root:0:b9b75672829af722/0000000000000000:803712: encapsulation = IKEv2/none
2026-02-27 08:51:30.616117 ike V=root:0:b9b75672829af722/0000000000000000:803712: type=ENCR, val=AES_CBC (key_len = 256)
2026-02-27 08:51:30.616126 ike V=root:0:b9b75672829af722/0000000000000000:803712: type=INTEGR, val=AUTH_HMAC_SHA2_384_192
2026-02-27 08:51:30.616134 ike V=root:0:b9b75672829af722/0000000000000000:803712: type=PRF, val=PRF_HMAC_SHA2_384
2026-02-27 08:51:30.616145 ike V=root:0:b9b75672829af722/0000000000000000:803712: type=DH_GROUP, val=MODP1536.
2026-02-27 08:51:30.616155 ike V=root:0:b9b75672829af722/0000000000000000:803712: proposal id = 2:
2026-02-27 08:51:30.616163 ike V=root:0:b9b75672829af722/0000000000000000:803712: protocol = IKEv2:
2026-02-27 08:51:30.616171 ike V=root:0:b9b75672829af722/0000000000000000:803712: encapsulation = IKEv2/none
2026-02-27 08:51:30.616182 ike V=root:0:b9b75672829af722/0000000000000000:803712: type=ENCR, val=AES_CBC (key_len = 256)
2026-02-27 08:51:30.616190 ike V=root:0:b9b75672829af722/0000000000000000:803712: type=INTEGR, val=AUTH_HMAC_SHA2_512_256
2026-02-27 08:51:30.616198 ike V=root:0:b9b75672829af722/0000000000000000:803712: type=PRF, val=PRF_HMAC_SHA2_512
2026-02-27 08:51:30.616207 ike V=root:0:b9b75672829af722/0000000000000000:803712: type=DH_GROUP, val=MODP1536.
2026-02-27 08:51:30.616221 ike V=root:0:b9b75672829af722/0000000000000000:803712: my proposal, gw vpn.Dbvu.ne:
2026-02-27 08:51:30.616232 ike V=root:0:b9b75672829af722/0000000000000000:803712: proposal id = 1:
2026-02-27 08:51:30.616243 ike V=root:0:b9b75672829af722/0000000000000000:803712: protocol = IKEv2:
2026-02-27 08:51:30.616250 ike V=root:0:b9b75672829af722/0000000000000000:803712: encapsulation = IKEv2/none
2026-02-27 08:51:30.616256 ike V=root:0:b9b75672829af722/0000000000000000:803712: type=ENCR, val=AES_CBC (key_len = 256)
2026-02-27 08:51:30.616266 ike V=root:0:b9b75672829af722/0000000000000000:803712: type=INTEGR, val=AUTH_HMAC_SHA2_512_256
2026-02-27 08:51:30.616272 ike V=root:0:b9b75672829af722/0000000000000000:803712: type=PRF, val=PRF_HMAC_SHA2_512
2026-02-27 08:51:30.616279 ike V=root:0:b9b75672829af722/0000000000000000:803712: type=DH_GROUP, val=ECP384.
2026-02-27 08:51:30.616287 ike V=root:0:b9b75672829af722/0000000000000000:803712: lifetime=86400
2026-02-27 08:51:30.616296 ike V=root:0:b9b75672829af722/0000000000000000:803712: my proposal, gw vpn.Dbvu.user:
2026-02-27 08:51:30.616304 ike V=root:0:b9b75672829af722/0000000000000000:803712: proposal id = 1:
2026-02-27 08:51:30.616311 ike V=root:0:b9b75672829af722/0000000000000000:803712: protocol = IKEv2:
2026-02-27 08:51:30.616317 ike V=root:0:b9b75672829af722/0000000000000000:803712: encapsulation = IKEv2/none
2026-02-27 08:51:30.616325 ike V=root:0:b9b75672829af722/0000000000000000:803712: type=ENCR, val=AES_CBC (key_len = 256)
2026-02-27 08:51:30.616333 ike V=root:0:b9b75672829af722/0000000000000000:803712: type=INTEGR, val=AUTH_HMAC_SHA2_512_256
2026-02-27 08:51:30.616339 ike V=root:0:b9b75672829af722/0000000000000000:803712: type=PRF, val=PRF_HMAC_SHA2_512
2026-02-27 08:51:30.616349 ike V=root:0:b9b75672829af722/0000000000000000:803712: type=DH_GROUP, val=MODP1536.
2026-02-27 08:51:30.616355 ike V=root:0:b9b75672829af722/0000000000000000:803712: lifetime=86400
2026-02-27 08:51:30.616363 ike V=root:0:b9b75672829af722/0000000000000000:803712: my proposal, gw vpn.Dsegra.ne: (should be matching here)
2026-02-27 08:51:30.616372 ike V=root:0:b9b75672829af722/0000000000000000:803712: proposal id = 1:
2026-02-27 08:51:30.616382 ike V=root:0:b9b75672829af722/0000000000000000:803712: protocol = IKEv2:
2026-02-27 08:51:30.616388 ike V=root:0:b9b75672829af722/0000000000000000:803712: encapsulation = IKEv2/none
2026-02-27 08:51:30.616398 ike V=root:0:b9b75672829af722/0000000000000000:803712: type=ENCR, val=AES_CBC (key_len = 256)
2026-02-27 08:51:30.616404 ike V=root:0:b9b75672829af722/0000000000000000:803712: type=INTEGR, val=AUTH_HMAC_SHA2_384_192
2026-02-27 08:51:30.616411 ike V=root:0:b9b75672829af722/0000000000000000:803712: type=PRF, val=PRF_HMAC_SHA2_384
2026-02-27 08:51:30.616417 ike V=root:0:b9b75672829af722/0000000000000000:803712: type=DH_GROUP, val=MODP1536.
2026-02-27 08:51:30.616427 ike V=root:0:b9b75672829af722/0000000000000000:803712: lifetime=86400
2026-02-27 08:51:30.616435 ike V=root:0:b9b75672829af722/0000000000000000:803712: my proposal, gw vpn.Dsegra.user:
2026-02-27 08:51:30.616444 ike V=root:0:b9b75672829af722/0000000000000000:803712: proposal id = 1:
2026-02-27 08:51:30.616450 ike V=root:0:b9b75672829af722/0000000000000000:803712: protocol = IKEv2:
2026-02-27 08:51:30.616457 ike V=root:0:b9b75672829af722/0000000000000000:803712: encapsulation = IKEv2/none
2026-02-27 08:51:30.616463 ike V=root:0:b9b75672829af722/0000000000000000:803712: type=ENCR, val=AES_CBC (key_len = 256)
2026-02-27 08:51:30.616472 ike V=root:0:b9b75672829af722/0000000000000000:803712: type=INTEGR, val=AUTH_HMAC_SHA2_384_192
2026-02-27 08:51:30.616478 ike V=root:0:b9b75672829af722/0000000000000000:803712: type=PRF, val=PRF_HMAC_SHA2_384
2026-02-27 08:51:30.616486 ike V=root:0:b9b75672829af722/0000000000000000:803712: type=DH_GROUP, val=MODP1536.
2026-02-27 08:51:30.616492 ike V=root:0:b9b75672829af722/0000000000000000:803712: lifetime=86400
2026-02-27 08:51:30.616502 ike V=root:0:b9b75672829af722/0000000000000000:803712: no proposal chosen

 

Terms & ConditionsAccessibility statement