Balance 20 not observing Enforced sometimes


#1

I have a Balance 20 which is working fine for most everything. The problem I have is that, for a particular large file (which always is on one particular remote server), it is sometimes downloading from WAN2 instead of WAN1 even though the client is suppose to be Enforced onto WAN1.

I have outbound policies on this client for both IP and MAC address to Enforce on WAN1. If I do something that seems to reset things (like restarting the client, or modify the outbound policy and Apply Changes), then a subsequent download will properly go to WAN1. (I can see where it’s downloading by looking at the real time bandwidth monitoring web page) I had also tried to set a destination to the server domain as enforced on WAN1 but that didn’t seem to help. At the point the problem happens, WAN1 appears to be working fine for other things.

I looked at all the outbound policies, which I have about 15, and all of them are MAC address source specified, so I don’t think I have any conflicts. The only non-MAC address policies are the default HTTS and Normal. The download is http, not https, though it is going over VPN.

I’m running 5.4.4 (1500)


#2

Hi there,

This is definitely unusual behavior for Outbound Policy if there are no apparent conflicting rules. Just to cover some of the Basics, please confirm/update the firmware on the Balance to the latest release and test again. If needed, here’s a link for the update (5.4.7)-

If there are still issues after confirming/updating firmware, go ahead and open a support ticket here

In addition, please capture a diagnostic report from the Balance while the issues are occurring but before rebooting to preserve the Event Logs for review. This will also get us a copy of your configuration file for the team to review and see what, if any, changes are needed.

Instructions on capturing the report of course can be found here

Keep us posted and we’ll go from there with it.


#3

Thanks for the response. I upgraded to the latest 5.4.7 but was able to reproduce the problem early this morning. I gathered the diagnostic file and opened ticket 734003 for this.