Page 3 of 5 FirstFirst 12345 LastLast
Results 21 to 30 of 43
  1. #21
    Untangle Ninja sky-knight's Avatar
    Join Date
    Apr 2008
    Location
    Phoenix, AZ
    Posts
    25,246

    Default

    Quote Originally Posted by johnsonx42 View Post
    honestly why would anyone want or expect the firewall admin to come up on alias IP's? what would be the point of that?

    It seems like someone tried to "fix" something that wasn't broken in the first place, because they didn't understand how it was supposed to work. another variation of "never remove a fence when you don't understand why it was put up" (Chesterton's Fence)
    The admin shouldn't come up on aliases... but the block pages do need to perhaps come up on aliases on non-WAN interfaces. I suspect the decision to just make Untangle own all IP addresses entirely was made out of either laziness, or a desire for consistency.
    Rob Sandling, BS:SWE, MCP
    NexgenAppliances.com
    Phone: 866-794-8879 x201
    Email: support@nexgenappliances.com

  2. #22
    Newbie
    Join Date
    Jan 2009
    Posts
    3

    Default

    same trouble.
    I just change admin port to 444 and port forward works !
    it was a little freaky but your post save me
    thanks

  3. #23
    Untangle Ninja jcoehoorn's Avatar
    Join Date
    Mar 2010
    Location
    York, NE
    Posts
    1,797

    Default

    Quote Originally Posted by sky-knight View Post
    I suspect the decision to just make Untangle own all IP addresses entirely was made out of either laziness, or a desire for consistency.
    I doubt a decision was made by Untangle at all. Seems more likely to be a behavior inherited from an upstream package where the behavior has changed across Debian releases. That kind of thing isn't always easy to catch, lazy or not.
    Five time Microsoft ASP.Net MVP managing a Lenovo RD330 / E5-2420 / 16GB with Untangle 15.1.0 to protect 500Mbits for ~450 residential college students and associated staff and faculty

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

    Default

    Quote Originally Posted by jcoehoorn View Post
    I doubt a decision was made by Untangle at all. Seems more likely to be a behavior inherited from an upstream package where the behavior has changed across Debian releases. That kind of thing isn't always easy to catch, lazy or not.
    I hadn't considered that, but you're quite right. That would also explain the inconsistency over time as well.
    Rob Sandling, BS:SWE, MCP
    NexgenAppliances.com
    Phone: 866-794-8879 x201
    Email: support@nexgenappliances.com

  5. #25
    Newbie
    Join Date
    Mar 2020
    Posts
    3

    Default

    It should be noted that PRIOR to version 16 we had an access rule to allow HTTPS on WAN to Firewall that included a Destination IP and Destination Port that ALWAYS worked on port 443. All of our other Port Forwarding rule (with other IP's) on port 443 worked without issue, until we upgraded to version 16. So something did change and I'm not sure I understand why!

    Note: The firewall has its OWN IP address and all the other Port Forwarding rule have different IP addresses.

    My question is regardless if the change is Debian or Untangle. WHY would the ACCESS rule not work if it has the Destination IP of the firewall and NO other port forwarding or access rule uses that IP with Port 443 ???

  6. #26
    Untangle Ninja
    Join Date
    Jan 2011
    Posts
    1,322

    Default

    Quote Originally Posted by jcoehoorn View Post
    I doubt a decision was made by Untangle at all. Seems more likely to be a behavior inherited from an upstream package where the behavior has changed across Debian releases. That kind of thing isn't always easy to catch, lazy or not.
    I highly doubt that. The admin is bound to port 443 on an internal IP address, 192.0.2.1. All access to it is provided via a hidden port-forward rule which uses the ports defined in Settings->Network->Services (this is why the Access Rules to allow admin access specify port 443 and port 80, regardless of what is set for the Service ports).
    Until 16.0, that port forward rule specified only traffic destined to the primary WAN and LAN IP addresses would be forwarded to 192.0.2.1; now that hidden rule specifies all traffic gets forwarded regardless of destination IP. This really doesn't seem like the sort of thing that would be changed by a package or Debian release, but rather the port forward rule (really an iptables entry) in the Untangle code has been changed on purpose.

  7. #27
    Untanglit
    Join Date
    Sep 2010
    Posts
    25

    Default

    Thank everyone here for their detective work, I would like to say this blew me up big time today as well, but of course changing the service port fixed it. So weird they made the rule more general, worked great until 16 \_(ツ)_/

  8. #28
    Master Untangler CMcNaughton's Avatar
    Join Date
    Feb 2015
    Location
    Denver, CO
    Posts
    148

    Default

    This would indeed be a weird decision to make..

  9. #29
    Newbie
    Join Date
    Jun 2020
    Posts
    13

    Default

    Quote Originally Posted by epriepke View Post
    I just wanted to chime in and say I had this exact same issue. Untangle updated overnight, all HTTPS was broken. Poked around and eventually found / changed the service port on my own and things started working. Then I hit the google to see if this had turned up for anyone else and found this thread. My config was also working fine until this update, without having changed that service port.
    Same issue, except my service port was already a custom number. Had to change it again to something new to get port forwarding to work again. This thread was a life saver, been banging my head on the wall for 2 days.

  10. #30
    Newbie
    Join Date
    Nov 2018
    Posts
    4

    Default

    I just was burned by this as well. Couple sites, including my own, have a block of WAN IP addresses with multiple services running behind Untangle utilizing those IP addresses configured as alias addresses. For years the port forwarding rule for 443 worked on the alias address regardless of the management port being on 443 on the LAN address for Untangle. Now, with 16.0.1 you've broken that. As others have said, the management ports for Untangle should NOT EVER interfere with the WAN alias addresses. This absolutely must be resolved.

Page 3 of 5 FirstFirst 12345 LastLast

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