Unable to ping a different interface

[kyriacoscy]

Hello everyone,

New to fortigate.

I stumble upon a problem. So I have a Fortigate 60F. On interface 5 I have the following network: 172.16.20.0/24 and on interface 2 I have the following network: 172.16.30.0/24. I've created the 2 necessary  policies for communication between the 2 networks ( I will later only give access to certain PCS). On 172.16.20.0/24 network we have a NAS with a static IP of 172.16.20.5. Everything works fine between the 2 networks. The issues arises when a client on 172.16.30.0/24 network, establishes a Open VPN connection with a remote location. All map drives for the NAS works for a while and then everything stops working. Also as soon as the connection is established, the ping stops responding. As soon as the OVPN is disconnected everything is back to normal. At this point I have to tell you that my Firewall is behind NAT but with DMZ to our Firewall. Any input is much appreciated!

[funkylicious]

hi,

it appears that your vpn tunnel while connecting to OpenVPN is full tunnel ( all traffic goes through the tunnel ) and doesn't do a split tunnel.

local traffic doesnt use it's existing local lan but instead tries to reach the NAS via the tunnel.

you can check and verify by doing a, route print -4 , in CMD to see the routing table and then compare while you are connected to it.

[dingjerry_FTNT]

Hi @kyriacoscy ,

I think that this is an issue with your Open VPN connection. 

"establishes a Open VPN connection with a remote location"

This remote location is not behind internal5 or internal2 interfaces, right?

If so, I guess that you have a full tunnel with this Open VPN connection, means all traffic will be directed to the VPN tunnel.

Please check your routing table on the PC once connected to the Open VPN connection.  You may provide it here for us to take a look.

[abarushka]

Hello,

I would recommend to sniff the traffic "diagnose sniffer packet any 'icmp and host <destination IP address>' 4 0 a" while the issue is reproduced and ICMP drops are observed.

Moreover, I would recommend to collect debug flow traces by running the commands below while the issue is reproduced and ICMP drops are observed:

diagnose debug flow filter daddr <destination IP address>
diagnose debug flow filter proto 1
diagnose debug flow show function-name enable
diagnose debug flow trace start 100
diagnose debug enable