IPSec VPN - Select internal hosts unreachable

[Stilty]

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:

IPSec Config:

Policies:

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.

[syordanov]

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]

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]

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]

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]

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.