Results 1 to 4 of 4
  1. #1
    Untangler
    Join Date
    Jan 2011
    Posts
    92

    Default Failing to understand port forward rules

    Hi,

    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 192.168.100.10 and 192.168.100.11 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 8.8.8.8 for example.., but it will also match a request to 192.168.100.11 (obviously), so I tried to make a modification to the Destination address so as not to forward requests when the destination is 192.168.100.11:

    Destination Address is NOT 192.168.100.10,192.168.100.11

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

    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 != 192.168.100.10) OR (DestinationAddress != 192.168.100.11)) )

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

    Destination Address is NOT 192.168.100.10-192.168.100.11

    This had the effect of not matching ANY traffic. So can anyone tell me why a request to Destination IP 8.8.8.8 is not matched by this rule ?, because I'm pretty sure 8.8.8.8 is not in the range 192.168.100.10-192.168.100.11 (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
    Location
    Sunnyvale, CA
    Posts
    9,385

    Default

    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 support@untangle.com

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

    Default

    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.

    So...

    Not (192.168.100.10 or 192.168.100.11)

    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* 192.168.100.10/31 means 192.168.100.10-11, 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
    NexgenAppliances.com
    Phone: 866-794-8879 x201
    Email: support@nexgenappliances.com

  4. #4
    Untangler
    Join Date
    Jan 2011
    Posts
    92

    Default

    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