Hi,
I have a VPN between 2 Fortigate and I notice a strange behaviour :
Some machines on one network can ping machines on the other side of the VPN while others can't.
Checking in Fortiview / sessions, I discovered that some of them correctly execute the ping through the VPN while the other are trying to connect through WAN (and so it doesn't work).
I configured policies for traffic going from and to the other side of VPN, and route to remote network using the corresponding vpn interface.
In attachment is an example of what happens. My local network is 10.1.0.0/16 and the remote network is 192.168.0.0/16.
Do you have any idea on how to solve this problem ?
THank you very much,
Regards,
Fred
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
What I would do;
run diag debug flow to se what happens
inspect routing table static and PBR to ensure the route is correct for the src/dst
review policyid 1+5 and possible ordering, look for any nat-enable on the policy that does NOT work.
ken
PCNSE
NSE
StrongSwan
What I would do;
run diag debug flow to se what happens
inspect routing table static and PBR to ensure the route is correct for the src/dst
review policyid 1+5 and possible ordering, look for any nat-enable on the policy that does NOT work.
ken
PCNSE
NSE
StrongSwan
Hi,
Thank you for your answer.
The routing table seems to be correct and we don't use PBR.
Static 0.0.0.0/0 87.198.xxx.yyy wan1 100
Connected 10.1.0.0/16 0.0.0.0 internal 00
Connected 10.2.0.0/16 0.0.0.0 vlan_voip 00
Static 10.7.0.0/16 0.0.0.0 vpn_asp 100
Connected 87.198.xxx.yyy/29 0.0.0.0 wan1 00
Static 192.168.0.0/16 0.0.0.0 vpn_evry_1-1 50
Regarding policies :
- policy 1 (default lan to wan) : nat is enabled
- policy 5 (lan to vpn) : nat is disabled (UTM features are also disabled)
Here is an export of diag debug flow :
RT359-201605 # 2016-10-06 16:21:29 id=20085 trace_id=73 func=print_pkt_detail line=4471 msg="vd-root received a packet(proto=1, 10.1.1.51:26853->192.168.200.3:8) from internal. code=8, type=0, id=26853, seq=1." 2016-10-06 16:21:29 id=20085 trace_id=73 func=init_ip_session_common line=4624 msg="allocate a new session-0008b473" 2016-10-06 16:21:29 id=20085 trace_id=73 func=vf_ip4_route_input line=1586 msg="Match policy routing: to 87.198.xxx.yyy via ifindex-5" 2016-10-06 16:21:29 id=20085 trace_id=73 func=vf_ip4_route_input line=1596 msg="find a route: flags=00000000 gw-87.198.xxx.yyy via wan1" 2016-10-06 16:21:29 id=20085 trace_id=73 func=fw_forward_handler line=686 msg="Allowed by Policy-1: SNAT" 2016-10-06 16:21:29 id=20085 trace_id=73 func=ids_receive line=239 msg="send to ips" 2016-10-06 16:21:29 id=20085 trace_id=73 func=__ip_session_run_tuple line=2593 msg="SNAT 10.1.1.51->87.198.xxx.zzz:62464"
87.198.xxx.zzz is the public ip of wan1
87.198.xxx.yyy is the public ip of the gateway of wan1
By the way, I forgot to provide basic informations : Fortigate 60D with FortiOS 5.2.9
Regarding WAN configuration, we use wan load balancing and wan2 is actually administratively disabled.
Hmm. see bold section;
2016-10-06 16:21:29 id=20085 trace_id=73 func=vf_ip4_route_input line=1586 msg="Match policy routing: to 87.198.xxx.yyy via ifindex-5" 2016-10-06 16:21:29 id=20085 trace_id=73 func=vf_ip4_route_input line=1596 msg="find a route: flags=00000000 gw-87.198.xxx.yyy via wan1" 2016-10-06 16:21:29 id=20085 trace_id=73 func=fw_forward_handler line=686 msg="Allowed by Policy-1: SNAT" 2016-10-06 16:21:29 id=20085 trace_id=73 func=ids_receive line=239 msg="send to ips" 2016-10-06 16:21:29 id=20085 trace_id=73 func=__ip_session_run_tuple line=2593 msg="SNAT 10.1.1.51->87.198.xxx.zzz:62464"
If I had to guess this is PBR and matching fwpolcyid1
Can you do a show router policy from the cli ?
ken
PCNSE
NSE
StrongSwan
show router policy in cli displays nothing.
And it is also the case in the web interface where the page Router/Static/Policy Routes is empty.
I'm still bother by the following line from your earlier trace
2016-10-06 16:21:29 id=20085 trace_id=73 func=vf_ip4_route_input line=1586 msg="Match policy routing: to 87.198.xxx.yyy via ifindex-5"
Can you try this & report back .
1>
Craft a /32 host route for the target 192.168.200.3
e.g
edit 2000
set dst 192.168.200.3 255.255.255.255
set device " vpn_evry_1-1 50"
set comment "vpn access diagnostics"
next
2>
Then ping attempt to the same host.
a: does ping work now
b: does the diag debug flow output change ? Does the above "match policy route change in the trace"
ken
PCNSE
NSE
StrongSwan
result is exactly the same as before.
Anyway, I planned to remove wan llb to use failover instead. I hope this will help, with router reboot.
More Qs:
Care to explain wan llb in your setup?
Also is the ONLY traffic blocked, "icmp" (proto1) related?
PCNSE
NSE
StrongSwan
Hi,
Regarding WAN LLB, we have 2 lines and we wanted to split traffic in two parts : mainly web surfing though WAN1 and VOIP through WAN2. I didn't manage to configure this scenario correctly because, for example, VOIP must go trough WAN2 for public SIP trunk and trough a VPN on WAN1 for internal SIP trunk between this agency and our main office.
Regarding traffic blocking, all ports where blocked, not only ICMP. Once the router was rebooted, everything went back to normal.
My guess is that I played earlier with PBR to solve the issues we add with WAN LLB and I think, even if it doesn't appear anywhere, that the router kept some traces of those PBR (did I found a bug ?).
I finally simplified the problem by just configuring WAN failover with route priority as in our main office, which works fine. KISS, as we usually say ;)
Anyway, thanks again for your help.
Fred
Glad you were able to get it fixed. Thanks for reporting back your resolution.
Mike Pruett
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1679 | |
1085 | |
752 | |
446 | |
226 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.