NAT does not work

[antinea]

Hello,

NAT seems does not working on my pix.

I verified n-times my config. No issue :(

Please can anyone verify my config and tell what's wrong ? and thanks in advance.

I have a DSL modem (Siemens) working as default router (x.x.16.17)

here's the config (x and y are the same everywhere in the script)

PIX Version 6.2(2)

nameif ethernet0 outside security0

nameif ethernet1 inside security100

enable password 7PmXr29jODRJ.eaI encrypted

passwd 7PmXr29jODRJ.eaI encrypted

hostname tita

domain-name any.net

fixup protocol ftp 21

fixup protocol http 80

fixup protocol h323 h225 1720

fixup protocol h323 ras 1718-1719

fixup protocol ils 389

fixup protocol rsh 514

fixup protocol rtsp 554

fixup protocol smtp 25

fixup protocol sqlnet 1521

fixup protocol sip 5060

fixup protocol skinny 2000

names

access-list inside_access_in permit icmp any any

access-list inside_access_in permit ip any any

access-list outside_access_in permit icmp any any

interface ethernet0 10baset

interface ethernet1 auto

icmp permit any outside

icmp permit any inside

mtu outside 1500

mtu inside 1500

ip address outside x.y.16.18 255.255.255.248

ip address inside 192.168.22.2 255.255.255.0

ip audit info action alarm

ip audit attack action alarm

pdm location 192.168.22.5 255.255.255.255 inside

pdm history enable

arp timeout 14400

global (outside) 10 x.y.16.19-x.y.16.21 netmask 255.255.255.248

nat (inside) 10 0.0.0.0 0.0.0.0 0 0

access-group outside_access_in in interface outside

access-group inside_access_in in interface inside

route outside 0.0.0.0 0.0.0.0 x.y.16.17 1

timeout xlate 3:00:00

timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h323 0:05:00 sip 0:30:00 sip_media 0:02:00

timeout uauth 0:05:00 absolute

aaa-server TACACS+ protocol tacacs+

aaa-server RADIUS protocol radius

aaa-server LOCAL protocol local

http server enable

http 192.168.22.5 255.255.255.255 inside

no snmp-server location

no snmp-server contact

snmp-server community public

no snmp-server enable traps

floodguard enable

no sysopt route dnat

telnet 192.168.22.5 255.255.255.255 inside

telnet timeout 5

ssh timeout 5

username samir password .KnHwytEP2k92JAD encrypted privilege 15

terminal width 80

Cryptochecksum:abd0f7a4e9339ff5026a3c5c9234cfa1

[wagrjohn]

It probably is working. Do a "sh xlate" to see if you have any entries in there. Also make sure that that dsl modem/router has route entries pointing x.y.16.19-x.y.16.21 to x.y.16.18 otherwise your return traffic doesn't know how to get back to the PIX.

- John

P.S. Should change your passwords now even though they're encrypted; never know who might be reading these forums. :)

[antinea]

Thank you all for you replies,

I'm sorry but this pix is making me crazy.

I added a PAT address in the global statement. No answer from any outside host, even the outside address.

I'm trying with only one host (192.168.22.5) my console.

The following may help you to help me:

- I'm quite sure my DSL modem is working fine, cause in the production site a router is instead of this pix and is working fine as a default route.

- I can ping all interfaces and hosts (inside and outside) from my pix.

- activating debugging as follows: debug icmp trace and logging buffered debugging i saw on my console everytime i ping to an external host the following:

(x.y.75.13 my isp's dns)

tita# 22: Outbound ICMP echo request (len 32 id 2 seq 20992) 192.168.22.5 > x.y.16.21 > x.y.75.13

23: Outbound ICMP echo request (len 32 id 2 seq 21248) 192.168.22.5 > x.y.16.21 > x.y.75.13

24: Outbound ICMP echo request (len 32 id 2 seq 21504) 192.168.22.5 > x.y.16.21 > x.y.75.13

25: Outbound ICMP echo request (len 32 id 2 seq 21760) 192.168.22.5 > x.y.16.21 > x.y.75.13

Thanks for the advise :)

[apriore685]

Type "clear xlate"

than type "show xlate"

The config looks good but y do you have the command to permit ip any any on the inside?

[wagrjohn · Accepted solution]

Try just PATing to the outside interface, using:

"global (outside) 10 interface"

and get rid of your other global statements (Might have to remove the "nat (inside) 10 0.0.0.0 0.0.0.0 0 0" first or the pix might complain, I forget).

"I have a DSL modem (Siemens) working as default router (x.x.16.17)

here's the config (x and y are the same everywhere in the script) "

By this do you mean the DSL Modem is also a router? or is x.x.16.17 your ISP's router and they assigned you a block of IPs? If it is the latter case, then the ISP's router has to know to route your NATed addresses to the PIX.

The icmp trace shows that the PIX is NATing and pings are going out as one of your NAT pool addresses, but it's not coming back in. So I really think that your upstream router doesn't know to send packets destined for your NAT addresses to your PIX address. If the interface PAT works, then that will show exactly that, because the PIX knows to reply to it becuase it's addressed to it. But the NAT addresses are not addressed directly on the PIX, they exist on it, and the PIX will know what to do once it gets them, but they must be routed to it.

- John

[antinea]

I thank you very very very much :)

When I patted my outside interface, everything went right.

In fact, it seems that my default gateway (which is the DSL modem) does not route back to pix (x.y.16.16/29) addresses except x.y.16.18

I transferred the issue of the other 5 ip addresses to my isp.

But please still one question: Why I still cannot ping from internal hosts my outside interface on the pix?

Once again, thank you very much to you and to all those who gave me some of their precious time.

[wagrjohn]

Yeah, you won't be able to. Probably because the PIX can't route out and back into one of it's own interfaces just like if you have multiple site-to-site VPNs terminated on the same interface, they won't be able to talk to each other unless you mesh them.

See the excerpt from the following link:

http://www.cisco.com/en/US/customer/products/hw/vpndevc/ps2030/products_tech_note09186a0080094e8a.shtml

" Pings to PIX's Own Interfaces

In PIX Software versions 4.1(6) until 5.2.1, ICMP traffic to the PIX's own interface is permitted; the PIX cannot be configured to not respond. You will not be able to ping interfaces on the "far side" of the PIX in any version. In our network diagram, you will be able to ping 10.1.1.1 from 10.1.1.5 or 200.1.1.1 from the outside, but you will not be able to ping 200.1.1.1 from 10.1.1.5, nor will you be able to ping 10.1.1.1, from the outside. Beginning in PIX Software version 5.2.1, ICMP is still permitted by default, but PIX ping responses from its own interfaces can be disabled with the icmp command (that is, a "stealth PIX"): "

- John