|
This article describes an issue when a remote user cannot connect to the dialup VPN from FortiClient and IKE debug outputs give the following error messages (outputs truncated). In this example, IKEv2 is being used.
Note:
Starting from v7.4.1, the 'diagnose vpn ike log-filter' command has been changed to 'diagnose vpn ike log filter'.
FortiGate # diagnose vpn ike log filter rem-addr4 x.x.x.x <----- x.x.x.x is the client public IP
FortiGate # diagnose vpn ike log-filter name Dialup
FortiGate # diagnose debug application ike -1
Debug messages will be on for 30 minutes.
FortiGate # diagnose debug enable
FortiGate # diagnose debug disable ---------to disable the debugs
ike 0: comes 192.168.10.2:500->192.168.10.1:500,ifindex=5,vrf=0.... <----- Connection started.
ike 0:Dialup:50: responder received AUTH msg
ike 0:Dialup:50: auth verify done
ike 0:Dialup:50: responder AUTH continuation
ike 0:Dialup:50: authentication succeeded <----- Authentication succeeded.
ike 0:Dialup:50: responder creating new child
ike 0:Dialup:50: mode-cfg type 1 request 0:''
ike 0:Dialup: mode-cfg allocate 172.16.1.1/0.0.0.0 <----- 172.16.1.1 was assigned to the client.
ike 0:Dialup:50: mode-cfg using allocated IPv4 172.16.1.1
ike 0:Dialup:50:32: peer proposal:
ike 0:Dialup:50:32: TSi_0 0:0.0.0.0-255.255.255.255:0
ike 0:Dialup:50:32: TSr_0 0:0.0.0.0-255.255.255.255:0
ike 0:Dialup:50:Dialup:32: comparing selectors
ike 0:Dialup:50:Dialup:32: matched by rfc-rule-4
ike 0:Dialup:50:Dialup:32: phase2 matched by intersection
ike 0:Dialup:50:Dialup:32: using mode-cfg override 0:172.16.1.1-172.16.1.1:0
ike 0:Dialup:50:32: remote selectors don't match
ike 0:Dialup:50:32: my proposal: <----- Phase 2 Selectors of the FortiGate.
ike 0:Dialup:50:32: TSi_0 0:172.16.4.0-172.16.4.255:0 <----- Remote Address.
ike 0:Dialup:50:32: TSr_0 0:192.168.20.0-192.168.20.255:0 <----- Local Address.
ike 0:Dialup:50:Dialup:32: error constructing dialup selectors
ike 0:Dialup:50::32: failed to match peer selectors
ike 0:Dialup:50: responder preparing AUTH msg
ike 0:Dialup: adding new dynamic tunnel for 192.168.10.2:500
ike 0:Dialup_0: tunnel created tun_id 172.16.1.1/::10.0.0.7 remote_location 0.0.0.0
ike 0:Dialup_0: added new dynamic tunnel for 192.168.10.2:500
ike 0:Dialup_0:50: established IKE SA a3d8cab174bee21e/46ab029f2c49791a
ike 0:Dialup_0:50: check peer route: if_addr4_rcvd=0, if_addr6_rcvd=0, mode_cfg=1
ike 0:Dialup_0:50: processing INITIAL-CONTACT
ike 0:Dialup_0: flushing
ike 0:Dialup_0: flushed
ike 0:Dialup_0:50: processed INITIAL-CONTACT
ike 0:Dialup_0:50: mode-cfg assigned (1) IPv4 address 172.16.1.1
ike 0:Dialup_0:50: mode-cfg assigned (2) IPv4 netmask 255.255.255.255
ike 0:Dialup_0:50: mode-cfg send (13) 0:192.168.20.0/255.255.255.0:0
ike 0:Dialup_0:50:32: traffic selectors unacceptable
In the example above, 172.16.1.1 was assigned to the client. However, the 'Remote Address' under phase 2 selectors is 172.16.4.0/24, which does not include 172.16.1.1. Below is an example configuration on the GUI.
|
