Hi,
I've read the document found here regarding ECMP:
I also read about DSCP and traffic shaping for marking packets. Of course, I also read the page on accessing two WANs:
However, my goal is slightly different. Suppose I have the following:
LAN1 192.168.1.0/24 --- 192.168.1.254 FortiGate 172.16.0.1|172.17.0.1 <-> 172.16.0.2|172.17.0.2 Linux Firewall 192.168.2.254 --- LAN2 192.168.2.0/24
I don't really care if Fortigate load-balances the traffic originated from LAN1 to LAN2 hosts but I do require traffic coming from LAN2 to LAN1 hosts from whichever path (172.16.x.x or 172.17.x.x) to be "routed back through the same interface/path". ie. if 192.168.2.10 opens a tcp connection to 192.168.1.10 through 172.16.0.2 and 172.16.0.1 then the reply packets should be going back through 172.16.0.1 and 172.16.0.2, even though LAN1 Fortigate's default route for LAN2 may be 172.17.0.2.
There's no clear example in the documentation that describes this scenario, as far as I can tell.
In other words, I don't strictly need to configure ECMP on the Fortigate (although I could do so in the future, if requested) but I do require Fortigate to "track incoming connections", mark the packets somehow, and "route back" by the same path the packets came from.
Is this possible? If so, can I get a simple config example?
Thanks
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.
Stuck here.
When a LAN2 host tries to connect to a LAN1 host through one of Fortigate's NICs and FotiGate's default route for LAN2 hosts is via the other interface, replies are lost.
Shouldn't replies go out the same interface the requests came in from?
Thanks
vdp wrote:No, this is basic TCP/IPShouldn't replies go out the same interface the requests came in from?
A package arrives via interface wan1 from 172.16.1.1, heading to internal 192.168.1.100
The client recieves the package and sends a reply to the source IP
The package arrives at the FGT and like every good router it looks up 172.16.1.1 in it's routing table and looks for the most specific route with the lowest distance/metric.
In this case it's wan2
Hence the package will travel via wan2 no matter what the Firewall aspect of the FortiGate (existing session in this case) decides.
This is an intended feature, not a bug.
Hi, Thanks for the feedback. I never said it was a bug but I believe it's a missing feature. On Linux you can use packet marking to achieve this. Here's a quick example according to data given in my first post. eth0: interface name of NIC connected to the first link NIC's IP addr.: 172.16.0.1 gateway to link 1: 172.16.0.2 eth1: interface name of NIC connected to the second link NIC's IP addr.: 172.17.0.1 gateway to link 2: 172.17.0.2 route rules: [...] 10001: from all fwmark 0x2/0xff lookup LNK1 10002: from all fwmark 0x3/0xff lookup LNK2 [...] 20000: from 172.16.0.1 lookup LNK1 20000: from 172.17.0.1 lookup LNK2 [...] 32767: from all lookup default Table LNK1: 172.16.0.2 dev eth0 scope link src 172.16.0.1 default via 172.16.0.2 dev eth0 src 172.16.0.1 Table LNK2: 172.17.0.2 dev eth1 scope link src 172.17.0.1 default via 172.17.0.2 dev eth1 src 172.17.0.1 Then netfilter/iptables is used to mark packets. Table mangle, PREROUTING chain contains: target prot opt in out source destination CONNMARK all -- * * 0.0.0.0/0 0.0.0.0/0 CONNMARK restore mask 0xff routemark all -- eth0 * 0.0.0.0/0 0.0.0.0/0 mark match 0x0/0xff routemark all -- eth1 * 0.0.0.0/0 0.0.0.0/0 mark match 0x0/0xff routemark chain: target prot opt in out source destination MARK all -- eth0 * 0.0.0.0/0 0.0.0.0/0 MARK xset 0x2/0xff MARK all -- eth1 * 0.0.0.0/0 0.0.0.0/0 MARK xset 0x3/0xff CONNMARK all -- * * 0.0.0.0/0 0.0.0.0/0 mark match ! 0x0/0xff CONNMARK save mask 0xff So packets coming in on both eth0 and eth1 are marked and routed back out accordingly. Can this be done somehow with Fortinet products or is it unsupported? Thanks
It would be nice if a FortiOS engineer could pitch in and let me know if what I'm posting can be done with any Fortinet product as it's done with Linux OS routers/firewalls.
At least I'd concentrate on other issues if I knew it "can't be done".
Besides, this feature isn't that strange and can be applied to another situation.
Suppose you have 2 internet providers and 2 WAN interfaces on your router. You want internet hosts to be able to access the same LAN/DMZ server behind the firewall (eg. DNAT) but you want this to happen whether the connection comes in from one provider or the other. So you need to track the connections. Replies must be sent out the interface the request came from.
It's a bit like my scenario except nat is not required.
AFAIK (on Fortinets site, no clue about Linux) the fortinet will build a session, hence packets entering on WAN1 will leave the fortigate on WAN1 as long as there is a (default) route pointing to that interface and the route is in the routing table.
You can have both routes with the same metric, in this case both routes are in the routing table and load balance traffic.
You can prefer a specific interface but keep the other interface open (e.g. for policy routing)
In that case you need to set metric/distance same for both routes (otherwise only on is in routing table and used) and priority different
config router static
edit 1 set device "wan1" set priority 1
edit 2 set device "wan2" set priority 5
Lower priority is prefered. so new traffic will use lowest prio, but the second route will stay in the routing table, hence building up session table.
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.