Fortigate 100F ipsec between 2

[supercato]

Hi

I have a strange bug, i have two fortigate f100 with ipsec connection up and runing, I have sslvpn on one ot then allowing me access to the other side.  I can ping all the vms on both side from ssl vpn, I can ping "somes" VM between sites through  ipsec. But I have 3 of them  2 Sice a and 1 side b, that I cannot ping through ipsec ( they are pignable from SSL VPN only ) .

I'm new in this forti brand, any tip will be great.

thank you

[johnathan]

The most common issue with IPsec tunnels where some resources are accessible from one source but not another would be the Phase 2 Selectors. I would make sure these can 'fit' your traffic through. You can alternatively NAT the traffic instead. If you want, you can share what is configured for the policy and tunnel.

[wmichael]

Check the phase2 selectors of tunnel in question and ensure the source and destination networks are configured correctly.

You can also try running a debug flow while pinging.  See step 4 in this article:

https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-First-steps-to-troubleshoot-connecti...

This may show why the traffic is being dropped.

[supercato]

Thanks for the tips, I'll try to see that, but in fact I have some machine that can ping

SITE-A ( subnet 101.x)                 SITE-B (subnet 0.X)    ping

vm1 (101.2)                                            vm-jb  (0.10)      yes (both sides)
vm3 (101.202 )                                       vm-jb (0.10 )     Nope
Vm1 (101.2)                                            vm-qkd (0.153)   nope

By SSLVPN I can ping whatever I want. all working

will check with debug flow.  thanks again

[wmichael]

If it's only one subnet on each side of the tunnel, then most likely the something in phase2 is not matching or something in the firewall policy is not matching.

a debug flow will show what policy allowed the the traffic or if the traffic hit policy-0 (implicit deny) and didn't match any policies.

I would suggest the following debug flow
diag debug flow show function-name enable
diag debug flow filter addr x.x.0.10 <--- set a destination at site B
diag debug flow filter proto 1    <--- sets protocol to icmp
diag debug flow trace start 100
diag debug enable

To disable the debug:

diag debug disable
diag debug reset

Try setting this at site A and ping from one of the devices in the x.x.101.x subnet.
If it looks like the traffic was allowed.  Try setting the same at site B and see if that side is dropping it.

You can also use the sniffer in a CLI console window to see where the traffic is stopping:

diag sniff pack any 'host x.x.0.10 and icmp' 4 0 l

run this on both sides and see if the traffic is making it to side B.

I hope this helps.

[supercato]

Hi thanks again!

here are the results

##########192.168.0.153 ( not responding ping) #######################################

FRT100-02 # exec ping 192.168.0.153
id=20085 trace_id=37 func=print_pkt_detail line=5867 msg="vd-root:0 received a packet(proto=1, 192.168.101.1:5632->192.168.0.153:2048) tun_id=0.0.0.0 from local. type=8, code=0, id=5632, seq=0."
id=20085 trace_id=37 func=init_ip_session_common line=6046 msg="allocate a new session-00110b9f, tun_id=0.0.0.0"
id=20085 trace_id=37 func=ipsecdev_hard_start_xmit line=669 msg="enter IPSec interface IPSECtoEXXAION, tun_id=0.0.0.0"
id=20085 trace_id=37 func=_do_ipsecdev_hard_start_xmit line=229 msg="output to IPSec tunnel IPSECtoEXXAION"
id=20085 trace_id=37 func=esp_output4 line=844 msg="IPsec encrypt/auth"
id=20085 trace_id=37 func=ipsec_output_finish line=544 msg="send to 172.17.26.1 via intf-wan1"
id=20085 trace_id=38 func=print_pkt_detail line=5867 msg="vd-root:0 received a packet(proto=1, 192.168.101.1:5632->192.168.0.153:2048) tun_id=0.0.0.0 from local. type=8, code=0, id=5632, seq=1."
id=20085 trace_id=38 func=resolve_ip_tuple_fast line=5953 msg="Find an existing session, id-00110b9f, original direction"
id=20085 trace_id=38 func=ipsecdev_hard_start_xmit line=669 msg="enter IPSec interface IPSECtoEXXAION, tun_id=0.0.0.0"
id=20085 trace_id=38 func=_do_ipsecdev_hard_start_xmit line=229 msg="output to IPSec tunnel IPSECtoEXXAION"
id=20085 trace_id=38 func=esp_output4 line=844 msg="IPsec encrypt/auth"
PING 192.168.0.153 (192.168.0.153): 56 data bytes

--- 192.168.0.153 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss

[johnathan]

Hmm. This is telling me that it actually exited the tunnel. Are you able to run the same debug on the other side (if it's a FortiGate)?

[wmichael]

id=20085 trace_id=38 func=print_pkt_detail line=5867 msg="vd-root:0 received a packet(proto=1, 192.168.101.1:5632->192.168.0.153:2048) tun_id=0.0.0.0 from local. type=8, code=0, id=5632, seq=1."
id=20085 trace_id=38 func=resolve_ip_tuple_fast line=5953 msg="Find an existing session, id-00110b9f, original direction"
id=20085 trace_id=38 func=ipsecdev_hard_start_xmit line=669 msg="enter IPSec interface IPSECtoEXXAION, tun_id=0.0.0.0"
id=20085 trace_id=38 func=_do_ipsecdev_hard_start_xmit line=229 msg="output to IPSec tunnel IPSECtoEXXAION"

This looks like the packet went out the tunnel, it's possible the remote side is dropping it for some reason.

try running the sniffer on the remote side and see if the packets are coming in from the tunnel.

[supercato]

and this is working

#####192.168.0.10 ###########################################

FRT100-02 # exec ping 192.168.0.10
id=20085 trace_id=42 func=print_pkt_detail line=5867 msg="vd-root:0 received a packet(proto=1, 192.168.101.1:5888->192.168.0.10:2048) tun_id=0.0.0.0 from local. type=8, code=0, id=5888, seq=0."
id=20085 trace_id=42 func=init_ip_session_common line=6046 msg="allocate a new session-00110c1d, tun_id=0.0.0.0"
id=20085 trace_id=42 func=ipsecdev_hard_start_xmit line=669 msg="enter IPSec interface IPSECtoEXXAION, tun_id=0.0.0.0"
id=20085 trace_id=42 func=_do_ipsecdev_hard_start_xmit line=229 msg="output to IPSec tunnel IPSECtoEXXAION"
id=20085 trace_id=42 func=esp_output4 line=844 msg="IPsec encrypt/auth"
id=20085 trace_id=42 func=ipsec_output_finish line=544 msg="send to 172.17.26.1 via intf-wan1"
id=20085 trace_id=43 func=print_pkt_detail line=5867 msg="vd-root:0 received a packet(proto=1, 192.168.0.10:5888->192.168.101.1:0) tun_id=162.25.27.16 from IPSECtoEXXAION. type=0, code=0, id=5888, seq=0."
id=20085 trace_id=43 func=resolve_ip_tuple_fast line=5953 msg="Find an existing session, id-00110c1d, reply direction"
id=20085 trace_id=43 func=vf_ip_route_input_common line=2611 msg="find a route: flag=80000000 gw-192.168.101.1 via root"
PING 192.168.0.10 (192.168.0.10): 56 data bytes
64 bytes from 192.168.0.10: icmp_seq=0 ttl=63 time=6.7 ms

--- 192.168.0.10 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 6.4/6.6/7.0 ms

[supercato]

the remote  side the WAN is  lag interface.... maybe this need some extra config? 

I'm doing the degub on both sides now