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? ... View more

Hi thjpr, Can you give us a feedback what the JTAC said about this topic? Could you solve your case successfully? Regards b. ... View more

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 ... View more

If you have only one public IP and port 443 of this IP is already in use, you need to NAT to connect to a second server running internally on 443. ... View more

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! ... View more