- Issue a ping to the LAN network to check for connectivity, and it times out:
Pinging 192.192.192.191 with 32 bytes of data:
Request timed out.
Request timed out.
A debug flow is run on the FortiGate, issuing a ping from the client. The traffic is hitting the firewall, but it is being dropped:
Challenger-kvm44 # diagnose debug flow filter addr 20.20.20.1
Challenger-kvm44 # diagnose debug flow filter proto 1
Challenger-kvm44 # diagnose debug console timestamp enable
Challenger-kvm44 # diagnose debug flow trace start 999
Challenger-kvm44 # diagnose debug enable
Challenger-kvm44 # 2024-01-26 14:41:11 id=65308 trace_id=1 func=print_pkt_detail line=5885 msg="vd-root:0 received a packet(proto=1, 20.20.20.1:1->192.192.192.191:2048) tun_id=20.20.20.1 from IPsec_VPN. type=8, code=0, id=1, seq=30."
2024-01-26 14:41:11 id=65308 trace_id=1 func=init_ip_session_common line=6071 msg="allocate a new session-00dae7a0, tun_id=20.20.20.1"
2024-01-26 14:41:11 id=65308 trace_id=1 func=__vf_ip_route_input_rcu line=1999 msg="find a route: flag=80000000 gw-0.0.0.0 via root"
2024-01-26 14:41:11 id=65308 trace_id=1 func=__iprope_tree_check line=524 msg="gnum-100004, use int hash, slot=101, len=2"
------------truncated-------------------------
id=65308 trace_id=1 func=__iprope_user_identity_check line=1668 msg="ret-no-match" --> (This line indicates that there is an issue with user authentication)
----------------truncated-----------------------
2024-01-26 14:41:11 id=65308 trace_id=1 func=fw_local_in_handler line=616 msg="iprope_in_check() check failed on policy 0, drop"
2024-01-26 14:41:22 id=65308 trace_id=2 func=print_pkt_detail line=5885 msg="vd-root:0 received a packet(proto=1, 20.20.20.1:1->192.192.192.191:2048) tun_id=20.20.20.1 from IPsec_VPN. type=8, code=0, id=1, seq=31."
In the policy, there is the correct configuration to allow traffic from the tunnel to our LAN network:
config firewall policy
edit 2
set name "IPsec_VPN_Policy"
set srcintf "IPsec_VPN"
set dstintf "port3"
set action accept
set srcaddr "IPsec_VPN_range"
set dstaddr "LAN"
set schedule "always"
set service "ALL"
set groups "Test_dialup" <----- The user group is being referenced in policy.
next
end
The Dialup IPsec VPN has been configured and is listening on port1 and the WAN interface. It is possible to connect successfully:
config vpn ipsec phase1-interface
edit "IPsec_VPN"
set type dynamic
set interface "port1"
set mode aggressive
set peertype any
set net-device disable
set mode-cfg enable
set proposal aes128-sha256 aes256-sha256 aes128-sha1 aes256-sha1
set comments "VPN: IPsec_VPN (Created by VPN wizard)"
set wizard-type dialup-forticlient
set xauthtype auto
set authusrgrp "Test_dialup" <----- The user group is also being referenced and chosen in IPSec configuration.
set ipv4-start-ip 20.20.20.1
set ipv4-end-ip 20.20.20.10
set dns-mode auto
set ipv4-split-include "IPsec_VPN_split"
set save-password enable
next
end
Solution:
If the dial-up VPN configuration is set to 'Choose' a user group, it is necessary to remove the user group from our firewall policy.
- Remove the user group from the firewall policy:
config firewall policy
edit 2
unset groups
Or, if the dial-up VPN is using 'inherit from policy', make sure that the firewall policy is referencing the correct user group.
- Change the xauth to 'inherit from policy':
config vpn ipsec phase1-interface
edit <vpn name>
unset authusrgrp
end
Pinging 192.192.192.191 with 32 bytes of data:
Reply from 192.192.192.191: bytes=32 time<1ms TTL=255
Reply from 192.192.192.191: bytes=32 time<1ms TTL=255
Related article:
Technical Tip: No bytes are received when connected to IPSEC dialup VPN using FortiClient
Technical Tip: IPsec dial-up full tunnel with FortiClient
|
