cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5215
Views
5
Helpful
25
Replies

PIX 515e basic config

ribin.jones
Level 1
Level 1

Hi,

I got a PIX and here is the config:

sh run

PIX Version 8.0(3)

hostname pixfirewall

enable password 8Ry2YjIyt7RRXU24 encrypted

names

interface Ethernet0

shutdown

nameif Outside

security-level 0

no ip address

interface Ethernet1

nameif inside

security-level 100

ip address 192.168.1.51 255.255.255.0

passwd 2KFQnbNIdI.2KYOU encrypted

ftp mode passive

pager lines 24

mtu Outside 1500

mtu inside 1500

no failover

            
icmp unreachable rate-limit 1 burst-size 1

no asdm history enable

arp timeout 14400

timeout xlate 3:00:00

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

timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00

timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00

timeout uauth 0:05:00 absolute

dynamic-access-policy-record DfltAccessPolicy

no snmp-server location

no snmp-server contact

snmp-server enable traps snmp authentication linkup linkdown coldstart

telnet timeout 5

ssh timeout 5

console timeout 0

threat-detection basic-threat

threat-detection statistics access-list

class-map inspection_default

match default-inspection-traffic

policy-map type inspect dns preset_dns_map

parameters

        
  message-length maximum 512

policy-map global_policy

class inspection_default

  inspect dns preset_dns_map

  inspect ftp

  inspect h323 h225

  inspect h323 ras

  inspect netbios

  inspect rsh

  inspect rtsp

  inspect skinny

  inspect esmtp

  inspect sqlnet

  inspect sunrpc

  inspect tftp

  inspect sip

  inspect xdmcp

service-policy global_policy global

prompt hostname context

Cryptochecksum:6ba6ce7d4cbacfeafbc90a2ed9b0d923

: end

My LAN is 192.168.1.0/24 and I gave the PIX IP as 192.168.1.51. My machine IP is 192.168.1.64 and 192.168.1.1 is the vlan IP of our Layer 3 switch. i am not able to ping 192.168.1.1 from the PIX. What could be the issue?

- Ribin

1 Accepted Solution

Accepted Solutions


Hi Ribin,


Here is more details on the issue:


Since the platform has a Failover Only-Active/Standby (FO) license, your PIX cannot be used as standalone unit unless you
change the type of license it has to an either Restricted or an Unrestricted license. You can still give it a try by enabling Failover on your device, but the device may reboot by itself every 24 hours since it is to detecting a mate (failover pair).
In order to enter these commands you need to make sure you are in configuration mode:

> pixfirewall# config t > pixfirewall(config) failover > pixfirewall(config) failover active

In case you are still unable to pass traffic, or the unit reboot every 24 hours, you  will need to obtain a new license for
your device. In order to do that, you will need to  contact your Account Manager or the Point of Sales where you got the
device from, or you can call the TAC front line at 1800 553 2447 and obtain the required license.

Also one more question before you opt for a seperate license. Do you have another PIX that you are willing to use in Active and Standby failover
mode (with 2 PIX) ? If yes then the PIXs will pass traffic once they are configured for failover.

Cheers,
Rudresh V

View solution in original post

25 Replies 25

Hi

could you try :

icmp permit any echo-reply inside

icmp permit any echo inside

policy-map gloval_policy
class class-default
  inspect icmp

HTH

Dan

No luck with those commands.

- Ribin

Could you enable logging and see what messages do you receive :

logging buffered 7

ping

then show logg

Dan

Nothing happens.

- Ribin

sinv
Level 1
Level 1

Hi,

Is this the full configuration that you have pasted ? Have you configured any access lists on the PIX ?

As per your description the switch seems to be the next hop on the PIX.

Check the default gateway on the switch.

Do a "debug icmp trace" on the PIX to see if the packets are even reaching the firewall.

Another way to check if the pings are even reaching the firewall is by putting captures.

Check the steps document to see if it helps you isolate the issue

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

Regards,

Sindhuja

Yes Sindhuja, this is the full config I have pasted here. I have not added any acl on the PIX.

What do you meant by "Check the default gateway on the switch." ? I have other devices in the network with gw as 192.168.1.1 which works fine. I think I am missing some basic thing in the PIX initial configuration.

- Ribin

Hi,

When I meant default gateway on the switch I meant to see if the traffic is being routed back to the PIX.

Lets just revisit your topology real quick here

host ----- --------------switch ------------------(192.168.1.51) PIX

(192.168.1.64)   (192.168.1.1)

Please correct me if this is wrong.

I understand you are unable to ping the 192.168.1.1 ip address.

The only issue on the pix that could be causing this is that the pix is dropping incoming icmp and this can be done by access lists.

Since that option has been eliminated let us look at it from the routing point of view.

1. Are you able to ping from 192.168.1.64 to 192.168.1.51 and vice versa ?

2. What is the output of the debug icmp trace on the firewall when you try to ping 192.168.1.1?

3. Also check that when you do a show route on the PIX you are able to see a directly connected route to the 192.168.1.0 subnet.

Regards,

Sindhuja

Hi Ribin,

Also check for any interface access lists on the L3 switch for dropping ICMP

Regards,

Sindhuja

Hi,

The topology is right.

My issue is not with the icmp alone. I am unable to make any kind of communication to or from the PIX. I think we can leave out the Layer 3 concept here (since the PC and the PIX sits in the same network). There is no acl in the L3 to block icmp.

1. Are you able to ping from 192.168.1.64 to 192.168.1.51 and vice versa ?

   - No

2. What is the output of the debug icmp trace on the firewall when you try to ping 192.168.1.1?

pixfirewall(config)# debug icmp trace
debug icmp trace enabled at level 1
pixfirewall(config)# 
pixfirewall# ping 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
?????
Success rate is 0 percent (0/5)

3. Also check that when you do a show route on the PIX you are able to see a directly connected route to the 192.168.1.0 subnet.

pixfirewall# sh route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is not set

C    192.168.1.0 255.255.255.0 is directly connected, inside

Hi Ribin,

Check your physical connectivity. Change the interface that your have connected to on the pix.

Regards,

Sindhuja

No luck. My config oncemore:

sh run

: Saved

:

PIX Version 8.0(3)

!

hostname pixfirewall

enable password 8Ry2YjIyt7RRXU24 encrypted

names

!

interface Ethernet0

shutdown

nameif Outside

security-level 0

no ip address

!

interface Ethernet1

nameif inside

security-level 100

ip address 192.168.1.51 255.255.255.0

!

passwd 2KFQnbNIdI.2KYOU encrypted

ftp mode passive

pager lines 24

logging buffered debugging

mtu Outside 1500

mtu inside 1500

<--- More --->
             
no failover

icmp unreachable rate-limit 1 burst-size 1

icmp permit any echo-reply inside

icmp permit any echo inside

no asdm history enable

arp timeout 14400

timeout xlate 3:00:00

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

timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00

timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00

timeout uauth 0:05:00 absolute

dynamic-access-policy-record DfltAccessPolicy

no snmp-server location

no snmp-server contact

snmp-server enable traps snmp authentication linkup linkdown coldstart

telnet timeout 5

ssh timeout 5

console timeout 0

threat-detection basic-threat

threat-detection statistics access-list

username ribin password 4PKgAdpUwCY7ZdMA encrypted privilege 15

!

class-map inspection_default

match default-inspection-traffic

<--- More --->
             
!

!

policy-map type inspect dns preset_dns_map

parameters

  message-length maximum 512

policy-map gloval_policy

class class-default

  inspect icmp

policy-map global_policy

class inspection_default

  inspect dns preset_dns_map

  inspect ftp

  inspect h323 h225

  inspect h323 ras

  inspect netbios

  inspect rsh

  inspect rtsp

  inspect skinny

  inspect esmtp

  inspect sqlnet

  inspect sunrpc

  inspect tftp

  inspect sip

  inspect xdmcp

<--- More --->
             
!

service-policy global_policy global

prompt hostname context

Cryptochecksum:6ba6ce7d4cbacfeafbc90a2ed9b0d923

: end

- Ribin

Ok ... Lets try capturing the traffic.

access-list capin permit icmp host 192.168.1.51 host 192.168.1.1

access-list capin permit icmp host 192.168.1.1 host 192.168.1.51

capture capin interface inside access-list capin.

Then initiate the ping.

Then check the output of 'show cap capin'

Since we are not able to ping even directly connected hosts I am suspecting an issue with the connectivity.

Regards,

Sindhuja

Hmm..It is zero packet captured.

pixfirewall# sh capture capin
0 packet captured
0 packet shown

What could be the issue with the connectivity? Just now I connected a laptop (with IP 192.168.1.90) directly to the pix using a straight cable and even these can't ping each other.

- Ribin

Just now noticed that the PIX doesn't even give reply to self ping.

- Ribin

Review Cisco Networking products for a $25 gift card