Change SSL port

[spuluka]

---

@bergbock wrote:

Hi all,

I would like to rise this issue again. Same problem. Tried to NAT a virtual port at the front FW

https://host.domain.com:8443 --> SSG-Firewall-NAT --> internal-IP-of-SA:443

The first request is working well and the certificate is loaded. Then the SA replies in the HTTP header to the client WITHOUT the virtual port 8443 and therefore the browser sends the next request to https://host.domain.com:443 which of course never arrives at the SA because it's not NATed at the firewall.

I had the idea to create a special sign-in policy for this: host.domain.com:8443/test But it did not solve the problem unfortunately.

I need to tell the SA to reply with :8443 in its headers to get this working. Did anybody configure the SA with port forwarding successfully?

Thanks!

---

I think the issue is with your firewall configuration. I believe you may have inbound nat only setup on the device. Take a look at kb11911 especially the last section noted here. I believe this combination of dual policy nat will solve the issue for you.

---------#8-------

A MIP (Mapped IP), which is generally used for bidirectional configurations, is a one-to-one mapping and cannot be used if you do not have enough public IP address.

Instead of using a MIP, use a combination of policy NAT-Dst for inbound communication:
¥ KB12652 - Configuration Example -- Configure Destination PAT to Multiple Servers (Port Mapping)
AND policy NAT-Src for outbound communication:
¥ ScreenOS Concepts & Examples Guide - Volume 8 - Address Translation_Chapter 2 - Source Network Address Translation _ NAT-Src from a DIP Pool with Address ShiftingÓ_Example: NAT-Src with Address Shifting

[ruc_]

>>>>I need to tell the SA to reply with :8443 in its headers to get this working. Did anybody configure the SA with port forwarding successfully?

Sorry this is not possible on the SA. There are several links/references that are tied to port 443. You might be able to access one or two applications using another port (using the pass through proxy feature) however as an overall solution for end user remote access this will not work.

[bergbock_]

Hi all,

Thanks, spuluka, for the detailed suggestion; I read through the chapter. When I try to do an additional src-NAT with address shift with my already configured VIP configuration, the port is not translated for outgoing packets to my fixed port 8443, but to a random port. So it is useless. With my VIP configuration only, the outgoing packets from my intenal SA IP are translated to the VIP's public IP address correctly, because it's based on the session table.

You can see that NAT is working properly in the wireshark capture. Packet 1-11 show the initial connection between client and SA. After that the client tried to connect with a new session to 443. I can see this behavior in my browser, too: The address line switches from <SA-IP:8443> to <SA-IP:443> which is not working anymore then.

      1 0.000000    <Client-IP>         <SA-IP>        TCP      webadmstart > 8443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1
      2 0.061516    <SA-IP>        <Client-IP>         TCP      8443 > webadmstart [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1304 SACK_PERM=1
      3 0.061609    <Client-IP>         <SA-IP>        TCP      webadmstart > 8443 [ACK] Seq=1 Ack=1 Win=65200 Len=0
      4 0.062632    <Client-IP>         <SA-IP>        TCP      webadmstart > 8443 [PSH, ACK] Seq=1 Ack=1 Win=65200 Len=105
      5 0.120246    <SA-IP>        <Client-IP>         TCP      8443 > webadmstart [ACK] Seq=1 Ack=106 Win=5840 Len=0
      6 0.144972    <SA-IP>        <Client-IP>         TCP      8443 > webadmstart [PSH, ACK] Seq=1 Ack=106 Win=5840 Len=1303
      7 0.148484    <Client-IP>         <SA-IP>        TCP      webadmstart > 8443 [PSH, ACK] Seq=106 Ack=1304 Win=63897 Len=186
      8 0.218067    <SA-IP>        <Client-IP>         TCP      8443 > webadmstart [PSH, ACK] Seq=1304 Ack=292 Win=6432 Len=47
      9 0.218261    <Client-IP>         <SA-IP>        TCP      webadmstart > 8443 [ACK] Seq=292 Ack=1351 Win=65200 Len=0
     10 0.218918    <Client-IP>         <SA-IP>        TCP      webadmstart > 8443 [PSH, ACK] Seq=292 Ack=1351 Win=65200 Len=462
     11 0.298891    <SA-IP>        <Client-IP>         TCP      8443 > webadmstart [PSH, ACK] Seq=1351 Ack=754 Win=7504 Len=462
     
---> here the Client tried to connect to 443 suddenly instead 8443
     12 0.316628    <Client-IP>         <SA-IP>        TCP      lmsocialserver > 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1
---> another service is answering the request
     13 0.384888    <SA-IP>        <Client-IP>         TCP      443 > lmsocialserver [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1304 SACK_PERM=1
     14 0.384964    <Client-IP>         <SA-IP>        TCP      lmsocialserver > 443 [ACK] Seq=1 Ack=1 Win=65200 Len=0
     15 0.385407    <Client-IP>         <SA-IP>        SSLv2    Client Hello
     16 0.457822    <SA-IP>        <Client-IP>         TCP      443 > lmsocialserver [ACK] Seq=1 Ack=106 Win=5840 Len=0
     17 0.457880    <SA-IP>        <Client-IP>         SSL      Continuation Data
---> because the other service is not a https server it sends a reset because it does not understand the protocol     
     18 0.461700    <SA-IP>        <Client-IP>         TCP      443 > lmsocialserver [RST, ACK] Seq=21 Ack=106 Win=5840 Len=0

I googled around a bit and found that this seems to be a natural behavior of the HTTPS protocol: The browser connects to the address which is included in the headers of the HTTPS server, not to the src-IP of the packet.

By the way, if you configure an apache https server to use another port than 443, you need to specify this in the hostname too. See this config snipplet of the httpd.conf

#Hostname *:5443
# NOTE: Hostname cannot be used without a port specifier
# (e.g. :5443) if mod_ssl is being used, due to the nature of the
# SSL protocol.

So I guess it is not possible to NAT the SA to another port

[thjpr_]

I can confirm the same behaviour. I need this for a client aswell who has only one public IP and is running an OWA on HTTPS port. Since they are using an SA700 creating a Virtual hostname on the SSL VPN is not an option since it's not included in the SA700 model. I just opened a JTAC case; maybe changing the port is still available as a hidden feature somewhere. Hopefully a positive update soon!

[bergbock_]

Hi thjpr,

Can you give us a feedback what the JTAC said about this topic? Could you solve your case successfully?

Regards

b.

[bergbock_]

Is there still no solution for this problem?

I am wondering that you canot find many information about this NAT issue and the Juniper SA. Is such a NAT scenario very uncommon?

[zanyterp_]

Unfortunately, as Ruc pointed out, the IVE is not able to do this.

[pkcpkc_]

Hi,

is this still unsupported ?

is it in the roadmap somewhere ?

thanks.

[zanyterp_]

This is still not possible with the IVE.

I do not know if it is on the roadmap; you would need to work with your local Juniper account to find out if this is something that is on the roadmap.

I am not sure if it will be possible to do, as Ruc pointed out, due to the dependencies on 443 as the communication port.

Is the communication you are needing inbound to the IVE on the different port (with the reply on the same port) or outboudnd to a backend server? (I am guessing the former; but wanted to confirm as the latter, SSL on a high port, should be possible without issue through the rewriter).

[colemtb_]

I've ran into the same design requirement, still no?