Page 2 of 2 FirstFirst 12
Results 11 to 19 of 19
  1. #11
    Untangler
    Join Date
    Jan 2020
    Location
    San Jose, CA
    Posts
    89

    Default

    Update on the issue:

    * After the install of 15.1 and during/after the restore and reboots and/or restarts of the UVM the problem occurred again.

    * Support confirmed that this issue is known to the dev team, and a fix should come at some later (though unspecified) time (probably with the next release at the earliest), but - when I asked - they wouldn't provide me the Jira ticket number, because "jira information for this ticket is not publicly shareable information".

    * However they did commit to keeping the ticket on hold and letting me know, when a fix is available.

    * In the meantime the best way to temporarily repair this, when it occurs, is apparently to remove all "extra" information from those invalid hosts entries (tags, quotas, etc.), anything that would keep Untangle from expiring the entry.
    Jim.Alles likes this.

  2. #12
    Untangle Ninja Jim.Alles's Avatar
    Join Date
    Jul 2008
    Location
    Central PA
    Posts
    2,523

    Lightbulb Suggested Mitigation

    After some research and testing, I have some more advice.

    This is for a narrow use-case:

    When a device first comes up with a 'wrong' (unintended or temporary) IP address from a DHCP or static assignment, and the device is subsequently assigned a new IP address, you will end up with two instances of the MAC address for the device in the Hosts table. One row for each IP address. This is an illegal condition.

    Mitigation is to make up a bogus MAC address and put that deprecated IP address into [DHCP Server] 'Static DHCP Entries' to reserve it, and it won't get assigned to any other device. Leave it in there until the entry for the initial instance decays in the Hosts table.

    EDIT: Also, understand that this placeholder DHCP reservation will not show up in the Devices or Hosts tables, nor "Current DHCP Leases" of NGFW; as no lease will be assigned - the device does not exist.

    Last edited by Jim.Alles; 09-19-2020 at 12:05 AM. Reason: Yes, I am recommending a kludge.

  3. #13
    Newbie
    Join Date
    Aug 2020
    Posts
    10

    Default

    Is there some reason to not simply use a DHCP reservation for the "bad" device (the TV)?

    This should solve all problems here. The DHCP server won't issue that IP to anything else. The TV will stay on a consistent (known) address, and then is actually easier to firewall off (wouldn't even need to use "tags," could just match on source IP address, i.e. the TV's unchanging DHCP assigned address).

    Also worth noting - underscore is not a proper/valid character in a hostname. Alphanumerics and hyphen are the only "legal" characters. Some implementations stretch this with underscore, but it's not RFC-compliant. (I would link them here but I don't have enough posts: tools.ietf.org/html/rfc952 and tools.ietf.org/html/rfc1123)

    Incidentally, periods also don't belong in a hostname, as they're reserved for the host-domain separation point... I've had to teach this to at least one career "network engineer" who worked for an ISP.

  4. #14
    Untangler
    Join Date
    Jan 2020
    Location
    San Jose, CA
    Posts
    89

    Default

    Quote Originally Posted by Jim.Alles View Post
    When a device first comes up with a 'wrong' (unintended or temporary) IP address from a DHCP or static assignment, and the device is subsequently assigned a new IP address, you will end up with two instances of the MAC address for the device in the Hosts table. One row for each IP address. This is an illegal condition.
    Yes, I have observed that as well.

    Mitigation is to make up a bogus MAC address and put that deprecated IP address into [DHCP Server] 'Static DHCP Entries' to reserve it, and it won't get assigned to any other device. Leave it in there until the entry for the initial instance decays in the Hosts table.
    The problem is that the initial instance won't decay in the hosts table, because it has a tag assigned. All I need to do is to remove the tag for it to disappear, so I don't quite understand what the bogus MAC address with give me.

  5. #15
    Untangler
    Join Date
    Jan 2020
    Location
    San Jose, CA
    Posts
    89

    Default

    Quote Originally Posted by ZPrime View Post
    Is there some reason to not simply use a DHCP reservation for the "bad" device (the TV)?
    Essentially this behavior affects all devices that have a tag assigned, so - yes - as a workaround I could just assign static IP addresses to all my devices with a tag. But I still think that Untangle should fix this.

    This should solve all problems here. The DHCP server won't issue that IP to anything else. The TV will stay on a consistent (known) address, and then is actually easier to firewall off (wouldn't even need to use "tags," could just match on source IP address, i.e. the TV's unchanging DHCP assigned address).
    I rather not create firewall rules by IP address, unless I have to. There's a good reason for those tags to exist, but perhaps they are indeed essentially useless and then this would be a good workaround.

    Also worth noting - underscore is not a proper/valid character in a hostname. Alphanumerics and hyphen are the only "legal" characters. Some implementations stretch this with underscore, but it's not RFC-compliant. (I would link them here but I don't have enough posts: tools.ietf.org/html/rfc952 and tools.ietf.org/html/rfc1123)

    Incidentally, periods also don't belong in a hostname, as they're reserved for the host-domain separation point... I've had to teach this to at least one career "network engineer" who worked for an ISP.
    Thanks, I didn't know that. It seems that Untangle uses a "stretched" implementation, but I'll go ahead and adjust the names.
    Jim.Alles likes this.

  6. #16
    Untangle Ninja Jim.Alles's Avatar
    Join Date
    Jul 2008
    Location
    Central PA
    Posts
    2,523

    Default

    Quote Originally Posted by ZPrime View Post
    Is there some reason to not simply use a DHCP reservation for the "bad" device (the TV)?
    Well, it is more administrative work. We shouldn't have to do work-arounds. You have that option though, of course.

    My bigger concern is that the 'ghost' IP address is still referenced in NGFW, and people have seen that lead to mass confusion in the logic of various rules when it shows up on the network on a different device (MAC address).

    Also worth noting - underscore is not a proper/valid character in a hostname. Alphanumerics and hyphen are the only "legal" characters. Some implementations stretch this with underscore, but it's not RFC-compliant. (I would link them here but I don't have enough posts: tools.ietf.org/html/rfc952 and tools.ietf.org/html/rfc1123)

    Incidentally, periods also don't belong in a hostname, as they're reserved for the host-domain separation point... I've had to teach this to at least one career "network engineer" who worked for an ISP.
    That is all correct. I would also explicitly state that spaces are illegal.
    Code:
    The rules for a host name were first standardized in the original host name specification, 
    "DoD Internet Host Table Specification". 
    It states that the name should be a text string consisting of the letters A through Z (upper or lower case), 
    digits 0 through 9, the minus sign (-), and the period (.). 
    Note, the period is only allowed as the last character of the host name if it is the delimiter of the full domain name (FQDN). 
    No spaces are permitted as part of a name. 
    The first character must be an alphabetic character and the last character must not be a minus sign or period. 
    It was also recommended that the host name be no longer than 24 characters in length. 
    Subsequently, in "Requirements for Internet Hosts - Application and Support", the host name rules were updated. 
    The first character could now be either a letter or a digit and software dealing with host names must handle names up to 63 characters in length.
    From: https://whatismyipaddress.com/hostname
    But there can be slight variations w/ different OSs.

    However, internal NGFW 'hostnames' are not bound to those rules- they never appear on the network.

    There is a lot of room for confusion here - be specific when troubleshooting.
    Here is something to help with that.

    hostname.png
    Last edited by Jim.Alles; 09-22-2020 at 12:37 PM.

  7. #17
    Untangle Ninja Jim.Alles's Avatar
    Join Date
    Jul 2008
    Location
    Central PA
    Posts
    2,523

    Default

    Quote Originally Posted by tangofan View Post
    The problem is that the initial instance won't decay in the hosts table, because it has a tag assigned. All I need to do is to remove the tag for it to disappear, so I don't quite understand what the bogus MAC address with give me.
    In my limited experience/testing, if the tag originates in the devices table, it migrates to the hosts table, and when the deprecated Host entry times-out, the tag won't impede deletion of the row.

    It may have different behavior if the tag was entered in the Hosts table.
    I think I would avoid doing that.

    YMMV

  8. #18
    Untangle Ninja Jim.Alles's Avatar
    Join Date
    Jul 2008
    Location
    Central PA
    Posts
    2,523

    Lightbulb To Untangle engineering:

    I have found another related issue. I am not going to do screenshots here. I expect to open a ticket when I have time.

    But I want to post this in case it resonates with anyone, and as a reminder note to me.

    I just discovered unexpected behavior where adding an entry in config/network/dns-server [Static DNS Entries].
    It appears that stuffs the name into the dnsmasq.leases file, replacing any hostname discovered during DHCP.

    The Static DNS entry should only be creating an additional DNS record. EDIT: ...NOT attaching a name to a MAC address.

    By stuffing it into the lease file that has a unique index key of MAC address; you are relating the new name with only some IP address. Yes, dnsmasq will migrate that name & IP to DNS, but this is not the way to accomplish that.

    Note: this is only based on my perception from observing NGFW behavior, not from looking at the code.
    Last edited by Jim.Alles; 09-22-2020 at 07:27 PM.

  9. #19
    Untangler
    Join Date
    Jan 2020
    Location
    San Jose, CA
    Posts
    89

    Default

    Quote Originally Posted by Jim.Alles View Post
    In my limited experience/testing, if the tag originates in the devices table, it migrates to the hosts table, and when the deprecated Host entry times-out, the tag won't impede deletion of the row.

    It may have different behavior if the tag was entered in the Hosts table.
    I think I would avoid doing that.

    YMMV
    My experience has been a bit different: I add tags in the Devices tab, but that still prevents the deletion for the corresponding deprecated Hosts entry, so I still need to manually remove the tag from such Hosts entries, so that they can be removed.

    I really wish that Untangle would behave like you suggest, i.e. that any "state" in the Hosts tab that can be reconstructed from the Devices tab will be ignored, when deciding on whether to delete the Hosts entry.

Page 2 of 2 FirstFirst 12

Tags for this Thread

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