Fortinet Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
FredMB
New Contributor

Some traffic goes through VPN, some other don't

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

1 Solution
emnoc
Esteemed Contributor III

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  

View solution in original post

10 REPLIES 10
emnoc
Esteemed Contributor III

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  

FredMB
New Contributor

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.

 

 

emnoc
Esteemed Contributor III

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  

FredMB
New Contributor

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.

emnoc
Esteemed Contributor III

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  

FredMB
New Contributor

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.

emnoc
Esteemed Contributor III

More Qs:

 

Care to explain  wan llb  in your setup?

 

Also is the  ONLY traffic blocked, "icmp" (proto1) related?

 

PCNSE 

NSE 

StrongSwan  

FredMB
New Contributor

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

 

 

MikePruett
Valued Contributor

Glad you were able to get it fixed. Thanks for reporting back your resolution.