Re: Troubleshooting PIx NAT/ICMP

spbench · ‎04-22-2004

I need to allow Ping for troubleshooting. I have a real basic config and I am having problems with ICMP.

From the inside 129.x.y.30 I can ping the PIX inside interface.

From the inside 129.x.y.30 I cannot ping the outside 32.x.y.11 address.

From the outside I can ping the outside interface.

From the outside I cannot ping the 32.x.y.11 address.

When I ping the 32.x.y.11 address the static does "create"...I can clear xlate, ping, and show xlate and the static is there.

I have posted the config, any ideas why nothing can hit the 32.x.y.11 address (or at least ICMP). The eventual goal is to allow DNS zone xfer ( initiated from outside in) over this static.

PIX Version 6.3(1)

interface ethernet0 100full

interface ethernet1 100full

interface gb-ethernet0 1000auto shutdown

interface gb-ethernet1 1000auto shutdown

nameif ethernet0 outside security0

nameif ethernet1 inside security100

nameif gb-ethernet0 intf2 security4

nameif gb-ethernet1 intf3 security6

enable password xxxx

passwd xxxxx

hostname pix003a

fixup protocol ftp 21

fixup protocol h323 h225 1720

fixup protocol h323 ras 1718-1719

fixup protocol http 80

fixup protocol ils 389

fixup protocol rsh 514

fixup protocol rtsp 554

fixup protocol sip 5060

fixup protocol sip udp 5060

fixup protocol skinny 2000

fixup protocol smtp 25

fixup protocol sqlnet 1521

names

access-list test remark --WIDE OPEN ACL FOR TESTING--

access-list test permit ip any any

access-list test permit icmp any any

access-list test permit tcp any any

access-list test permit udp any any

pager lines 24

logging buffered debugging

icmp permit any outside

icmp permit any inside

mtu outside 1500

mtu inside 1500

mtu intf2 1500

mtu intf3 1500

ip address outside 32.x.y.10 255.255.255.224

ip address inside 129.x.y.21 255.255.255.224

no ip address intf2

no ip address intf3

ip audit info action alarm

ip audit attack action alarm

no failover

failover timeout 0:00:00

failover poll 15

no failover ip address outside

no failover ip address inside

no failover ip address intf2

no failover ip address intf3

pdm history enable

arp timeout 14400

global (outside) 1 32.x.y.21-32.x.y.27

global (outside) 1 32.x.y.28

nat (inside) 1 129.x.0.0 255.255.0.0 0 0

static (inside,outside) 32.x.y.11 129.x.y.1 netmask 255.255.255.255 0 0

access-group test in interface outside

route outside 0.0.0.0 0.0.0.0 32.x.y.1 1

timeout xlate 3:00:00

timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225 1:00:00

timeout h323 0:05:00 mgcp 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

aaa-server ADMIN protocol tacacs+

aaa-server ADMIN (inside) host 129.x.y.18 il2ecic4ledx4t timeout 10

aaa authentication telnet console ADMIN

no snmp-server location

no snmp-server contact

snmp-server community public

no snmp-server enable traps

floodguard enable

telnet 129.x.0.0 255.255.0.0 inside

telnet timeout 5

ssh timeout 5

console timeout 0

terminal width 80

I can post more info if needed. I am sure this is something simple.

Here are the results of ICMP TRACE (some omitted)

Outside In (no replies received):

Inound ICMP 32.x.y.17 > 32.x.y.10 > 129.x.y.1

Inside Out (no replies received):

Outbound ICMP 129.x.y.30 > 32.x.y.22 > 32.x.y.11

jmia · ‎04-22-2004

Hi

Enable Pinging for testing connectivity only:

Enter an access-list command to permit ICMP access as follows:

access-list acl_out permit icmp any any

The "acl_out" is an access-list command ID and can be any name or a number you specify.

Use the show access-list command to view this command in the configuration.

You then need to specify an access-group command for each interface through which you want the

ICMP packets to pass. Use the show access-group command to view this command in the configuration.

To ping from one interface to another, bind the access-list and access-group command statements to the

lower security interface, which lets the ICMP echo reply to return to the sending host.

For example, enter the following command statement to ping from the inside interface to the outside

interface:

access-group acl_out in interface outside

save with command wirte memory and also issue command clear xlate.

Good luck and let me know how you get on.

Jay

spbench · ‎04-22-2004

I have an ACL named "test" which does exactly that. It is bound to the outside interface. No pings are going through.

There are no intervening routers or ACLs.

I cant figure this.

ehirsel · ‎04-22-2004

You state "From the inside 129.x.y.30 I cannot ping the outside 32.x.y.11 address". You won't be able to do that because the 32.x.y.11 is the address referred to in the static statement, and the pix will not re-send your request back thru the inside interface. Also note that you will not be able to ping the 32.x.y.10 pix outside interface from the inside because the pix does not function like IOS in that regard; i.e., it won't route the packet first and then determine if it is permitted.

As far as the ping to the 32.x.y.11 address from the outside is concerned, I would run tcpdump on the true inside host (if it is a unix host; if it run ms windows then there is similar tool avialable) and see if the packet is reaches the true host. It may be that the host is configured not to respond to icmp requests. Note the pix cpature command can be used to; run it on the inside interface and see if the pix is sending the icmp to the host.

Let me know how the tcpdump/capture test went.

spbench · ‎04-23-2004

To get the dump you refer to I would have to grab one of the unix admins, but if really needed, I can post it. However I can ping from within the PIX. I cannot ping from the 32 subnet.

Does that help?

ehirsel · ‎04-23-2004

Try running the capture command on the pix. Here's how to set that up

create an acl that defines interesting traffic for the capture

access-list cap01 permit icmp any any

now run the capture command on the inside interface:

capture cap01c access-list cap01 interface inside buffer 4096

also run a seperate capture on the outside interface

capture cap01d access-list cap01 interface outside buffer 4096

You can run both at the same time. Then run your pings from the outside host to the static address, not the pix interface the one that gets directed to the inside host.

After you run the ping, examine the captures:

show cap cap01c

show cap cap01d

Then post the results. To stop the capture, run no cap cap01c and no cap cap01d.

Also, turn pix logging buffer to level info or higher, if possible, and post what messages you see in the log.

spbench · ‎04-23-2004

Here are the packet captures you requested:

sh capture cap01out

4 packets captured

09:26:36.221332 32.x.y.17 > 32.x.y.11: icmp: echo request

09:26:37.642239 32.x.y.17 > 32.x.y.11: icmp: echo request

09:26:38.643628 32.x.y.17 > 32.x.y.11: icmp: echo request

4 packets shown

pix003a(config)# sh capture cap01in

15 packets captured

09:28:22.799656 129.x.y.30 > 129.x.y.21: icmp: echo request

09:28:22.799717 129.x.y.21 > 129.x.y.30: icmp: echo reply

09:28:22.800312 129.x.y.30 > 129.x.y.21: icmp: echo request

09:28:22.800358 129.x.y.21 > 129.x.y.30: icmp: echo reply

09:28:22.800831 129.x.y.30 > 129.x.y.21: icmp: echo request

09:28:22.800877 129.x.y.21 > 129.x.y.30: icmp: echo reply

09:28:22.801334 129.x.y.30 > 129.x.y.21: icmp: echo request

09:28:22.801380 129.x.y.21 > 129.x.y.30: icmp: echo reply

09:28:22.801838 129.x.y.30 > 129.x.y.21: icmp: echo request

09:28:22.801884 129.x.y.21 > 129.x.y.30: icmp: echo reply

09:28:31.524966 129.x.y.30 > 32.x.y.11: icmp: echo request

09:28:33.523639 129.x.y.30 > 32.x.y.11: icmp: echo request

09:28:35.523532 129.x.y.30 > 32.x.y.11: icmp: echo request

09:28:37.523425 129.x.y.30 > 32.x.y.11: icmp: echo request

09:28:39.523303 129.x.y.30 > 32.x.y.11: icmp: echo request

You can see which pings went through and not. And the debug output below:

pix003a(config)# sh log

Syslog logging: enabled

Facility: 20

Timestamp logging: disabled

Standby logging: disabled

Console logging: disabled

Monitor logging: disabled

Buffer logging: level debugging, 26 messages logged

Trap logging: disabled

History logging: disabled

Device ID: disabled

199002: PIX startup completed. Beginning operation.

502103: User priv level changed: Uname: enable_1 From: 1 To: 15

111008: User 'enable_1' executed the 'enable' command.

111009: User 'enable_15' executed cmd: show logging

101003: (Secondary) Failover cable not connected (this unit)

111009: User 'enable_15' executed cmd: show running-config

111007: Begin configuration: console reading from terminal

111008: User 'enable_15' executed the 'configure t' command.

710005: UDP request discarded from 129.x.y.22/137 to inside:129.x.y.31/netbios-ns

111008: User 'enable_15' executed the 'access-group test in int out' command.

710005: UDP request discarded from 32.x.y.17/138 to outside:32.x.y.31/netbios-dgm

111008: User 'enable_15' executed the 'ping 32.x.y.17' command.

111008: User 'enable_15' executed the 'ping 129.x.y.30' command.

111008: User 'enable_15' executed the 'ping 129.x.y.1' command.

111009: User 'enable_15' executed cmd: show logging

710005: UDP request discarded from 129.x.y.22/138 to inside:129.x.y.31/netbios-dgm

609001: Built local-host inside:129.x.y.1

305009: Built static translation from inside:129.x.y.1 to outside:32.x.y.11

111009: User 'enable_15' executed cmd: show logging

710005: UDP request discarded from 129.x.y.22/137 to inside:129.x.y.31/netbios-ns

609001: Built local-host inside:129.x.y.30

305009: Built dynamic translation from inside:129.x.y.30 to outside:32.x.y.21

111009: User 'enable_15' executed cmd: show logging

pix003a(config)#

I hope this sheds some light....

spbench · ‎04-23-2004

Figured it. In testing, I didnt reroute the entire subnet to the new gateway (the PIX), only specific host IPs. After I swung the entire 32 net through the PIX I realized the NAT pool didnt have routes out...

Thanks for all the help