Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 20 replies
  • Subscribers 2 subscribers
  • Views 7196 views
  • Users 0 members are here
Options
Suggested
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

mutlipath rules don't have any effect

Krycek
Hi,

since this morning the IPS and AV broke down everything seems to be in order again.
BUT my multipath rules don't work anymore!

I have set it up as shown in the attached pictures but I'm still only going out over the "Standleitung netcologne" line. Although surfing on port 80, 8080 and 443 is set to use the "DSL Telekom" line, I try to surf to a site that shows me what IP I come from (What Is My IP Address? Lookup IP, Hide IP, Change IP, Trace IP and more...) it shows me that I'm using the wrong line.

Same problem for SMTP. I noticed this because I got rejected by RDNS checks that of course don't work anymore if it uses the wrong line.

what helps is changing the order of the uplink interfaces. everything goeas out over the first one just as if it was configured like failover. but it is not!

Any ideas?


This thread was automatically locked due to age.
  • 0
    still nothing... traffic only flows through the first interface in the list. multipath rules don't have any effect... I'm really not sure where to look for errors...
  • 0
    Not that it will really help you, however I have a client with a very similar set up. I just tried directing port 80 traffic out their two different ISP's and the site you posted above picked up the two different connection coming from different locations so load balancing was working for them. 

    Their box is now running on v7.504 and pattern 12412. What pattern version has you ASG picked up?
  • 0
    12411 until now... I have called my reseller about this and hope to get an answer to this soon.
  • 0
    I talked to my reseller and I'm actually not very pleased at all...

    They told me I have to use "Uplink primary address --> web surfing --> any --> [interface]" instead of "any --> web surfing --> internet --> [interface]" to bind a certain traffic to one interface... (see attached pic - first rule changed to new pattern - don't know if the other ones work)

    Well it works in the way he told me to do it but I'm not satisfied with that at all. Since it DID WORK in the other way before.

    Why? That doesn't seem right to me but they wouldn't answer the "why do I have to do that? It's basically the same rule - just looks way more confusing and is not exactly what I wanted..."

    Can anyone tell me why that is?

    Getting very frustrated with the ASG lately...
  • 0 in reply to Krycek
    Hi, I am have a similar problem.
    I have setup the Uplink Load Balancing. In Mulitpath Rules, I have setup a rule to redirect all traffic from a VLAN with wireless users to go out to a Ziggo connection. Untill now, I only get our primairy IP address (the one from the main connection which is not the Ziggo one) when I test it on whatismyip.com.
    Have I configured correct,or is it the same problem as Krycek?
    Running version 7.504.
    ScreenShot402.jpg

    ScreenShot403.jpg
  • 0
    this has gotten completely out of hand. This morning I couldn't deliver emails anymore because they all went out over the wrong line. Then I tried to disable uplink balancing and go back to one gateway on which I want the emails to go out on.
    Well it showed me on the WebAdmin that it was disabled, but traffic was STILL going out the other line.
    I could only fix that by rebooting the box. now I'm down to one gateway with all traffic going out through that and waiting for the astaro support to call back...
  • 0
    Systembeheerder, the easy answer is that a packet that doesn't qualify for a traffic selector goes out the default (first) interface.

    I think that, if you're going through the HTTP/S Proxy and using only one External interface, the origin of a packet is the External interface.  For example, before uplink balancing, if one wanted proxied HTTP traffic to leave via a second interface, part of the solution was a SNAT with "External (Address)" as the source in the traffic selector.

    So, if you want the traffic for other subnets to go out a different interface, you can't let them use the proxy - the subnet must be removed from 'Allowed networks' and their traffic allowed by packet filter.
    I believe that Astaro has changed this for the HTTP/S Proxy only (and none of the others).  You now should be able to use traffic selectors for Web Surfing with interior subnets as sources.

    And, Krycek, I don't understand how your SMTP traffic selector worked with proxied traffic before.  (Just as aside, you could add rDNS for the second interface so you don't get rejected if the primary connection for SMTP goes down.)

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0
    why wouldn't it work?

    "any" traffic that uses port 25 "smtp" and wants to go out to "internet" has to use [interface]

    the suggestion I got fromn the reseller was use
    source "(virtual/multipath) uplink interface" --> port 25 --> any --> [interface]

    I don't see how "any" doesn't include the uplink interface. Or am I looking at it the wrong way?

    Oh and btw: registering rdns on that second interface is not possible because it's a dialup connection. Even if it would, 3rd party email servers still reject me because of the dial up-connection beeing in their blaclist.
  • 0
    By way of explanation, here's the comment I got from Alan Toews when I submitted a trouble ticket about packets slipping past an explicit packet filter rule.
    The log provided, shows everything working as intended. The packet was dropped by fwrule 60001, which is the default drop rule for the INPUT chain. 

    It may seem odd that your pf rule didn't match, and instead, hit the default drop rule. The explanation is relatively simple. Packets being sent TO the Astaro are matched against several iptables INPUT chains. packets being sent THROUGH the Astaro, are matched against several iptables FORWARD chains. All rules created in the packet filter are created in the USR_FORWARD chain, so only applied ot packets being forwarded through the Astaro. The packet logged above was trying to reach port 80, which you probably don't have a DNAT rule for. Since Astaro isn't forwarding the packet, it only hits the INPUT chains, and thus doesn't match your rule. This doesn't change the behavior in any way, since the packet is still dropped. If you want to drop these packets also, creating the same pf rule, but with the external address as the destination will put the rule in the USR_INPUT chain, and the packet will match that rule explicitly, instead of the default drop rule.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0
    @ BAlfson,

    I am not using HTTP Proxy at all. should I create a rule that outputs the traffic to the VLAN_Ziggo?
Unfiltered HTML