Screen OS

Good morning everyone.  I'm, unfortunately, completely out of my depth with Juniper kit, but I still need to solve this issue.

I have an SSG140 with ScreenOS 6.3 mostly ready to become my router.
From my ISP I have 2 IP blocks:

• a /30: x.x.1.10 as my primary
• a /29: x.x.2.2 through x.x.2.4 as my secondaries

I need to configure my SSG140 to forward ports from the IPs on the /29 to various machines inside my network.  I can't use MIP because it's not a 1 to 1 relationship between public IP and private IP.  Unfortunately, I can't use VIPs because the secondaries are on a different subnet.   What I'm looking for is either instructions, or pointers to the proper documentation for setting this up.   If I can do it through netscreen, that would be ideal, but I do have console access to the device if it's only possible through the CLI.

Thank you

You can do this with destination NAT.

https://www.juniper.net/documentation/software/screenos/screenos6.3.0/630_ce_AddressTranslation.pdf page 5 11.

I'm clearly asking questions way above my ability to clearly understand the documentation.  It sounds like I need to move my prite devices to a DMZ zone in order to set the secondary IPs and make this work as I want?  Is that correct, or am I just misreading everything?

If I have untrust with static IP x.x.1.10 as my primary IP.

How do I get traffic coming to public IP x.x.2.2 to direct port 80 to trust 192.x.x.20 and port 90 to trust 192.x.x.30

Yes, destination NAT inside of your policy is how you do this.

You can have the destination device in any zone you want.  Naturally the best practice is to isolate any hosts you expose to the internet in a DMZ secured internal zone.  But this is not a technical requirement to use the feature and the zones can have any name.

Create your inbound allow pollicy from Untrust zone to your internal zone

Destination address is the public address you want to translate.  make this object in the same zone as your server internal address.

Permit the desired ports in this policy

On the advanced tab of the policy check the box for destination translation and enter the internal address.

Steve,

    Thank you for that.  After I re-read the documentation yesterday, I had come to the conclusion that I was making things harder than they needed to be, however I must have set up something wrong as I'm still having issues.

I created a policy address in Trust for my Publi IP

I createa a new policy from Untrust to Trust for ANY to <Public IP> for <Service>
Under advanced, I selected Destinatino Translation, and Translate To: <Private IP>

However, this doesn't seem to be working as I thought it would.  Is there something else simple that I overlooked?

Thank you

    Adam

You need to make sure you have a destination route for x.x.2.x that is pointing to the same interface as your internal IP.  Without this, the zone lookup will not match.

Untrust is on Eth 0/9

Trust is on Eth 0/8

In my trust-vr I have:

set route x.x.2.1/32 interface ethernet0/8

In my policies I have
set policy id 13 name "<server>" from "Untrust" to "Trust"  "Any" "x.x.2.1" "HTTPS" nat dst ip 192.168.x.x permit

However, I still am not getting any response from outside my network.

Can you run a debug flow basic?  That will show how the traffic is being handled.

https://kb.juniper.net/InfoCenter/index?page=content&id=KB23844#basicdebug

I ran the debug flow basic as detailed in the article.   I did find some issues with bad cached routes, which I was able to disable for the time being, and a poorly-thought-out policy that I removed while I get this sorted.

I'm attaching a snipped from the debug stream in a text document.   It says that it's not matching any policies, but the policies it says don't match definitely exist.

zone 1 is Untrust

zone 2 is Trust

A policy does exist from Untrust to Trust; from Any to x.x.2.1 HTTPS;

policy search from zone 1-> zone 2
 policy_flow_search  policy search nat_crt from zone 1-> zone 2
  RPC Mapping Table search returned 0 matched service(s) for (vsys Root, ip x.x.2.1, port 443, proto 6)

Attachment(s)

connection_debug_https.txt   1 KB 1 version

Double check your trust address entry.

My address entry in the Trust address list is correct: x.x.2.1/32

nded up deleting all my Untrust->Trust policies and Addresses, then recreating them 1 by 1.

This issue is completely resolved at this point.  Thank you!

Glad you have it all figured out.  Thanks for the update.