Port Forwarding no longer working after updating to 16.0.1

[Jim.Alles]

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.

I suggest you open a support ticket and also add a feature request to [Suggest Idea].

[jcoffin]

I suggest you open a support ticket and also add a feature request to [Suggest Idea].

Alias having admin GUI was a requested feature so we are unlikely revert the change.

[sky-knight]

Alias having admin GUI was a requested feature so we are unlikely revert the change.

Having the admin GUI on alias addresses was a requested feature?

[PathfinderNetworks]

Alias having admin GUI was a requested feature so we are unlikely revert the change.

Say what? That's insane. I truly cannot fathom a wide-spread enough use case for that to be considered a feature.

[donhwyo]

Especially when there are requests with hundreds of votes and no response other than the default "under consideration".
https://untanglengfirewall.featureupvote.com/

[sky-knight]

And the effect of admin on any alias can be had with a port forward rule...

I guess now the inverse is true, move your service port then make a port forward rule for TCP 443 traffic on whatever IP you want admin to work on to 192.0.2.200 but... come on.

You make the weirdos do the weird configuration, not make everyone else jump through hoops because you want to steal a common service port. This is something you fix with a tech talk, or a white paper, not a fundamental feature shift.

[johnsonx42]

Alias having admin GUI was a requested feature so we are unlikely revert the change.

just because people request something stupid doesn't mean you have to do it

[johnsonx42]

You make the weirdos do the weird configuration, not make everyone else jump through hoops because you want to steal a common service port. This is something you fix with a tech talk, or a white paper, not a fundamental feature shift.

100% agreed... suddenly changing a well understood feature that's worked the same way for a decade or longer just because somebody asked for something weird is just strange.
This all tells me that whoever decided on this feature change either really didn't stop and think it through, or genuinely doesn't understand how this sort of thing should work

[jlficken]

I'm sooooo glad I stumbled onto this thread.

[jcoehoorn]

I've been thinking about this more, and I've come to believe what should really be happening here is that, yes, the admin UI really should respond on any alias... at least by default.

However, the way it's implemented should be different. I want to think of the change conceptually as an invisible port forward rule for each interface (that we can enable/disable with a checkbox, possibly in the per-interface configuration rather than all at once). These rules should logically come after all our other port forward rules. This way we'll see Untangle if we don't have any other 443 forwards defined on the interface. But if we do have a conflicting port forward rule it will take precedence and we see the thing we asked for.

In other words, the problem we have right now is it's as if the Untangle port forward rules come first in the list. It's not that we don't want those rules; it's that we want to come after the ones we define ourselves.

There might also need to be some additional protection, to make sure the admin UI remains available somewhere and help keep a clueless administrator from accidentally doing something silly and locking himself out.