Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 14 replies
  • Subscribers 2 subscribers
  • Views 3080 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

6.300 port forward problem.

Simon Shaw
Patched up to 6.300 today and now my companies web mail and outlook is no longer accessible.

I have an additional IP on external interface, this is supposed to NAT through to our Exchange server, instead, the firewall web admin interface is loading instead!  Argh.  Any ideas??

PS: I suggest a reboot for this patch too, after applying it, CPU usage went very high.  Had to reboot to fix it.


This thread was automatically locked due to age.
Parents
  • 0
    Further to this, if I change the webmin port to something other than 443 my webmail works... (Which uses port 443).

    So this is a workaround that fixes the issue.

    Looks like NAT prioritys are screwed?
  • 0 in reply to Simon Shaw
    Further to this, if I change the webmin port to something other than 443 my webmail works... (Which uses port 443).

    So this is a workaround that fixes the issue.

    Looks like NAT prioritys are screwed?


    I don't know about that.. that was a problem from before (Version 6, at least).. we always just change the Webadmin port if we're going to have a customer host an SSL site or service behind the firewall.  The downside of doing that right now is that the new ACC software doesn't support different ports for SSO login.

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

Reply
  • 0 in reply to Simon Shaw
    Further to this, if I change the webmin port to something other than 443 my webmail works... (Which uses port 443).

    So this is a workaround that fixes the issue.

    Looks like NAT prioritys are screwed?


    I don't know about that.. that was a problem from before (Version 6, at least).. we always just change the Webadmin port if we're going to have a customer host an SSL site or service behind the firewall.  The downside of doing that right now is that the new ACC software doesn't support different ports for SSO login.

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

Children
  • 0 in reply to BrucekConvergent
    Binding 2 services to one ip and port dosn't work to well ;-).

    It can work, but it dosn't have to. Like you could survive a jump from a 50m cliff, but I wouldn't count on that.
  • 0 in reply to NimmdirKeks
    Binding 2 services to one ip and port dosn't work to well.


    Yes, I totally agree - So, I've had a lot of luck in the past [;)] I wasn't aware that the port used by WebAdmin is bound to all configured IP's... So, this is what your're talking about or am I wrong?

    Regards,
    Simeon
  • 0 in reply to Big-Cheese
    NAT occures before the packetfilter, so in theory in normaly could work, because the packet would get mangled before it reaches the WebAdmin port on the firewall. But as you see, a little code tweaking and it stops working.
  • 0 in reply to NimmdirKeks
    Yep--you've been lucky.. during the ACE training, we were told to change the port in the event that we were going to host anything on port 443 behind the Astaro.. so that's how we've been installing them.

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

  • 0 in reply to BrucekConvergent
    Aha - Thanks for your advice... So I leave the WebAdmin port changed [:)]
  • 0 in reply to Big-Cheese
    Although I agree that this stops people from locking themselves out of Webmin on the interfaces, mine is an additional IP bound to that interface.

    Surely it is not right that Webmin auto binds to any new IP address added to an interface?  This seems to be a bit of a security hole too.

    In my opinion, Webmin should NOT bind to additional added IP addresses.  This would also fix the broken functionality for port forwarding.
  • 0 in reply to Simon Shaw
    Have spoken with support.  They may be changing this but it depends on feedback.  They may make an option for what interface IP's it listens on for webmin but we'll just have to see.
  • 0 in reply to Simon Shaw
    Hi there all, 

    let me give a small insight about this..

    We had a lot of issues in the past where people tried out NAT and did a DNAT rule:

    Any x Any x Any -> webserver

    and the whole system was gone, webadmin could not he accessed and system needed to be RMAed.

    We now added this 'don't DNAT webadmin traffic rule, only if there is at least one DNAT rule configured, that uses the service "Any", which would block webadmin access.

    If you are sure what you are doing, than there is a workaround by replacing the 'Any' service with a 'TCP_UDP_all' service. This leads to same expected NAT behavior, but does not create the  'protect webadmin' rule.

    hope that helps, 

    regards
    Gert
  • 0 in reply to Gert Hansen
    Why can't you simply force all https port 443 (or whatever the WebAdmin port is) traffic to each real interface to WebAdmin instead of all https traffic to any interface.

    If you had rules which did this that would solve everyone's problems. 

    WebAdmin can't be locked out, you can keep WebAdmin on port 443 and port 443 NAT to addresses other than the primary address on each NIC would still work.

    This change came as quite a surprise to us and brought us some unexpected downtime while we tried to track this down. Something this significant surely should have been mentioned in the release notes!!!
  • 0 in reply to drees
    Agreed, it broke all our email services to external users [:(]

    I see how some users can break their access to the system this way, however, and may I be blunt here.  If you are silly enough to create such a rule perhaps you shouldn't be setting up the firewall in the first place as I doubt you'd know enough to configure it correctly.

    A nicer option would be in the Web admin options, create a new config for which IP's Webmin is to listen on and have those rules overide all others?

    Gert's suggestion is a decent one, but a bit tricky to remember for new players.

    In any case I don't think Webmin should be binding to any new IP you add by default...
Cookie Information Banner