How to mark packets, dual connections.

[Mbrassesco]

Hi, The problem is that some packets come from interface A, but try to go out to interface B because the network of that packet is known in both interfaces. Can i mark the packet for send it out to the same interface that it come from? Thanks! Marcelo.

[severach]

Sounds you' re trying to run a server behind a dual WAN and want the server to be available to both WAN simultaneously. For some reason the servers internal to the Fortigate know how to return packets to the same interface they came from. Return packets from external servers go through the routing table which will send it out the wrong interface at least half the time and if you' re lucky like me, 100% of the time. Your first try might be to use NAT which turns on many disasters all at once. The Fortigate loses track of all the incoming connections from multiple interfaces and the servers do not receive real IP for logging purposes. What happens is that the first interface to connect allows any number of connections from that interface but no connections from the other interface until the NAT policy expires. I' d like to run the server on multiple ports with each port directed to a specific interface but Policy Based Routing (PBR) won' t filter on source port, only dest port which for the return packets of VIP servers is random. OpenSSH knows how to advertize on multiple ports but most server programs do not. We must choose a filter criteria that PBR and simpleton servers support. The only way I' ve found to support external servers multi wan is to assign 3 IP addresses to the server. 3= 1 + the number of WAN interfaces. This takes advantage of the fact that servers will egress the return packets from the same ip they came in on. IP 1: No policy route otherwise failover, VPN, Virtual IP, and other LAN functions will break unless you' re willing to maintain an extensive PBR table. Because PBR is so high in the pecking order I' m not convinced that any number of policy routes can enable all lan functionality. No VIP. IP 2: PBR -> wan1, wan1 -> VIP IP2 IP 3: PBR -> wan2, wan2 -> VIP IP3 If you' re using failover a 3rd IP for the preferred route may not be necessary. Add a VIP for IP1 and let automatic routing handle the return. We don' t care if the interface fails because nothing will work anyways. Automatic routing of IP1 return packets can go to the wrong interface if you have longer prefix routes to pull traffic away from the main interface. The 3rd IP with its Policy Route ensures this cannot happen. You can make the alternate IPs on a different subnet if you like and assign an alternate IP to your internal interface. Don' t use the alternate IP for other purposes because with the incomplete policy routes they will not play well with the rest of your network. While I have not tested it yet I believe I can run a dyndns client on IP1 and incoming connections will fail over in the time specified by the dyndns provider. I' m open to less terrible methods that function in a rich network environment full of VPN and VIP.