Resolution Guide - How to configure NAT (Network Address Translation) in ScreenOS [ Edited ]

[PentinProcessor]

JTAC has added the following Resolution Guide to the Knowledge Base:

KB11909 - NAT Resolution Guide - How to configure Network Address Translation (NAT) in ScreenOS

Try it out and let us know how it goes.

Regards,

Josine

Message Edited by PentinProcessor on 12-17-2008 12:24 PM

[futuretec]

hi,

the link is not working it dosnt show anything

[PentinProcessor · Accepted solution]

Thank you for reporting this.

In the mean time, you can get to it by cutting/pasting this link into a new browser window: http://kb.juniper.net/KB11909

Regards,

Josine

[NDCool]

Hi All,

this is the working link also http://kb.juniper.net/index?page=content&id=KB11909

cheers,

ND

Message Edited by NDCool on 12-15-2008 12:03 PM

Message Edited by NDCool on 12-15-2008 12:05 PM

[mark9119]

---

PentinProcessor wrote:

Thank you for reporting this.

In the mean time, you can get to it by cutting/pasting this link into a new browser window: http://kb.juniper.net/KB11909

Regards,

Josine

---

I read the part of your documents in http://kb.juniper.net/KB12835

But I still got some confused. In the document, it said the packets pass the interface would be forced to NAT if it is made as NAT mode.

In the same situation as the documents, I found the outbound address would be NAT to egace interface which is not NAT to the MIP adddress as we thought.  Any explaination will be appreciated.

How to solve this situation as the above document http://kb.juniper.net/KB12835? Including the interface mode.

[PentinProcessor]

Hi,

Thank you for asking.

Can you cut/paste the actual lines which are misleading, so that I can answer your problem properly?

KB12835 includes the following note:

A MIP is bidirectional and always takes precedence over a DIP. 

I should also clarify that a MIP takes precedence over a DIP pool, DIP on egress interface, and interface-NAT.  

I will update the article after I make sure I understand your questions.

Regards,

Josine

[mark9119]

http://kb.juniper.net/KB12835 (maybe it cannot directly reached, you should http://kb.juniper.net/KB11909 then 11911, then 12835)

• You want to allow a DMZ server inside the firewall full access to the Internet, and any outside host access to a web server inside the firewall on the Trust zone
• Users on Internet will use the Server Public IP address 1.1.1.50 to access the internal server 192.168.1.50

The untrust interface is 1.1.1.100 and the server public address is 1.1.50. The internal server is 192.168.1.50.

As the document said, if the server need access the internet, it should also use the public IP address? Am i right? It means, if the server need to start a connection to other server, it should also use it public IP address just the same address as  it was connected by other servers.

But my problem is when I make a log in the policies, I see the packets from the 192.168.1.50 was translated to 1.1.1.100 (Engrase IP address). It was not I wanted.

Mine is Screen OS 5.4.0r4.0, SGS 1400

[PentinProcessor]

Mark,

Yes, that is correct.  When the server 192.168.1.50 initiates a session to a host on the Internet, it should use the MIP address and not the egress interface.  Can you include the following portions of your configuration using these two commands:

get config | inc mip

get config | inc policy

You can scrub your config (i.e. replace the IPs and remove the lines that are not applicable).

Also, is there another device between the 192.168.1.50 server and the SSG140 that could be source NATing the 192.168.1.50 to another IP address?

Are inbound connections from the Internet to the internal 192.168.1.50 server working (using the MIP address)?

Regards,

Josine

Message Edited by PentinProcessor on 04-29-2009 10:44 AM

[Asm0deus]

There's a category that I don't see here (and one that has given me some trouble):  In the common scenario where a MIP on the Untrust interface maps to an internal (private IP) host, what if that internal host is at another site via VPN tunnels? 

I have "local MIPs" all over my various sites, and all sites are able to route to one another just fine.  But I encountered a corner condition where an external device (one of my routers at "site A") needed to tftp to/from an internal host via our tunnel interfaces (server at "site B").  Ideally, I had thought that simply pointing site A's MIP to the internal address at site B would handle the permissions, but I don't think the translated source is what I (or site B's firewalls) expected.  debug flows/filters showed that the MIP did indeed result in the packets being routed over the tunnel from site A to site B, but the source address was from site A's Untrust interface.

It's no longer an issue, but that would certainly make for a nice addition to this otherwise excellent troubleshooting collection.

"NATing from external hosts to internal hosts at other sites via VPN tunnels."

[Einar]

Hi, 

I've got a question to this MIP precedence: Is there any way to override this by policy so that outgoing traffic from a host behind a MIP address may be using same outgoing interface NAT as the other traffic?

I know this can be accomplished by using VIP, but this function is limited to an Untrust interface (also not supported on a sub-interface in intrust zone)

Regards, Einar