Results 1 to 4 of 4
  1. #1
    Join Date
    Jan 2011

    Default Failing to understand port forward rules


    I have an issue where I'm clearley failing to understand how the logic is combined in port forward rules.

    I want to port forward all internal DNS(53) traffic to my own internal DNS server. The DNS server has two IP's and which get assigned over DHCP my untangle. There are a number of devices (mostly Google ones) that ignore this setting and use their own DNS directly. So I have this port forward rule

    Screenshot from 2021-02-11 10-37-07.png

    So, this rule works, and will match a request to for example.., but it will also match a request to (obviously), so I tried to make a modification to the Destination address so as not to forward requests when the destination is

    Destination Address is NOT,

    So, this does not match a DNS(53) request from the internal network to

    IF ( ((SourceInterface == Internal) OR (SourceInterface == Guests) OR (SourceInterface == IoT) OR (SourceInterface == Games) OR (SourceInterface == OpenVPN)) AND ((Protocol == UDP) OR (Protocol = TCP)) AND (DestinationPort = 53) AND ((DestinationAddress != OR (DestinationAddress != )

    The natural language part of my brain thinks this should not match a request from, however the logical part knows the last clause will be TRUE in the case of such a request because !=, so I then tried this:

    Destination Address is NOT

    This had the effect of not matching ANY traffic. So can anyone tell me why a request to Destination IP is not matched by this rule ?, because I'm pretty sure is not in the range (clearly I'm not understanding what's going on here.)

    I also tried an alternative approach to the rule:

    Screenshot from 2021-02-11 10-40-28.png

    This rule did also not match any traffic.., Why ?

    and finally this rule also matches nothing:

    Screenshot from 2021-02-11 11-11-33.png

    Which as far as I can tell means that Destined Local is also not doing what I think it should be (i.e. It matches on traffic destined to the local NG Firewall machine and one of its IPs).. Even when I take ouit the Destined Local condition it still MATCHES NOTHING..., how is this possible when this is the same as the first rule (that works) but with fewer conditions...?
    Last edited by tescophil; 02-11-2021 at 05:43 AM.

  2. #2
    Untangler jcoffin's Avatar
    Join Date
    Aug 2008
    Sunnyvale, CA


    On Layer 3 rules (anything in the Config -> Network), NOT will not correctly work with a list or range of IPs. It does work with a CIDR. It's a limitation of iptables.
    tescophil likes this.
    Attention: Support and help on the Untangle Forums is provided by
    volunteers and community members like yourself.
    If you need Untangle support please call or email

  3. #3
    Untangle Ninja sky-knight's Avatar
    Join Date
    Apr 2008
    Phoenix, AZ


    To be clear it works perfectly as expected... in boolean logic.

    The problem is in this case, boolean logic is bloody nuts!

    When you provide a list in any of Untangle's forward inputs, each of those items in the list is connected with a logical OR. NOT means, to flip the value that's resolved. That is to say, false becomes true, and true becomes false.


    Not ( or

    If it's .10 showing up, that bit is true so the entire bit in the () is true, then NOT shows up and makes it false... rule doesn't fire.

    If it's .11 same thing.

    If it's .12, the or in the ()'s is false... then NOT shows up and now the line resolves as TRUE!

    Because Boolean logic.

    So it's not a limitation of IPTables, it's the way Boolean logic works that IPTables uses, and Untangle slapped a pretty UI over. Fixing it requires the admin to understand this, and adjust his rules accordingly.

    I haven't digested the total of your post OP, so I don't have suggestions just yet... but I'll be back later to look again.

    *Edit* means, so just use that in your original rule, it should cooperate then. CIDR ranges are handled as singular inputs, so you avoid the nested logical structure that causes the problem.
    Last edited by sky-knight; 02-11-2021 at 09:24 AM.
    Kyawa likes this.
    Rob Sandling, BS:SWE, MCP
    Phone: 866-794-8879 x201

  4. #4
    Join Date
    Jan 2011


    Genius, worked perfectly !

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts

SEO by vBSEO 3.6.0 PL2