PIX 515 doesn't route packets

"

"B Squared" 21 years ago

The following is the configuration file for my PIX 515. For some reason I can no longer get any http packets to cross between the interfaces. This change first occurred when I turned off the fixup protocol for http, and then turned it back on. I posted a question about this about a week ago, but the concensus was that the fixup protocol issue probably wasn't the real problem.

If this were a normal router, not a PIX, from the behavior I'd say it's either 1) A bad access list, or

2) the network statements haven't been entered correctly and the thing isn't routing. But the access list looks sufficently general to let http pass.

For testing I always enter the IP address in decimal, not a web address so that DNS doesn't cloud the issue.

By using the packet debug command I can see the packets at the outside interface whenever I point the browser at the web server in the dmz, but no packets ever come out of the dmz interface. This used to work just fine. I'm stumped!

I've inserted some comments along the way to aid the discussion.

------------------------------------------

PIX Version 6.3(4) ! this is all pretty normal

interface ethernet0 auto interface ethernet1 auto interface ethernet2 auto nameif ethernet0 outside security0 nameif ethernet1 inside security100 nameif ethernet2 dmz security50

! naming stuff hostname pixfirewall domain-name our_domain_name.net

! the normal fixups, but I've turned ftp off fixup protocol dns no 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

! for my basic testing I attempt to permit http and https ! in a very general way

access-list web permit tcp any any eq www access-list web permit tcp any any eq https access-list web permit ip any any

! these are pretty much by the book pager lines 24 mtu outside 1500 mtu inside 1500 mtu dmz 1500

! my addresses, as expected

ip address outside xxx.xxx.xxx.xxx 255.255.255.224 ip address inside xxx.xxx.xxx.xxx 255.255.255.0 ip address dmz xxx.xxx.xxx.xxx 255.255.255.224

ip audit info action alarm ip audit attack action alarm

! the pdm wasn't all the useful. it tells me I'm not ! getting any packets across the interfaces, which I knew

pdm location xxx.xxx.xxx.xxx 255.255.255.255 inside pdm location xxx.xxx.xxx.xxx 255.255.0.0 outside pdm history enable arp timeout 14400

! use the inside and dmz addresses without translation ! again, pretty generic

nat (inside) 0 0.0.0.0 0.0.0.0 0 0 nat (dmz) 0 0.0.0.0 0.0.0.0 0 0

! here's where I apply the access-list to attempt to ! allow www traffic access-group web in interface dmz access-group web in interface outside

! my default route is up and working fine -- this might ! seem backward to you, but this is just a test network. ! I'm testing a single laptop on the "outside" to simulate ! customers accessing our web site, and our application ! servers are on the inside, in the typical way. -- Perhaps ! some might think this is the problem, but I kinda don't ! think so

route inside 0.0.0.0 0.0.0.0 xxx.xxx.xxx.xxx 1

! more typical stuff

timeout xlate 3: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 aa-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

! stuff for PDM, which works http server enable http xxx.xxx.xxx.xxx 255.255.255.255 inside

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

-------------------

Thanks in advance for any help.

B Squared

Vote

"

"B Squared" 21 years ago

Configuration stuff deleted, but visible in the main posting.

Yes, we are running the registered IP's internally. That's the main reason I XXX'd them out in my posting.

B Squared

Vote

"

"B Squared" 21 years ago

OK. I'm pretty sure I've it with the access-list on only the outside interface, but I'll certainly try it tomorrow. While we're on the subject, that this mean that if I want to apply an identical access-list to both interfaces similar to this one, to permit www or https access I have to write the access-list twice, but with different names, and apply them, one to each interface.

For example, while we're testing the PIX, we'll want a mail server in the DMZ, and one on the inside. And we'll want to allow access from the outside to both of them, so that our clients wouldn't be cut off from their mail. But later, cnce we got it working, all mail servers would be moved into the DMZ. So the issue is more than just academic.

Vote

B

Brian V 21 years ago

Your not NATing....are you running registered IP's internally?

Vote

W

Walter Roberson 21 years ago

In article , wrote: :The following is the configuration file for my PIX 515. :For some reason I can no longer get any http packets to cross :between the interfaces.

:access-list web permit tcp any any eq www

:access-group web in interface dmz :access-group web in interface outside

You can't share access-lists between interfaces. The access-list is internally dynamically modified in order to handle adaptive security, and modifying it for two interfaces simultaneously doesn't work.

Vote

W

Walter Roberson 21 years ago

:OK. I'm pretty sure I've it with the access-list on only the outside :interface, but I'll certainly try it tomorrow. While we're on the :subject, that this mean that if I want to apply an identical access-list :to both interfaces similar to this one, to permit www or https access :I have to write the access-list twice, but with different names, and :apply them, one to each interface.

Yes.

Vote

"

"B Squared" 21 years ago

I tried your suggestion. That is, I removed the access-list / access-group so that it was only on one interface. That didn't solve the problem, and http packets still won't cross between the interfaces. Thanks for the tip on not having the same access-list applied to both interfaces, that just wasn't the [only] problem.

As a recap, this issue was try to get http packets to cross from either the outside to inside, or dmz to inside, which should be a function of an access-list. When this failed I decided to test again, and tried to get http packets to cross the other direction, from the inside to the dmz, or inside to outside, which I think is a function of the fixup protocols, not access-lists. This was working fine before, but now, doesn't. Again the boundary between working and not working was turning fixup protocol for http off, then back on. You've said this is a red herring and it shouldn't cause this problem, and I think that you're right. I've rebooted the PIX several times, and the http fixup protocol is back in place. Still, I'm not sure where else to look. Any other suggestions?

Thanks in advance for any help.

B Squared

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ... alarmed at first by the patient's condition, because he had the weak pulse, the hoarse breathing, and the pale perspiration of a dying man. But his examination revealed that he had no fever, no pain anywhere, and that his only concrete feeling was an urgent desire to die. All that was needed was shrewd questioning, first of the patient and then of his mother, to conclude once again that the symptoms of love were the same as those of cholera. -- Gabriel Garcia Marquez, _Love in the Time of Cholera_

Vote

PIX 515 doesn't route packets

Join the Discussion

Didn't find your answer?