Skip to main content
graffle
graffle
New Member
November 10, 2019
Solved

Can't ping from Internal to SSL-VPN

  • November 10, 2019
  • 3 replies
  • 36772 views

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

    Best answer by Toshi_Esumi

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

    3 replies

    Toshi_Esumi
    SuperUser
    Toshi_Esumi
    SuperUser
    November 10, 2019

    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
    graffleAuthor
    New Member
    November 13, 2019

    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
    graffleAuthor
    New Member
    November 13, 2019

    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
    graffleAuthor
    New Member
    November 13, 2019

    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
    emnoc
    New Member
    November 13, 2019

    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
    graffleAuthor
    New Member
    November 14, 2019

    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
    SuperUser
    Toshi_EsumiAnswer
    SuperUser
    November 14, 2019

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

    graffle
    graffleAuthor
    New Member
    November 15, 2019

    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 :(

    Terms & ConditionsAccessibility statement