10-15-2010 06:52 AM - edited 03-11-2019 11:54 AM
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
Solved! Go to Solution.
10-15-2010 10:55 AM
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
10-15-2010 06:59 AM
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
10-15-2010 07:01 AM
No luck with those commands.
- Ribin
10-15-2010 07:23 AM
Could you enable logging and see what messages do you receive :
logging buffered 7
ping
then show logg
Dan
10-15-2010 07:27 AM
Nothing happens.
- Ribin
10-15-2010 07:38 AM
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
10-15-2010 07:42 AM
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
10-15-2010 07:52 AM
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
10-15-2010 07:58 AM
Hi Ribin,
Also check for any interface access lists on the L3 switch for dropping ICMP
Regards,
Sindhuja
10-15-2010 08:03 AM
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
10-15-2010 08:07 AM
Hi Ribin,
Check your physical connectivity. Change the interface that your have connected to on the pix.
Regards,
Sindhuja
10-15-2010 08:13 AM
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
10-15-2010 08:19 AM
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
10-15-2010 08:26 AM
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
10-15-2010 09:13 AM
Just now noticed that the PIX doesn't even give reply to self ping.
- Ribin
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide