PDA

View Full Version : Auto NAT vs Manual NAT vs port mapping problem



Snowbird
2008-01-06, 14:21
I am probably missing something obvious here...

I am running NGX R65 on SPLAT and have one external
(dynamic) IP address.

I have one internal LAN object defined with Automatic NAT,
Hide behind Gateway configured. No problems there.

I have "Translate destination on client side" checked for
both Automatic and Manual NAT in Global Properties.

I have a client in the LAN that requires inbound port
9940 mapped to it, so I have defined two manual NAT rules:

outbound: [client - Any - 9940 | external IP object(hide) - Original - 9940]

inbound: [Any - external IP object - 9940 | Original - client - Original]


and then have the two required Security rules:

outbound: [client - Any - 9940 - Accept]

inbound: [Any - external IP object - 9940 - Accept]


So the problem is when I fire up the application on the client
that requires inbound 9940, the application reports to it's
external connection server that the return port on my external
IP is a high NATed port instead of the required 9940 that I
think I have manually defined.

Any ideas what I am missing? Thanks..

Thorpuse
2008-01-06, 19:05
Use Static rather than Hide-Nat.

Snowbird
2008-01-06, 20:22
On which, my LAN object, manual rule, or both?

chillyjim
2008-01-06, 22:45
Manual rule.

Snowbird
2008-01-07, 21:38
When I change this manual rule to static:

outbound: [client - Any - 9940 | external IP object(hide) - Original - 9940]

and try to save or push policy this is what I get

RayPesek
2008-01-07, 23:08
"object(hide)"

You need to use Static NAT, not Hide NAT. Hide NAT uses random high TCP ports.

Ray

Snowbird
2008-01-08, 22:09
I only have one external IP address.

When I try to save or push this policy, I get the error I posted
above. If I change rule 9 to Hide, it installs. Any idea why?

Snowbird
2008-01-08, 22:23
After rebooting both the enforcement module and the smartcenter
server, I have now pushed this NAT policy, but the client application
still reports to the connection server a high NATed port instead of 9940.
Any ideas? Thanks

MarioL
2008-01-09, 07:08
You need to move the static rules above the Hide rules.

Edited to add this:
I usually create a group with all "my" networks (assuming I don't want to NAT between my own networks), then I configure a rule to avoid NAT like this (it's my first rule):
All my networks | All my networks | any | = | = | =

After that one I have all the static NAT rules. I always create them automatically when possible, because I think that is "cleaner".

In the end I add a manual hide NAT rule which goes something like this:
All internal nets | any | any | Hide fw | = | =

I don't like the automatic Hide, because of all the extra rules it creates.

Snowbird
2008-01-09, 22:03
I pushed the following policy but no luck. The app still reports a high
NATed port to the connection server instead of 9940.
Do you think client side NAT translation has anything to do with it?

RayPesek
2008-01-09, 22:18
I'm getting a little confused here. Is this all correct?

Your client is on your LAN and needs to accept connections from the Internet on UDP 9940.

Your client on the LAN needs to be able to go outbound anywhere on the internet using UDP 9940.

This application is located somewhere on the Internet.

Ray

MarioL
2008-01-10, 05:56
As Ray says, can you please clarify... please detail exactly how the communication between client/server works and where each is, who initiates the connection, etc.

PS Translation on the client side only changes when the NAT happens, it doesn't affect the end result "on the packets".

mcnallym
2008-01-10, 07:01
If I understand you correctly then the Server is on your network behind a R65 box with one external dynamic IP address. Do you actually need to initate a connection from the server to the client, other then reply traffic to the clients request.

I would look at the SRV_REDIRECT function (look at http_mapped) for how to use this. That way rather than NATting the traffic it just redirects essentially port mapping the traffic rather then NAT as such.

VPN-1/FireWall-1 can perform Port Address Translation (PAT), and includes predefined Port Mapping Services. Connections are directed to the firewall module, accepted on a given port and translated to another, then routed to an internal server, when Port Mapping Services are defined and configured. This occurs transparently to users.

Procedure:

Configuring predefined TCP Port Mapping Services


Log into SmartDashboard.


Click 'Manage > Services'.


On the Services dialog box Click the drop down menu next to 'Show:', select 'User defined services' and choose the desired Port Mapping Service (e.g. http_mapped).


Click the 'Advanced' button.


In the 'Match' section configure the IP address of the internal server utilizing port mapping, and the mapped ports.

Example:

Default
SRV_REDIRECT(80,0.0.0.0,80)


Modified
SRV_REDIRECT(80,10.20.1.5,8080)


Click 'OK' and close all screens.


Configure the rule (see Rule Base configuration).

Rule Base Configuration

Source: Any
Destination: firewall_object
Service: Port Mapping Service (e.g. http_mapped)
Action: accept


Install the Security Policy.

Snowbird
2008-01-10, 21:08
RayPesek and MarioL

The app I'm trying to use is iVisit video conferencing. The client app is
on a PC behind my R65 firewall. You load the client app and then login to the
iVisit connection server on the Internet. It tells that server what external
port other iVisit clients can directly connect to you on. There's a network
stats window you can open in the app to show what it is reporting for
example: "external 10.1.1.1 (10654) : internal 192 168.1.1 (9940)"

I can't figure out what R65 NAT rules will allow the client app to detect
that 9940 is mapped in to it. Instead it always reports to the server that it
can be reached on a random high NATed port.

I know the client app correctly reports the outside port because if I login
to the internet connection server through a cheap NetGear router, it
reports 9940 as the external reachable port. Can't get it to do the same
through R65.

mcnallym

I thought SRV_REDIRECT only worked for TCP and not UDP..

Snowbird
2008-01-15, 21:48
So far I haven't found any manual NAT rules or SRV_REDIRECT
combinations that have solved this problem. Could it be something
to do with the fact that I have a dynamic external address?

Thanks