[SOLVED] Problem with multiple masq_dest entries

Hello, multiple masq_dest negate entries don't work on Chaos Calmer via UCI.

For example:

config zone 'rule zone wan'
        list network 'wan'
        option output 'ACCEPT'
        option masq '1'
        option name 'wan'
        option input 'REJECT'
        option forward 'REJECT'
        option mtu_fix '1'
        list masq_dest !
        list masq_dest !

According to this link it was fixed after Chaos Calmer if I'm not mistaken:

Any way to fix that without updgrading the whole firmware? Any workaround outside having to configure iptables manually?

I have a workaround you can try. But you may not like it since it's manually configured iptables rules you add to Custom Rules (/etc/firewall.user). Using ACCEPT in the postrouting_wan_rule chain means it won't reach the MASQUERADE rule last in zone_wan_postrouting.

iptables -t nat -A postrouting_wan_rule -d -j ACCEPT
iptables -t nat -A postrouting_wan_rule -d -j ACCEPT

I can verify that Do Not Equal UCI rules were fixed. I made a similar bug report. But...unless I'm mistaken, I see a major error in your rules...

How are you making TWO Do Not Equal rules for the same condition???

Rules are followed in order and carried-out once the condition applies.

In this instance (unless I've mistaken):

  • a packet for comes through the chain
  • the rule ! is met
  • the device masquerades the packet

I think you should try @mikma's suggestion.

Negated masq_dest entries are translated into -j RETURN rules so that the flow process jumps out of the postrouting chain without further action

1 Like

Yes in the zone_wan_postrouting chain. But RETURN wouldn't work in postrouting_wan_rule since it would return to zone_wan_postrouting where the next rule is MASQUERADE. (postrouting_wan_rule is the chain where you may put custom rules.) Would using RETURN in zone_wan_postrouting instead of ACCEPT in postrouting_wan_rule make a difference anyway?

I understand what you mean but for me UCI would aways ignore the order of configurations and parameters. I would expect the translation to be like mikma's solution. If it's supposed to work the way you say it works then there is no use for this parameter to accept lists.

That worked, thanks!

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.