multiple paths to same destination network

[vdp]

Hi,

I've read the document found here regarding ECMP:

http://docs-legacy.fortinet.com/fos50hlp/50/index.html#page/FortiOS%205.0%20Help/adv_static_routing....

I also read about DSCP and traffic shaping for marking packets. Of course, I also read the page on accessing two WANs:

http://docs-legacy.fortinet.com/cb/html/index.html#page/FOS_Cookbook/Install_advanced/cb_install-dua...

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

[vdp]

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

[gschmitt]

vdp wrote:

Shouldn't replies go out the same interface the requests came in from?

No, this is basic TCP/IP

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.

[vdp]

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

[vdp]

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.

[Jan_Scholten]

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.