Address translation do not work

[pslavkovsky]

Hi

I have PIX-OS 6.3(3), 3 interfaces,

Important rows:

nameif gb-ethernet0 outside security0

nameif gb-ethernet1 inside security100

nameif ethernet0 mgmt security30

access-list all-ip-packet permit ip any any

nat (inside) 0 access-list all-ip-packet

nat (mgmt) 0 access-list all-ip-packet

static (mgmt,outside) tcp interface 9000 12.1.3.17 9000 netmask 255.255.255.255 0 0

static (mgmt,outside) tcp interface 9001 12.1.3.18 9001 netmask 255.255.255.255 0 0

It looks that address translation do not work for situation when I try "telnet <ip addr of outside interface> 9000" from outisde network.

When I do "telnet <ip addr of outside interface> 9000" and do "show xlate" respons is "0 in use, 0 most used"

And this message is in syslog: No route to <ip addr of outside inteface> from <ip addr of PC on outside site>

Commands "static ..." was added now because we need access to server located on network routed by router Cisco 2800 and this router Cisco 2800 is connected to mgmt interface of PIX. PIX has route in routing table to 12.1.3.0 255.255.255.0 via Cisco 2800.

Thanks

Peter

[vasthorvak]

2 things:

1) Did you apply and access-list to the outside allowing this traffic?

2) Do you have a default route for everything to the outside interface?

[pslavkovsky]

1)

Access-list is applied and communication from PC to outside interface of PIX is allowed.

When I do "telnet 9000"

a I do "show conn | include " I see this:

TCP out :35064 in :9000 idle 0:00:48 Bytes 0 flags SaAB

So I think that is no problem with access list

And no message is in syslog about access-list denied ...

2)

Yes, default route for everything is to the outside interface.

Route for network where is Server located (network behind Cisco 2800) is in routing table of PIX.

And It is funny syslog message "No route to from " .

PIX does not know itself interfaces?

My idea:

I do "telnet 9000".

Is it OK that respons from "show xlate" is "0 in use, 0 most used" ??

I would expect: 1 in use.

So I think that problem is with address translation.

Peter

[paddyxdoyle]

Do you see your static's in the xlate table?

"show xlate"

I believe you should see entries for the static PAT statements, if not please issue "clear xlate"

HTH

PJD

[pslavkovsky]

xlate table is empty,

show xlate: 0 in use, 0 most used

After "clear xlate" it is the same.

Peter

[vasthorvak]

Lets take a step back. You say you telnet to the ip address of the pix interface on port 9000? Why are you trying to do this? Do you mean are trying to telnet from a pc on the outside network though the pix to a server on you dmz on port 9000? If this is the case then you have to have a static translation (which you say you have) and an access list applied to the outside interface allowing this traffic.

If you are actually trying to telnet to port 9000 on the actual pix interface as this statement indicates "when I try "telnet 9000" then you will not be able to as that port is not open on the pix itself.

please clarify

[pslavkovsky]

I trying to telnet from a PC on the outside network though the pix to a server on my dmz on port 9000.

When I trying to telnet, output from "show xlate" is always :"0 in use, 0 most used"

So I think that Address translation do not work.

Peter

[vasthorvak]

ok...you have your xlates correct so its not a translation issue. Your issue from the information you have provided is with you access list. When you answered my previous question about the ACL you mentioned that an access-list is applied allowing the pc to the outside interface. That is not what I was referring to. To allow access from a lower security interface to a higher security interface then you need to have a acl applied to the outside (lower security interface) allowing that box to access the internal pc on port 9000. The acl that is applied to any other interface does not apply. Please confirm that you have the acl applied to the OUTSIDE interface allowing this host from the outside to your internal pc. Remember you will not see a translation if the ACL is blocking this traffic as ACL are checked before translations.

[pslavkovsky]

I have ACL on on outside interface.

And this row is in ACL:

access-list name permit ip host host

I added this row (like you recommended):

access-list name permit ip host host

And I try to telnet but result is the same:

Show xlate:

0 in use, 0 most used

Summary of Facts:

I try: "telnet 9000"

symptoms:

1)

show xlate:

0 in use, 0 most used

2)

sh conn | include :

TCP out :35640 in :9000 idle 0:00:45 Bytes 0 flags SaAB

3)

no message in syslog that some Access-List denied some communication

4)

this message appears in syslog:

No route to from

Funny things:

Flags "SaAB" in symptom #2 tells that connection is initialized to outside interf of PIX and symptom #4 tells that No route to IP addr of outside interf PIX.

Peter

btw: I use ONLY private ip addresses on network and PIX, but I changed it on this webforum unhappily, sorry.

[vasthorvak]

As for the outside ACL the IP of server should be what it translates to not the real ip. So if your translating to the pix int then the first acl entry you have is sufficient. You can verify this with the hit counters incrementing every time you try to connect.

Since you see it in the conn table then it wont be an acl issue and its not due to translation otherwise you will see it in the syslogs (if you are logging at least to level 5) and you would need a translation before a connection could be made. It is odd that you do not see a translation in the xlate table though.

Can you try to connect to add a static route for the network to your outside interface (should be necessary as you have the default route but try it regardless)

Also try to initiate a connection from the server in the inside to the pc on the outside to make sure you see and xlate in the table (this will confirm an xlate from the trusted to the untrusted) which should definitely work.

[vasthorvak]

One more question why are you translating to a public IP addresson your dmz? What is the ip address that you have on the outside interface of your pix that you are translating too? if you can cut and paste your route table here so i can see it and the ip addresses of your interfaces with the netblocks included. I see you have the public space assigned to AT&T WorldNet Services on your dmz. I recommend you dont do this. Please provide the information above.

[pslavkovsky]

This is in command reference:

Order of NAT Commands Used to Match Local Addresses

The firewall matches local traffic to NAT commands in the following order:

1. nat 0 access-list (NAT exemption)

2. static (static NAT)

3. static {tcp | udp} (static PAT)

4. nat nat_id access-list (policy NAT)

5. nat (regular NAT)

Can be a problem with this order?

"nat 0 access-list" is first one and I have it in my configuration so static is not used.

What do you think about it?

thanks

Peter

[slaurin]

Hi,

If I can jump into this thread for a second, I would say two things:

1) Vasthorvak is right when he says that your "static" must translate to the external address of your server, not its real IP.

2) Your "nat 0" statement tells the PIX not to translate anything from the DMZ, so this won't work. Why are you using "nat 0" on this interface? Do you have VPN tunnels? Please make sure your server's IP address isn't included in you "nat 0" statement.

Simon Laurin

[vasthorvak]

Nat0 does tell it not to translate, and according the ips that he has list which are real, is why i suggested to do a nat0. The other option would be a static which he has but would like to override. Since NAT0 has a higher precedence he could do this (if he has real ips on the inside) which will override the static statement for the same ip block.

[slaurin]

You're right, he can use identity NAT to do this, and for it to work he would need routable IPs behind the DMZ, however this scenario would still require the use of static translations (from the public IP address to the same, unchanged public address between the outside and the DMZ interfaces) to pass traffic from the outside (higher security) to the DMZ interface.

Simon Laurin