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.

[graffle]

Hi Toshi,

No particularly good reason - it's just enabled by default so haven't messed with it :\  I've disabled it for ssl.root -> internal, with no change :(

[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.

[graffle]

Oh, I missed that -- thank you.  Here's the route table on the remote machine:

IPv4 Route Table =========================================================================== Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 10.0.1.1 10.0.1.43 50 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 10.0.1.1 255.255.255.255 On-link 10.0.1.43 50 10.0.1.43 255.255.255.255 On-link 10.0.1.43 306 10.0.1.255 255.255.255.255 On-link 10.0.1.43 306 10.0.2.1 255.255.255.255 10.0.2.3 10.0.2.2 1 10.0.2.2 255.255.255.254 10.0.2.3 10.0.2.2 1 10.0.2.2 255.255.255.255 On-link 10.0.2.2 257 10.0.2.4 255.255.255.252 10.0.2.3 10.0.2.2 1 10.0.2.8 255.255.255.248 10.0.2.3 10.0.2.2 1 10.0.2.16 255.255.255.240 10.0.2.3 10.0.2.2 1 10.0.2.32 255.255.255.224 10.0.2.3 10.0.2.2 1 10.0.2.64 255.255.255.192 10.0.2.3 10.0.2.2 1 10.0.2.128 255.255.255.192 10.0.2.3 10.0.2.2 1 10.0.2.192 255.255.255.224 10.0.2.3 10.0.2.2 1 10.0.2.224 255.255.255.240 10.0.2.3 10.0.2.2 1 10.0.2.240 255.255.255.248 10.0.2.3 10.0.2.2 1 10.0.2.248 255.255.255.252 10.0.2.3 10.0.2.2 1 10.0.2.252 255.255.255.254 10.0.2.3 10.0.2.2 1 10.0.2.254 255.255.255.255 10.0.2.3 10.0.2.2 1 13.33.0.0 255.255.0.0 10.0.2.3 10.0.2.2 1 23.0.0.0 255.0.0.0 10.0.2.3 10.0.2.2 1 34.0.0.0 255.0.0.0 10.0.2.3 10.0.2.2 1 50.0.0.0 255.0.0.0 10.0.2.3 10.0.2.2 1 52.0.0.0 255.0.0.0 10.0.2.3 10.0.2.2 1 54.0.0.0 255.0.0.0 10.0.2.3 10.0.2.2 1 xxx.xxx.xxx.xxx 255.255.255.255 10.0.1.1 10.0.1.43 50 107.0.0.0 255.0.0.0 10.0.2.3 10.0.2.2 1 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 174.0.0.0 255.0.0.0 10.0.2.3 10.0.2.2 1 184.0.0.0 255.0.0.0 10.0.2.3 10.0.2.2 1 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.0.1.43 306 224.0.0.0 240.0.0.0 On-link 10.0.2.2 257 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.0.1.43 306 255.255.255.255 255.255.255.255 On-link 10.0.2.2 257 ===========================================================================

(note: xxx.xxx.xxx.xxx is our public ip)

I'm not too sure where the 10.0.2.3 gateway is coming from.  Might that have something to do with it?

[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.

[graffle]

Hm, I'm not sure I'm following entirely :\

>>  If it's the real subnet at the remote location, you need to change it.

Do you mean that I need to change the subnet on the remote pc to 10.0.2.0/24?  Where/how would I do that?  (remote machines _should_ be on 10.0.2.0/24, and I have that range specified in the SSL VPN settings)

>> 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.

The SSL-VPN Portal specifies 10.0.1.0/24 and 10.0.2.0/24 in its routing addresses already (at least, that's what I think you're suggesting?)

[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.

[graffle]

Hi Toshi,

First off, thank you for the help.  You have no idea how much I appreciate it.

Next - I realized my VPN'd machine was connected to the internal WiFi, and so had both an 10.0.1.0/24 ip (on wifi) and 10.0.2.0/24 ip (from sslvpn).  Doh :(

I've since changed the SSLVPN subnet to 10.1.1.0/24, changed the remote computer to a public (off-site) wifi, and vpn'd in.  The remote computer now has an address of 10.1.1.1 / 255.255.255.255.  Pinging from 10.0.1.100 -> 10.1.1.1 still does not come back.  Route table looks like this:

IPv4 Route Table =========================================================================== Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 192.168.43.176 192.168.43.184 35 10.0.1.0 255.255.255.0 10.1.1.2 10.1.1.1 1 10.1.1.0 255.255.255.0 10.1.1.2 10.1.1.1 1 10.1.1.1 255.255.255.255 On-link 10.1.1.1 257 13.33.0.0 255.255.0.0 10.1.1.2 10.1.1.1 1 23.0.0.0 255.0.0.0 10.1.1.2 10.1.1.1 1 34.0.0.0 255.0.0.0 10.1.1.2 10.1.1.1 1 50.0.0.0 255.0.0.0 10.1.1.2 10.1.1.1 1 52.0.0.0 255.0.0.0 10.1.1.2 10.1.1.1 1 54.0.0.0 255.0.0.0 10.1.1.2 10.1.1.1 1 xx.xx.xx.xxx 255.255.255.255 192.168.43.176 192.168.43.184 35 107.0.0.0 255.0.0.0 10.1.1.2 10.1.1.1 1 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 174.0.0.0 255.0.0.0 10.1.1.2 10.1.1.1 1 184.0.0.0 255.0.0.0 10.1.1.2 10.1.1.1 1 192.168.43.0 255.255.255.0 On-link 192.168.43.184 291 192.168.43.176 255.255.255.255 On-link 192.168.43.184 35 192.168.43.184 255.255.255.255 On-link 192.168.43.184 291 192.168.43.255 255.255.255.255 On-link 192.168.43.184 291 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 192.168.43.184 291 224.0.0.0 240.0.0.0 On-link 10.1.1.1 257 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 192.168.43.184 291 255.255.255.255 255.255.255.255 On-link 10.1.1.1 257 ===========================================================================

[Toshi_Esumi · Accepted solution]

Now everything looks normal. Remote access from the client into internal network still works even after some changes you made so far, right? Then I don't have any other idea this wouldn't work. Are you really sure Windows FW is not blocking your pinging at the machine? With a testing like this, I always double-check turning it off completely because it comes back on every time Windows update happens.

[graffle]

Well, I feel dumb :(  The combination of dropping the firewall and ensuring a policy from internal -> ssl.root did it.  Added a rule on the local firewall to allow traffic from 10.0.0.0/8 and I'm golden.

Thank you for the help, Toshi!