Can't ping from Internal to SSL-VPN

[graffle]

Hi folks,

I'm a bit new to this, so hoping someone can help.  I have our SSL VPN set up and working decently well:  remote clients can access internal the (single) internal network resources, and also split tunnels through to external resources (e.g. AWS).  So that's working well.  The part I'm struggling with is getting the internal network to access VPN clients.  

I have a policy set up as such:

-----------------------------------

Incoming Interface:  internal

Outgoing Interface: SSL-VPN tunnel interface (ssl.root)

Source: all

Destination: VPN Range

Schedule: always

Service: All

Action: Allow

(This is in addition to the regular SSL-VPN -> internal/wan policies that are working as expected right now)

Internal IP Range: 10.0.1.0/24

VPN IP Range : 10.0.2.0/24

Ping from SSL VPN to Internal is fine (e.g. 10.0.2.123 -> 10.0.1.123)

Ping from Internal to SSL VPN times out (e.g. 10.0.1.123 -> 10.0.2.123)

When I ping from internal to the SSL VPN resource, I can see in FortiClient that the resource is receiving/sending data, and the firewall logs (Windows 10) also shows the ICMP allowed and received:

2019-11-10 11:21:48 ALLOW ICMP xxx.xxx.xxx.xxx 10.0.2.2 - - 0 - - - - 8 0 - RECEIVE

I'm at a bit of a loss, not sure how to proceed from here.  Any help would be really appreciated.

Best,

Graf

[Toshi_Esumi · Accepted solution]

I would run sniffing (diag sniffer packet) on the FGT to see if the ping replies are actually coming back from the client. That would tell if it's on the client side or the FGT side.

[emnoc · Accepted solution]

The tunnel adapter should always be a /32 , what does the routing show? What happens when you do a  {  diag sniffer packet ssl.root "icmp" } ?

Ken Felix

[Toshi_Esumi · Accepted solution]

This doesn't explain the symptom but why you have NAT enabled for ssl.root -> internal policy?

[Toshi_Esumi · Accepted solution]

Get rid of the NAT first. Then I think Ken asked you about the routing table on the client machine "route print" for windows and "netstat -nr" for Mac.

[Toshi_Esumi · Accepted solution]

The remote machine's local subnet is the same 10.0.1.0/24 with the FGT's local subnet. That's why the response to 10.0.1.100 doesn't come in the tunnel. If it's the real subnet at the remote location, you need to change it. Otherwise, you need to set a tricky NAT for the local machine (10.0.1.100) to something else, and inject that IP/subnet to the client's routing table by adjusting split-tunnel subnets in SSL VPN config on the FGT.

[Toshi_Esumi · Accepted solution]

Ok, I was wrong. I was misreading the routing table.

10.0.1.0 255.255.255.0 On-link 10.0.1.43 306 10.0.1.0 255.255.255.0 10.0.2.3 10.0.2.2 1

The lower the metric, the higher the precedence. So returning packet still should come in the tunnel although this is potentially a problem. Because this machine can't even access a local printer when the tunnel is up.

But I have some bad experiences with Windows machines when a local subnet and a remote subnet into a tunnel are the same. I always avoid the conflict. To verify, you can create a new subnet like 10.255.0.0/24 or something on the FGT then set up the split tunnel with this subnet. Then try pinging it from inside of this subnet. I think you would get reply with this set up.

[Toshi_Esumi · Accepted solution]

I would run sniffing (diag sniffer packet) on the FGT to see if the ping replies are actually coming back from the client. That would tell if it's on the client side or the FGT side.

[graffle]

Hi Toshi,

Thank you for the response.  I ran the sniffer between while pinging the two machines, here's what I got back:

# diag sniffer packet internal 'icmp' 1 5 interfaces=[internal] filters=[icmp] 1.791606 10.0.1.100 -> 10.0.2.3: icmp: echo request 2.791165 10.0.1.100 -> 10.0.2.3: icmp: echo request 3.792441 10.0.1.100 -> 10.0.2.3: icmp: echo request 4.802223 10.0.1.100 -> 10.0.2.3: icmp: echo request 5.812401 10.0.1.100 -> 10.0.2.3: icmp: echo request

(no replies coming back).  The machine will respond to pings on its regular network (192.168.1.0/24), but not from the internal network.. I'm at a bit of a loss.

(for context, my end goal is to be able to Remote Desktop into VPN'd machines, but the internal network can't connect to them)

[graffle]

Found this thread:

https://forum.fortinet.com/tm.aspx?m=145375

And from there disabled the NAT on SSL-VPN --> internal, and it works now =)

Thanks!

[graffle]

Ok, next problem :)  The remote computer (on SSL-VPN) won't respond to pings unless I manually set its subnet to 255.255.0.0.  However, each time it reconnects to the VPN, the subnet is changed back to 255.255.255.255.  I understand that this expected, and from the handful of threads I've found suggested a static route to allow the remote computer to respond to pings, but nothing has worked so far.  Any ideas?

[emnoc · Accepted solution]

The tunnel adapter should always be a /32 , what does the routing show? What happens when you do a  {  diag sniffer packet ssl.root "icmp" } ?

Ken Felix

[graffle]

Hi Ken,

Output of diag sniffer:

diag sniffer packet ssl.root 'icmp' interfaces=[ssl.root] filters=[icmp] pcap_lookupnet: ssl.root: no IPv4 address assigned 0.142874 10.0.1.100 -> 10.0.2.2: icmp: echo request 1.147461 10.0.1.100 -> 10.0.2.2: icmp: echo request 2.155535 10.0.1.100 -> 10.0.2.2: icmp: echo request 3.163188 10.0.1.100 -> 10.0.2.2: icmp: echo request 4.168851 10.0.1.100 -> 10.0.2.2: icmp: echo request 5.173410 10.0.1.100 -> 10.0.2.2: icmp: echo request

....

[graffle]

Gah, I really have no idea how to get this to work.  If I force the subnet on the remote VPN machine to /16, the pings are returned.  If it goes back to /32 (as I understand is correct), it's lost.  I've tried adding a static route:

10.0.2.0/24 | ssl.root

but that didn't change anything.  Still no response from the remote machine.  What am I missing here? :\

[graffle]

Digging some more, I have the same problem as the guy from this thread:

https://forum.fortinet.com/tm.aspx?m=110871

Best I can tell we're set up the same, but just in case, this is my setup:

VPN/SSL-VPN Settings:

   Tunnel Mode Client Settings:  Custom IP Ranges (10.0.2.0/24)

VPN/SSL-VPN Portals:

   Enabled Tunnel Mode

         Routing Address: 

               10.0.1.0/24  # Internal 

               10.0.2.0/24  # SSL-VPN

   Source IP Pools:

          10.0.2.0/24 # SSL-VPN

Policy and Objects:

    internal -> ssl.root: 

          (src) 10.0.1.0/24 

          (dst) 10.0.2.0/24

          NAT disabled

          Service: ALL

          Action: ACCEPT

    ssl.root -> internal:

          (src) 10.0.2.0/24

          (dst) 10.0.1.0/24

          NAT enabled

          Service: ALL

          Action: ACCEPT

Network:

     Static Routes:

              (dst) 0.0.0.0/0 | (gateway) xxx.xxx.xxx.xxx | (interface) wan1

              (dst) 10.0.2.0/24 | (gateway) [empty] | (interface) ssl.root

I think what I'm missing is that while the ping reaches the remote machine from internal over ssl.root (e.g 10.0.1.100 --> 10.0.2.2), the reply isn't coming back to the internal machine.  Best I can tell the policy from ssl.root -> internal, and the split tunnel to reach 10.0.1.0/24 should cover that?  

[Toshi_Esumi · Accepted solution]

This doesn't explain the symptom but why you have NAT enabled for ssl.root -> internal policy?