• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 463
  • Last Modified:

Pix not passing traffic from Inside to Outside interface

I have a pix where I reset the config to factory defaults.  Enabled both interfaces, assigned ips to both interfaces.

Put a default route on the unit route outside 0.0.0.0 0.0.0.0 x.x.x.193 1

It pings everything outside the network perfectly fine, however when attempting to ping from the internal interface I get nothing.  I'm not as familiar with the Pix CLI as I am with IOS but I established nat with:

global (outside) 1 interface
nat (outside) 1 0.0.0.0 0.0.0.0 0 0

still I can ping everything outside, but if I do a ping inside x.x.x.193 (<- next hop router, mine) I get nothing.  The inside machines can ping the pix but for some reason the pix won't pass the traffic from the inside to the outside.

Any clues?
0
caplinktech
Asked:
caplinktech
  • 8
  • 5
  • 2
  • +1
1 Solution
 
lrmooreCommented:
You can't ping from inside because ICMP is not allowed in by default.
Try this:
  access-list icmptest permit icmp any any
  access-group icmptest in interface inside

0
 
caplinktechAuthor Commented:
Hi,

I actually do have that access list applied and still no luck.  The traffic not passing through is not limited to just icmp traffic.  Nothing passes from the inside to the outside interface.
0
 
rsivanandanCommented:
Looks like you have a router in the picture somewhere, do you have routes properly setup on it to get back to the PIX? Describe with your current network diagram and ip addressing, we'll be able to understand better.

Cheers,
Rajesh
0
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
caplinktechAuthor Commented:
Well, It is a simple setup with a router sharing a /29 subnet with the pix.  I don't think the routing is a problem because as I said, I can ping anything worldwide from the external interface of the pix, including the next 2 hops in the routes.

I'm putting the complete config here to see if anyone can notice something wrong.

PIX Version 6.3(4)
interface ethernet0 auto
interface ethernet1 100full
nameif ethernet0 outside security0
nameif ethernet1 inside security100
enable password x encrypted
passwd x encrypted
hostname pix506e
fixup protocol dns maximum-length 512
fixup protocol ftp 21
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
fixup protocol http 80
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
fixup protocol tftp 69
names
access-list 100 permit icmp any any echo-reply
access-list 100 permit icmp any any time-exceeded
access-list 100 permit icmp any any unreachable
pager lines 24
mtu outside 1500
mtu inside 1500
ip address outside x.x.x.187 255.255.255.248
ip address inside 172.16.0.1 255.255.0.0
ip audit info action alarm
ip audit attack action alarm
pdm history enable
arp timeout 14400
global (outside) 1 interface
nat (inside) 1 172.16.0.0 255.255.0.0 0 0
access-group 100 in interface outside
route outside 0.0.0.0 0.0.0.0 x.x.x.185 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 TACACS+ max-failed-attempts 3
aaa-server TACACS+ deadtime 10
aaa-server RADIUS protocol radius
aaa-server RADIUS max-failed-attempts 3
aaa-server RADIUS deadtime 10
aaa-server LOCAL protocol local
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable
telnet timeout 5
ssh timeout 5
console timeout 0
terminal width 80
Cryptochecksum:c10c49c03e6252a97dec5df401020af1
: end
0
 
lrmooreCommented:
Can you provide output of C:\>route print  from your test workstation?
>interface ethernet1 100full
Suggest using auto on eth1 unless your switchport is also manually set to 100/full
Can you post result of "sho interface" from the PIX?
0
 
caplinktechAuthor Commented:
Hi lr,

I actually switched it recently from auto to 100full, because it wasn't working with auto was trying to ensure their was not some type of negotiation problem.

I have posted the output of sho int below and the results of the ping commands i am using when pinging the google.com ip.  The output of the workstation routing tables I will not be able to get until I get on site in a couple of hours, but i don't think the problem lies there as all the local network ips show in the pix arp and they all ping the pix's inside interface fine.  The collisions on the inside interface are most likely occurring due to the port being set to 100full with the switch on auto, but i mentioned auto wasn't working either, but i have changed it back to auto at this point.

pix506e# sho int
interface ethernet0 "outside" is up, line protocol is up
  Hardware is i82559 ethernet, address is 0012.8081.e3d0
  IP address x.x.x.187, subnet mask 255.255.255.248
  MTU 1500 bytes, BW 100000 Kbit full duplex
        223942 packets input, 58292869 bytes, 0 no buffer
        Received 180371 broadcasts, 0 runts, 0 giants
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        26055 packets output, 2259753 bytes, 0 underruns
        0 output errors, 0 collisions, 0 interface resets
        0 babbles, 0 late collisions, 0 deferred
        0 lost carrier, 0 no carrier
        input queue (curr/max blocks): hardware (128/128) software (0/17)
        output queue (curr/max blocks): hardware (0/11) software (0/1)
interface ethernet1 "inside" is up, line protocol is up
  Hardware is i82559 ethernet, address is 0012.8081.e3d1
  IP address 172.16.0.1, subnet mask 255.255.0.0
  MTU 1500 bytes, BW 100000 Kbit full duplex
        32520 packets input, 2898921 bytes, 0 no buffer
        Received 6519 broadcasts, 21 runts, 0 giants
        28 input errors, 7 CRC, 0 frame, 0 overrun, 7 ignored, 0 abort
        42163 packets output, 46945263 bytes, 0 underruns
        0 output errors, 149 collisions, 0 interface resets
        0 babbles, 131 late collisions, 18 deferred
        103 lost carrier, 0 no carrier
        input queue (curr/max blocks): hardware (128/128) software (0/11)
        output queue (curr/max blocks): hardware (0/19) software (0/1)

pix506e# ping 216.239.37.104
        216.239.37.104 response received -- 20ms
        216.239.37.104 response received -- 10ms
        216.239.37.104 response received -- 10ms
pix506e# ping inside 216.239.37.104
        216.239.37.104 NO response received -- 1000ms
        216.239.37.104 NO response received -- 1000ms
        216.239.37.104 NO response received -- 1000ms
pix506e#
0
 
lrmooreCommented:
>ping inside 216.239.37.104
That's the problem. This IP address is not inside, it's outside
Pinging "inside" will never work because that IP is actually "outside"
Ping inside 192.168.1.2 might work since 192.168.1.x is "inside"

These error counts on the inside interface point to a duplex mismatch. You're set to 100/full and the switch is set for auto, which means it will default to half duplex.

>interface ethernet1 "inside" is up, line protocol is up
        28 input errors, 7 CRC, 0 frame, 0 overrun, 7 ignored, 0 abort
        42163 packets output, 46945263 bytes, 0 underruns
        0 output errors, 149 collisions, 0 interface resets
        0 babbles, 131 late collisions, 18 deferred
        103 lost carrier, 0 no carrier

Either that, or you have a bad cable between the inside interface and the switchport
0
 
caplinktechAuthor Commented:
Hi lr,

Not as familiar with pix CLI as IOS, I guess I made a bad assumption in that the "inside" keyword indicated the source interface not the interface that it would send the ping out.  As mentioned in my previous post, I assumed that the collisions were due to the duplex mismatch.

However, that syntax error in trying to ping with source of inside on the pix still doesn't change that i can't ping from the workstations connected to the inside interface of the pix.  If I ping from the pix without specifying an interface it pings anything out on the internet. If I attempt to ping anything inside the network it also pings perfectly fine.  For some reason traffic from 1 interface won't move into the other interface.

pix506e# ping 216.239.37.104
        216.239.37.104 response received -- 20ms
        216.239.37.104 response received -- 10ms
        216.239.37.104 response received -- 10ms
pix506e# ping 84.53.144.6
        84.53.144.6 response received -- 20ms
        84.53.144.6 response received -- 10ms
        84.53.144.6 response received -- 10ms
pix506e# ping 63.208.226.41
        63.208.226.41 response received -- 80ms
        63.208.226.41 response received -- 80ms
        63.208.226.41 response received -- 80ms
pix506e# ping 172.16.1.1
        172.16.1.1 response received -- 0ms
        172.16.1.1 response received -- 0ms
        172.16.1.1 response received -- 0ms
0
 
caplinktechAuthor Commented:
Increasing points....
0
 
LionBSDCommented:
i am a bit confused here...

"Put a default route on the unit route outside 0.0.0.0 0.0.0.0 x.x.x.193 1"
however the configuration states:
"route outside 0.0.0.0 0.0.0.0 x.x.x.185 1"

i guess you have some IP address missconfiguration.
the config syntax looks fine.

if you can clear this up it will be more helpfull. is it LAN-->PIX-->router ?
or anything else is missing ?
router config might be helpfull too..

thanks
lior

0
 
caplinktechAuthor Commented:
Hi Lion,

I apologize, the question was originally part of a different question and our ISP reassigned a /29 for routing to them so that ip changed.  Anyway the problem was temporarily solved by putting a Pix 501 we had laying around with the same config, so I have a feeling our Pix went bad.
0
 
lrmooreCommented:
So, you're working now with a different PIX?
0
 
LionBSDCommented:
maybe its the internal interface of the pix, if it is, you might be able to use another interface and still use the it
allways good to see a problem solved :)

take care
0
 
caplinktechAuthor Commented:
yes everything is up with a different pix. thanks.
0
 
lrmooreCommented:
What model is the one that doesn't work?
Way back when there was a whole batch that was bad and recalled ... 515's and 506's
0
 
caplinktechAuthor Commented:
It was a 506.  I will check on that.  We have a smartnet contract on it for NBD, so I'll just call up Tuesday and have it replaced.
0

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

  • 8
  • 5
  • 2
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now