This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Conflicts between Masquerading and Multipath rules

We have two uplinks (call them A and B) in load-balancing mode, each with 8 static IPs (call them A.0 thru A.7 and B.0 ... B.7). 

We've been encountering some weird effects / bugs when trying to migrate some outgoing traffic (SMTP, for example) from egressing on A.2 to B.2, and I now believe this to be because the Masquerading Rules were accidentally conflicting with the Multipath Rules.

This leads me wonder what UTM does when you specify (in the Multipath Rules) that traffic from the SMTP server box goes out on interface B, but tell it (in the masquerading rules) to use a source address from interface A (e.g. A.2).

Obviously, if the configuration is fixed, this shouldn't be an issue in normal operation, but I'm asking because I suppose this issue would break any failover setup, wouldn't it?

I've looked for an explanation of how these two things interrelate in the documentation and in the forums, but can't seem to find anything (I may be blind of course). Is there a writeup anywhere about it? Or does anyone know how it works?


This thread was automatically locked due to age.
  • the Masquerading Rules were accidentally conflicting with the Multipath Rules.

    Masq rules don't route traffic out a particular interface, they just replace the source IP with the public IP on the interface.  You would cause no conflict by having two masq rules like 'Internal (Network) -> External-A' and 'Internal (Network) -> External-B'.  In the UTM, the preferred approach is a single rule like ''Internal (Network) -> Uplink Interfaces' unless you want to use specific Additional Addresses on the Interfaces.

    Cheers - Bob
  • Hello BAlfson, thanks very much for replying so quickly.

    Masq rules don't route traffic out a particular interface, they just replace the source IP with the public IP on the interface.  


    So if I have a Masq rule replacing the source IP with public address A.2 (in my example) but send it out on interface B using a Multipath rule, it will do just that, right? But any reply packet (if the ISP even routes my outgoing packet) will come back to interface A, of course. Thus a very bad idea, according to my understanding.

    This behaviour is not really surprising -- it's what you would expect. It fails because the firewall's misconfigured. I know I should have set it to use Uplink Interfaces instead of interface B. 

    But what if it goes out on interface B because interface A died. Is the Masq algorithm smart enough to see it's going out on an unexpected interface and thus insert a different public address?

    You would cause no conflict by having two masq rules like 'Internal (Network) -> External-A' and 'Internal (Network) -> External-B'.  In the UTM, the preferred approach is a single rule like ''Internal (Network) -> Uplink Interfaces' unless you want to use specific Additional Addresses on the Interfaces.

    Actually I do sort of need to use additional addresses -- after all, we pay our ISP for them, so we should be able to send out on them! In our case, we keep individual internal organizations segregated on different IP addresses, even though they all use the same two uplinks. But it seems that automatic failover won't really work properly for outgoing services like SMTP.
  • Afterthought: perhaps I can create 8 pairs of external addresses, so e.g. pair A.0 and B.0 creating an object called "Uplink Interfaces 0", and similarly create Uplink Interfaces .1, .2, and on to .7.

    Then I can route SMTP traffic to "Uplink Interfaces 2" and it will load balance between going out on A.2 and B.2!?
  • So if I have a Masq rule replacing the source IP with public address A.2 (in my example) but send it out on interface B using a Multipath rule, it will do just that, right? [...]  But what if it goes out on interface B because interface A died. Is the Masq algorithm smart enough to see it's going out on an unexpected interface and thus insert a different public address?

    The masq rule for interface A does not apply to traffic that leaves interface B.  That's why you need either a second rule or to use "Uplink Interfaces" in the masq rule as I explained above.

     But it seems that automatic failover won't really work properly for outgoing services like SMTP.

    Yes and no.  You can use Multipath rules for Web Surfing traffic that passes through the Web Filtering Proxy, but not for other proxy traffic.  If you aren't using Email Protection for outbound traffic for one mail server, you can use a Multipath rule for that traffic.  Otherwise, all outbound SMTP traffic that passes through the SMTP Proxy will all leave from the same A-IP on Interface A and the same B-IP on Interface B.

    Afterthought: perhaps I can create 8 pairs of external addresses, so e.g. pair A.0 and B.0 creating an object called "Uplink Interfaces 0", and similarly create Uplink Interfaces .1, .2, and on to .7.

     Then I can route SMTP traffic to "Uplink Interfaces 2" and it will load balance between going out on A.2 and B.2!? 

    It doesn't work like that.  For any one combination of "LAN subnet and WAN interface, you only can have a single masq rule.   If you want to have specific traffic (e.g., SMTP) leave from something other than what's in the masq rule, you override Masquerading with an SNAT.  Again, the Multipath rule determines the interface from which the traffic is sent, and the masq/SNAT determines the IP on that interface that replaces the LAN IP in the packet on the Internet.

    Cheers - Bob
  • Ok, I think I've got it.

    You're saying I set up a first Masq entry (specifying public address A.2), and it will get used when the packet goes out on interface A (because the Multipath rule specifies to use A or specifies "Uplink Interfaces"); then I make a second Masq entry (with public address B.2) which will be used if the packet should happen to go out on interface B (either because of load balancing or fallback because A is dead).

    Right?

    I never thought about using SNAT for this (or at all, really). I'll look into it immediately.

    Thanks again for the help and clarification,
    Paul