New Member

Question

Fortigate 100F ipsec between 2

Forum|Forum|1 year ago
October 14, 2024
11 replies
5567 views

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

FortiGate

johnathan

Staff

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.

Never trust a computer you can't throw out a window.

wmichael

Staff

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-connectivity/ta-p/192560

This may show why the traffic is being dropped.

supercatoAuthor

New Member

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

Staff

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.

supercatoAuthor

New Member

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

Staff

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)?

Never trust a computer you can't throw out a window.

supercatoAuthor

New Member

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

supercatoAuthor

New Member

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

I'm doing the degub on both sides now

supercatoAuthor

New Member

id=20085 trace_id=20 func=resolve_ip_tuple_fast line=5953 msg="Find an existing session, id-0002f649, original direction"
id=20085 trace_id=20 func=ipsecdev_hard_start_xmit line=669 msg="enter IPSec interface IPSEC-ED, tun_id=0.0.0.0"
id=20085 trace_id=20 func=_do_ipsecdev_hard_start_xmit line=229 msg="output to IPSec tunnel IPSEC-ED_0"
id=20085 trace_id=20 func=ipsec_common_output4 line=778 msg="No matching IPsec selector, drop"

wmichael

Staff

id=20085 trace_id=20 func=_do_ipsecdev_hard_start_xmit line=229 msg="output to IPSec tunnel IPSEC-ED_0"
id=20085 trace_id=20 func=ipsec_common_output4 line=778 msg="No matching IPsec selector, drop"

Check the phase2 selectors on the IPSEC-ED tunnel. Make sure all subnets that need to communicate are allowed.

supercatoAuthor

New Member

remote site A shows this on debug,. and dont stop scrolling ( I shutdown 102, but nothing changed)

wmichael

Staff

You have to type "diag debug disable" to stop it, and "diag debug reset" to stop all debugs.
It's also showing all the traffic is allowed but is all in the original direction, there is no reply.

I think the issue is the phase2 on remote site B

supercatoAuthor

New Member

check this, it is normal to have to two ipsec tunnel , one with _0

johnathan

Staff

Yep, the tunnel is probably a dialup / dynamic. See: https://docs.fortinet.com/document/fortigate/6.2.16/cookbook/239039/dynamic-tunnel-interface-creation

Never trust a computer you can't throw out a window.

supercatoAuthor

New Member

checking the session list I found this

ofld_fail_reason(kernel, drv): not-established/not-established, IPSec-enc-SA-not-offloaded(6)/IPsec-dec-SA-not-offloaded(7)
npu_state_err=04/04

wmichael

Staff

That message is indicating that the session is not being offloaded.

https://docs.fortinet.com/document/fortigate/7.6.0/hardware-acceleration/734139/diagnose-sys-session-list-and-no-ofld-reason-field-np7-session-information

not-established A TCP session is not in its established state (proto_state=01).

IPsec-enc-SA-not-offloaded

The option npu-offload is disabled in the IPsec Phase 1 or Phase 1 interface configuration that accepted the session. This reason can also appear if the SA cannot be offloaded.

Show more replies

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded