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

HTTPS DNAT Fails

I am completely unable to forward the HTTPS port/service to an internal server.  I confirmed the local portal was both changed port (1443) and disabled.  The HTTP (80) DNAT works, but the server default page immediately redirects to HTTPS.  I get the meta redirect, but the browser hangs and eventually fails.  I have 2 separate NAT rules listed below:

1. Any --> HTTP --> External (WAN) (Address)
   (Internal Server) --> HTTP

2. Any --> HTTPS --> External (WAN) (Address)
   (Internal Server) --> HTTPS

I created matching packet filters rules, even though I checked the "Automatic" box.

I tried a plain HTTP page, and it works, only the HTTPS fails.

I even tried my old Linksys junk home gateway and the connection there works.


This thread was automatically locked due to age.
  • When I attempt to Telnet to the IP on port 443, I simply get a timeout.  The Packet Filter LOG shows no entries pertaining to a failed attempt to connect to the port, or IP.  The IIS log is similar to my experience on the client.  It shows the attempt to connect, then a timeout.  If I go directly to the HTTPS: ssl page, the result is the same as the redirected page.  I am not using OWA/Exchange.  It is a simple web page with a redirector to an SSL log in page.  It works on a simple Linksys home router as well as a simple install of Redhat with ipchains enabled and configured for forwading as needed.  

    An odd occurance...I deleted the DNAT rules and created a NEW rule pointing to a completely different internal server (not Windows) that is simply port 80 (non-SSL).  It worked well.  I disabled - modified this rule to just the HTTPS service and the destination to the previous server - and re-enabled the rule...even after a reboot on the firewall, it continued to direct me to the same non-windows system?????
  • I am trying to replicate your problem but I can't.... which version (major.minor) of the product are you using?
  • I am using Astaro 7.104 installed on a PC (not an appliance).  I have never been able to get a DNAT working with Astaro.  I tried many years ago without success then as well.  I currently have a stand in router until I can get the Astaro working.  I am surprised you can't get a duplication.  I have tried all possibilities to make it work with more than one rule.  That seems to be a limit; one rule per DNAT address.
  • Strange... 
    Can you please issue the following commands in the command line of astaro software and post the output?
    # netstat -an | grep ':443'
    # iptables -t nat -L 

    Also you can try the following, from the command line, in order to check out if forwarding using iptables DNAT rules is working:

    iptables -t nat -A PREROUTING -p tcp -i  -d  --dport 443 --sport 1024:65535 -j DNAT --to :443

    for example:
    iptables -t nat -A PREROUTING -p tcp -i eth1 -d 80.51.22.34 --dport 443 --sport 1024:65535 -j DNAT --to 172.31.1.10:443
    (Don't forget to allow HTTPS traffic from your packet filter rules).
  • I am completely unable to forward the HTTPS port/service to an internal server.  I confirmed the local portal was both changed port (1443) and disabled.  The HTTP (80) DNAT works, but the server default page immediately redirects to HTTPS.  I get the meta redirect, but the browser hangs and eventually fails.  I have 2 separate NAT rules listed below:

    1. Any --> HTTP --> External (WAN) (Address)
       (Internal Server) --> HTTP

    2. Any --> HTTPS --> External (WAN) (Address)
       (Internal Server) --> HTTPS

    I created matching packet filters rules, even though I checked the "Automatic" box.

    I tried a plain HTTP page, and it works, only the HTTPS fails.

    I even tried my old Linksys junk home gateway and the connection there works.


    were you able to resolve your problem? I'm having a very similar issue
  • SWOC, my guess is that you are using an SSL VPN and that you have a conflict.  We normally recommend an 'Additional Address' on the External interface to facilitate access to an internal webserver.  We also prefer explicit packet filter rules instead of the 'Automatic' ones.

    Cheers - Bob