Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 9 replies
  • Subscribers 2 subscribers
  • Views 6068 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

Port 443 DNAT not working for LAN

swoc
I have 2 IP aliases assigned to my external interface and have DNAT rules setup to forward port 80 and 443 to an internal server on LAN. All is working well when accessing the servers by external IP from outside or VPN (PPTP), but when accessing the servers by external IP from LAN, only port 80 is reachable and not 443.

- End user portal is configured to use port 1443 and it is disabled.
- HTTP proxy is in transparent mode. And I have tested with proxy disabled as well.
- masqarading is enabled for LAN.

NOTE: I don't think that matters, but port 443 is NOT an HTTPS service, but rather an HTTP service running on port 443.

thanx


This thread was automatically locked due to age.
Parents
  • 0
    Do you have a packet filter rule set up to allow LAN clients to access the external address for 443?
  • 0 in reply to Jack Daniel
    Do you have a packet filter rule set up to allow LAN clients to access the external address for 443?


    first rule on the firewall is to allow LAN->Any (client services group) where client services group includes HTTPS and SMTP. Also the create automatic rules in the DNAT filter is enabled. Also, if I enable logging on the same rule, I can see the traslated SYN packet going through.

    The weird part is that the same exect setup works for port 80, but not 443.
  • 0 in reply to swoc
    Are there any other NAT rules which might be intercepting/altering the traffic?

    Also, is the SSL VPN active on 443?
  • 0 in reply to Jack Daniel
    Are there any other NAT rules which might be intercepting/altering the traffic?

    Also, is the SSL VPN active on 443?


    Nothing I can think off. The HTTP proxy is in trasparent mode and it should not intercept HTTPS. I even tried disabling the proxy. SSL VPN is disabled as well as End User Portal. Web Admin runs on the default 4444 port and I'm not doing any other forwarding.
Reply
  • 0 in reply to Jack Daniel
    Are there any other NAT rules which might be intercepting/altering the traffic?

    Also, is the SSL VPN active on 443?


    Nothing I can think off. The HTTP proxy is in trasparent mode and it should not intercept HTTPS. I even tried disabling the proxy. SSL VPN is disabled as well as End User Portal. Web Admin runs on the default 4444 port and I'm not doing any other forwarding.
Children
  • 0 in reply to swoc
    Running out of ideas- but I have to ask: if it is a local resource, why are you accessing it through the ASG instead of directly?  Are you using a FQDN which resolves to the external IP?
  • 0 in reply to Jack Daniel
    Running out of ideas- but I have to ask: if it is a local resource, why are you accessing it through the ASG instead of directly?  Are you using a FQDN which resolves to the external IP?

    exectly. customers access it via a FQDN and so do internal users. I'm thinking it might be a bug so I opened a support ticket with Astaro.
  • 0 in reply to swoc
    well, astaro support resolved the issue by adding a full NAT rule for anything coming from LAN to external IP on ports 80 or 443 to forward it the internal IP's and translate the source to LAN network. I still don't know why DNAT worked for port 80 and not 443.

    Thanx for all your help
  • 0 in reply to swoc
    You created a DNS loop by pointing to an FQDN which resolved to an external address, the reason the traffic behaved differently is because port 80 traffic was going through the proxy while 443 was not and clients were getting different IPs depending on which route the  traffic took.  An alternate approach to solving the problem is to solve the root problem- create a static entry on the internal DNS resolver (either the ASG or your internal DNS server) pointing to the internal IP address instead of the external address.
  • 0 in reply to Jack Daniel
    Jack is such a gentle soul, in contrast to his claim to be a curmudgeon...

    The "trick" the Astaro engineer used is a bandaid that he put in place because you didn't have the correct solution which Jack describes above.

    We would recommend you do as Jack suggests and remove the NAT rule.

    Cheers - Bob