Hello, We have a FGT60D router and we have 2 internet connections connected to WAN1 and WAN2. Basically we want to use WAN1 for incoming connections (internet->WAN2->internal) and forward them to internal servers and use WAN2 for office staff to connect internet (internal->WAN2->internet) because WAN1 is an expensive internet (Metro Ethernet fiber line) with 10 Mb/s and the other one is cheap home-use internet with 100 Mbit/s. I don't want a real time load balancing, I can manually switch between WAN2/WAN1 if WAN2 goes down.
So I have; * setup Interfaces for WAN1 and WAN2, * created static routes for wan adapters, * created policy routes for internal->WAN1 (and for WAN2 separately) and on the static route table I set a distance of 50 to WAN1 and 10 to WAN2 so that we can use WAN2 to connect to internet from the office when both lines are up. I did not set any link health monitors because I wanted to keep settings as simple as possible. At first everything went smooth, I manually performed a failover test and unplugged WAN2 and WAN1 immediately took over and we were still on the internet through WAN1. But when the problems started when it comes to forwarding connections from wan to internal. When I take down WAN2, everything works fine, I can ping my WAN2 from external, I can see incoming packets in the Fwd Traffic Log, I can see my policies are working well and I can succesfully forward or deny connections based on our business requirements and policies. When I take WAN2 to UP status, WAN1 stops responding to incoming requests. I don't see any (not a single one) packets in the Fwd Traffic log, I can not even ping my WAN2 adapter from an external host.
I searched and read and tried many things and finally I've figured out that (yet I don't know how to fix it?) WAN2 is actually receiving packets but can not or does not respond them.
This is what I see when I sniff the ICMP packets in the CLI
when WAN2 is down; (xx.xx.xx.178=WAN2 , nn.nn.nn.217=external host) nn.nn.nn.217 -> xx.xx.xx.178: icmp: echo request xx.xx.xx.178 -> nn.nn.nn.217: icmp: echo reply nn.nn.nn.217 -> xx.xx.xx.178: icmp: echo request xx.xx.xx.178 -> nn.nn.nn.217: icmp: echo reply nn.nn.nn.217 -> xx.xx.xx.178: icmp: echo request xx.xx.xx.178 -> nn.nn.nn.217: icmp: echo reply
when WAN2 is UP;
nn.nn.nn.217 -> xx.xx.xx.178: icmp: echo request nn.nn.nn.217 -> xx.xx.xx.178: icmp: echo request nn.nn.nn.217 -> xx.xx.xx.178: icmp: echo request
I have removed static route records one by one also removed policy route records (from internal to WANx) again one by one, I have tried all possible combinations but still no luck. I have changed distances because I suspected that WAN1 can be trying to respond through WAN2 for incoming ICMP packets. To eliminate this possiblity I have started a second sniff in a second CLI session (through SSH) and sniffed WAN1, there was no activity related to my pinging to WAN1.
I appreciate any help to solving this problem.
Sahin
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.
Just a quick info, I think it's all about anti-spoofing.
I played around by enabling assymetric routing and then disabling it and doing some other things and now IT WORKS
But just don't know how :s
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 |
---|---|
1714 | |
1093 | |
752 | |
447 | |
232 |
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.