http prioritization over SD-WAN
Dear Watchguard Community,
i am struggling with a confusing problem:
we are using four ports of our Firebox T35.
eth0: external ISP (A) with a static IP (PPPoE)
eth1: Our Trusted Network (10.0.1.1/24)
eth2: external ISP (B) with a static IP
eth4: Local static IP (Gateway: 192.168.1.1, 192.168.1.10/24), this interface is also connected with the second interface (of the modem) of A, to configure the modem over the Webinterface.
eth3: Down
We have configured Multi-WAN (Failover, eth2: primary, eth0: secondary) with one SD-WAN (eth0).
FTP-proxy and HTTPS-proxy policies are running with SD-WAN and it works perfectly fine. All HTTPS and FTP traffic is routed through A, everything else (like UDP Packets) are routed through B.
We have several managed switches in our local (eth1) network and the Webinterface of the modem of A (eth4). All are accessible over http (Webinterface). So far so good.
We also would like to route all http traffic over eth0, but as soon as turning on SD-WAN on the Firewall Policy 'HTTP-proxy' all http traffic is routed through eth0, but we have no access to the Webinterface of the Modem (192.168.1.1) anymore. Ping is working fine on 192.168.1.1. The access to the switches on the trusted network (eth1) is not disturbed (we still have access).
The access to 192.168.1.1 'comes back' after turning off SD-WAN on HTTP-proxy.
I think with default HTTP-proxy settings, the Firebox processes http requests in the following order:
- Trusted
- External Interface, but local IP (192.168.1.1)
- Primary External Interface (eth2)
- Secondary External Interface (eth0)
after activating SD-WAN it seems like the Firebox is processing http request in this order:
- Trusted
- Primary External Interface of SD-WAN (eth0)
Is there a way to make the Firebox act like in the first case, although SD-WAN is active, without adding the 'External Interface with local IP (192.168.1.1)' to the SD-WAN policy?
Comments
For each packet, the 1st policy in your config which matches that packet is used.
So for your case, add a new HTTP policy From: Trusted To: 192.168.1.0/24
Make sure that this is above your current HTTP policy.
ok, thank you for that suggestion. With a new policy like you've described, access to the Webinterface of the Modem (eth4) is possible.
We have one policy for http traffic, it is the unchanged default policy 'HTTP-proxy' of the Firebox:
From: Any-Trusted, Any-Optional,
To: Any-External on
Port: TCP:80
I was wondering why we need a second policy with SD-WAN activated, just to keep the default settings of the global settings (Multi-WAN). I mean, if i would change Multi-WAN to eth0: primary and eth2: secondary, i would have access to the Webinterface of 192.168.1.1, without a second policy, haven't i?.
So it looks like the searching order in global settings (Multi-WAN) for http requests, differs from the searching order for SD-WAN, although HTTP-proxy is the first policy in both cases, isn't it?
The goal is to use as less policies as possible and as much as needed, because it looks like the policy rules doesn't count for VPN traffic (Allow IKEv2-Users).
If i connect over VPN, the rules for HTTPS, HTTP and FTP have no impact for the VPN traffic and if i activate SD-WAN for the 'Allow IKEv2-Users' policy, i have the same problem (no access to 192.168.1.1), what means i would need another policy 'Allow IKEv2-Users' with Trusted to 192.168.1.1.
At the end i would have two policies for accessing the Webinterface of a local external interface from Trusted and VPN network, which i could access without the use of SD-WAN by default.
Is it possible to let SD-WAN keep the default searching order of Multi-WAN (Failover) maintained?
So what is your problem with adding policies or other settings to do what you want?
I have at least 16 HTTP and 19 HTTPS policies to do exactly what I want.
Since my recommendation works - what is the real issue here?
Think about what your current settings do.
"Failover, eth2: primary, eth0: secondary)"
This says that nothing goes out eth0 by default if eth2 is up, unless there is some other setting to cause traffic to go out eth2.
So you have made changes to defeat the default packet handling.
And my recommendation has tweaked those to give you the results that you want.
Feel free to try any other changes to your config to get the results that you want.
Mine do it with minimal changes.
I think your recommendation is the most efficient and easy workaround for this issue and there is no problem in adding two more policies at all. I think i will realize it exactly this way. Thanks again and i appreciate this solution.
What i mean is, that this issue feels more like a bug and not like a customization of functionality, because after customizing im creating an issue which hasn't exist before the change and which i have to fix with policies.
In the default settings everything is working fine (access to 192.168.1.1), the only thing i would like to change is the failover order of the external ISPs with SD-WAN, but after adding this change, the previous functionality (which i have not intended to change) is getting lost suddenly, with no reason. So a solution for this issue could be a fix of SD-WAN policies in future firmware upgrades, where the SD-WAN policy do not lose any previous functionality of Multi-WAN, with other words SD-WAN adopts the functionality of Multi-WAN except of the intended change. Do you know what i mean?
You applied a SD-WAN action on a policy, and the result is not what you wanted, but that is the way that SD-WAN works.
It is not a bug or design issue IMO.
thx for your assessment.
But why is Multi-WAN working in a different way than SD-WAN? I mean if its intended this way, whats the reason for the difference between them? Why would i would like to lose this specific Multi-WAN functionality by using SD-WAN?
SD-WAN can only be used with Multi-WAN.
It provides the ability to control which of the multiple external interfaces is used for specific traffic, and under what circumstances, which can't be done with just Multi-WAN settings.
Thank you for your patience @Bruce_Briggs . Everything works like a charm now.