Some traffic goes through VPN, some other don't

[FredMB]

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

[emnoc · Accepted solution]

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

[FredMB]

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]

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

[FredMB]

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]

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

[FredMB]

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]

More Qs:

Care to explain  wan llb  in your setup?

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

[FredMB]

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]

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