Skip to main content
Stilty
New Member
June 17, 2025
Question

IPSec VPN - Select internal hosts unreachable

  • June 17, 2025
  • 2 replies
  • 1289 views

After the update to 7.6.3 and losing SSL vpn, I've been trying to get a new IPSec vpn setup but have been having two issues. First and most importantly, here's the setup of the network:

network2.png

 

IPSec Config:

1.png

2.png

3.png

4.png

5.png

 

Policies:

policies.png

policies2.png

 

Now the issue: I can successfully connect to the vpn and browse the internet. When I try and ping the internal network in the 10.0.0.0/8 range I can with the exception that I can't ping or rdp into WDS (10.91.16.101), nor ping PC1 from WDS. From the remote PC1, I can get to DC06 (10.91.16.100) just fine and ping back PC1.

 

I don't see how anything in the configuration would be blocking specific hosts in the 10.91.16.0/24 range. I'm told that Crowdstrike isn't in the way of this. If anyone could shed some light as to why I can only get to the DC and no other hosts on that network, I'd be grateful.

 

Also, when connecting with an iPhone, the token is never asked for, and I get "The VPN server is not responding". Windows and Mac's get the prompt and can connect.

2 replies

syordanov
Staff
Staff
June 17, 2025

Dear Stilty,

 

I have few questions :

- When your PC1 is connected, what IP address is assigned to it? 

- Because the split tunnel is disabled, can you confirm that the default route on PC1 points towards FortiGate?

- When you do an ICMP to 10.91.16.101 did you capture the traffic using the sniffer?

- If you do an ICMP from FortiGate towards 10.91.16.101 , are you able to get an ICMP reply?

- Because both DC06 and WDS are part of the same broadcast domain and you can ping 10.91.16.100, there could be a problem with routing/return traffic on WDS(missing default route ).

 

My suggestion is to do the following captures when ICMP is running from PC1 towards WDS:

 


#SSH No1:

diagnose debug reset
diagnose debug flow filter saddr XXXXXX <----source IP (PC1)
diagnose debug flow filter daddr YYYYYY <----destination IP (WDS)
diag debug flow show function-name enable
diag debug flow show iprope enable
diagnose debug console timestamp enable
diagnose debug flow trace start 999999
diagnose debug enable


#SSH No2:

diagnose sniffer packet any "host XXXXXX and YYYYYY" 4 0 l <--- replace XXXXXX and YYYYYY with source IP (PC1) and destination IP (WDS)


#SSH No3:

diag sys session filter src XXXXXX <----source IP (PC1)
diag sys session filter dst YYYYYY <----destination IP (WDS)
diag sys session list


SSH No1 will show you if the traffic is allowed or blocked and by which FW rule, SSH No2 how traffic flows between interfaces of your FortiGate and SSH No3 if there a session created for the mentioned flow.

 

Thank you!

 

Best regards,
Fortinet

Stilty
StiltyAuthor
New Member
June 17, 2025

On SSH No1, nothing showed up

FGT3400E # diagnose debug reset FGT3400E # diagnose debug flow filter saddr 10.91.19.49 FGT3400E # diagnose debug flow filter daddr 10.91.16.108 FGT3400E # diag debug flow show function-name enable show function name FGT3400E # diag debug flow show iprope enable show trace messages about iprope FGT3400E # diagnose debug console timestamp enable FGT3400E # diagnose debug flow trace start 99999 FGT3400E # diagnose debug enable

 

SSH No2. was the same, nothing.

FGT3400E # diagnose sniffer packet any "host 10.91.19.49 and 10.19.16.108" 4 0 1 interfaces=[any] filters=[host 10.91.19.49 and 10.19.16.108]

 SSH No3. had the only output.

FGT3400E # diag sys session list  session info: proto=1 proto_state=00 duration=642 expire=42 timeout=0 refresh_dir=both flags=00000000 socktype=0 sockport=0 av_idx=0 use=3 origin-shaper= reply-shaper= per_ip_shaper= class_id=0 ha_id=0 policy_dir=0 tunnel=/ tun_id=0.0.0.0/10.91.19.49 vlan_cos=0/255 user=hotkej_vpn auth_server=EAP_PROXY dst_user=XXXXXX dst_authsvr=FSSO Agent state=log may_dirty npu authed f00 log-start acct-ext statistic(bytes/packets/allow_err): org=9060/151/1 reply=0/0/0 tuples=2 tx speed(Bps/kbps): 25/0 rx speed(Bps/kbps): 0/0 orgin->sink: org pre->post, reply pre->post dev=60->41/41->60 gwy=10.91.16.108/0.0.0.0 hook=pre dir=org act=noop 10.91.19.49:1->10.91.16.108:8(0.0.0.0:0) hook=post dir=reply act=noop 10.91.16.108:1->10.91.19.49:0(0.0.0.0:0) misc=0 policy_id=62 pol_uuid_idx=16577 auth_info=14 chk_client_info=0 vd=0 serial=812a097c tos=ff/ff app_list=0 app=0 url_cat=0 rpdb_link_id=00000000 ngfwid=n/a npu_state=0x000400 ofld-O npu info: flag=0x81/0x00, offload=8/0, ips_offload=0/0, epid=368/0, ipid=1005/0, vlan=0x0000/0x0000 vlifid=1005/0, vtag_in=0x03ce/0x0000 in_npu=2/0, out_npu=2/0, fwd_en=0/0, qid=29/0, ha_divert=0/0 no_ofld_reason: total session: 1

 

All while pinging the WDS server 10.91.16.108 (I have it in the diagram as 10.91.16.101).

 

To answer your questions:

When your PC1 is connected, what IP address is assigned to it? 

A: 10.91.19.49/32

- Because the split tunnel is disabled, can you confirm that the default route on PC1 points towards FortiGate?

A: Output from route print

=========================================================================== Interface List  23...00 09 0f fe 00 01 ......Fortinet Virtual Ethernet Adapter (NDIS 6.30)   4...c0 25 a5 40 cc 48 ......Realtek PCIe GbE Family Controller  15...00 09 0f aa 00 01 ......Fortinet SSL VPN Virtual Ethernet Adapter  13...cc d9 ac 5c 90 fe ......Intel(R) Wi-Fi 6 AX201 160MHz   1...........................Software Loopback Interface 1 =========================================================================== IPv4 Route Table =========================================================================== Active Routes: Network Destination        Netmask          Gateway       Interface  Metric           0.0.0.0          0.0.0.0      10.91.19.50      10.91.19.49      2           0.0.0.0          0.0.0.0      192.168.0.1    192.168.0.154     35       10.91.19.49  255.255.255.255         On-link       10.91.19.49    257         127.0.0.0        255.0.0.0         On-link         127.0.0.1    331         127.0.0.1  255.255.255.255         On-link         127.0.0.1    331   127.255.255.255  255.255.255.255         On-link         127.0.0.1    331       192.168.0.0    255.255.255.0         On-link     192.168.0.154    291     192.168.0.154  255.255.255.255         On-link     192.168.0.154    291     192.168.0.255  255.255.255.255         On-link     192.168.0.154    291      192.168.79.0    255.255.255.0         On-link      192.168.79.1    291      192.168.79.1  255.255.255.255         On-link      192.168.79.1    291    192.168.79.255  255.255.255.255         On-link      192.168.79.1    291     192.168.254.0    255.255.255.0         On-link     192.168.254.1    291     192.168.254.1  255.255.255.255         On-link     192.168.254.1    291   192.168.254.255  255.255.255.255         On-link     192.168.254.1    291    OUR VPN IP      255.255.255.255      192.168.0.1    192.168.0.154     35         224.0.0.0        240.0.0.0         On-link         127.0.0.1    331         224.0.0.0        240.0.0.0         On-link       10.91.19.49    257         224.0.0.0        240.0.0.0         On-link     192.168.0.154    291         224.0.0.0        240.0.0.0         On-link      192.168.79.1    291         224.0.0.0        240.0.0.0         On-link     192.168.254.1    291   255.255.255.255  255.255.255.255         On-link         127.0.0.1    331   255.255.255.255  255.255.255.255         On-link       10.91.19.49    257   255.255.255.255  255.255.255.255         On-link     192.168.0.154    291   255.255.255.255  255.255.255.255         On-link      192.168.79.1    291   255.255.255.255  255.255.255.255         On-link     192.168.254.1    291 =========================================================================== Persistent Routes:   Network Address          Netmask  Gateway Address  Metric           0.0.0.0          0.0.0.0       10.91.24.2  Default =========================================================================== Persistent Routes:   None

- When you do an ICMP to 10.91.16.101 did you capture the traffic using the sniffer?

A: No output was displayed from the SSH No2 command

- If you do an ICMP from FortiGate towards 10.91.16.101 , are you able to get an ICMP reply?

A: Yes

 

From PC1, when I trace route to the DC it hits it in 2 hops. When trying 10.91.16.101 it times out after the first hop.

 

syordanov
Staff
Staff
June 25, 2025

Dear @Stilty,

 

Thanks for the update. On FW policy No62 is it possible to enable the SNAT and use outgoing interface for SNAT, if that is not possible, to the following test :


SSH No1:

execute ping-options source 10.91.19.49

execute ping-options repeat-count 30

execute ping 10.91.16.108

 

SSH No2:

diagnose sniffer packet any " host 10.91.16.108 and host 10.91.19.49" 4 0 l 

 

 

This test will prove if there is a problem with return traffic or missing routing on the server 10.91.16.108.

 

Best regards,

Fortinet.

dukalma1
New Member
June 25, 2025

I can't think of much here, it looks like you've done all you should need to do. The only thing I can think of is an iptables PREROUTING rule that's mangling the packets.

Richie_C
Staff
Staff
June 25, 2025

Hi @Stilty 

 

The output from the 'diag session list' seems to indicate possible one directional traffic. I would start by checking you have the correct default gateway on the server and anything else with connectivity issues.

 

I hope that helps.