Port Forwarding no longer working after updating to 16.0.1

Quote:

---

Originally Posted by johnsonx42

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.

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

Quote:

---

Originally Posted by sky-knight

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.

Quote:

---

Originally Posted by jcoehoorn

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.

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 ???

Quote:

---

Originally Posted by jcoehoorn

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.

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 ¯\_(ツ)_/¯

This would indeed be a weird decision to make.. :cool:

Quote:

---

Originally Posted by epriepke

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.

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.