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

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.
Parents
  • 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
Reply
  • 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
Children
No Data