I just got our new 515E into the shop and I've been trying to get it up and running. This is my first experience with PIX, so I've definitely drifted a little deeper in the pool than I've been before.

We have a subnetted class C that we'd like to hold on to, since all the machines are presently configured with it. I'm not interested in NAT and using private addresses behind the PIX since that is the case. I can't seem to get the unit configured, though, in such a way that it let's me access outside from inside.

Using the example here:
http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_sw/v_63/config/bafwcfg.htm#39502

I managed to work up the following config:

PIX Version 6.3(1)
interface ethernet0 auto
interface ethernet1 auto
nameif ethernet0 outside security0
nameif ethernet1 inside security100
hostname pixfirewall
domain-name mysite.com
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 acl_out permit icmp any any
pager lines 24
logging buffered debugging
mtu outside 1500
mtu inside 1500
ip address outside A.B.C.130 255.255.255.192
ip address inside A.B.C.193 255.255.255.192
ip audit info action alarm
ip audit attack action alarm
arp timeout 14400
nat (inside) 0 A.B.C.130 255.255.255.255 0 0
access-group acl_out in interface outside
route outside 0.0.0.0 0.0.0.0 A.B.C.129 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
http server enable
http A.B.C.200 255.255.255.255 inside
floodguard enable
telnet timeout 5
console timeout 0
terminal width 80


I can ping the router (outside) from the PIX, and I can ping hosts on my network (inside) from the PIX, and vice versa. I can't seem to transverse it, though, with ping or http requests.

Anyone see the problem with my configuration?

- Edited because I'm an idiot.

Well I have a job working at Colgate Screwing the Caps onto tubes of toothpaste how much harder could it me to fix a Pix firewall, let me look at the config.

I haven't worked with PIX firewalls yet (my school will be getting some in to offer a CCSP course soon ), but I can forward this to my instructor to see if he has any help he can give if you would like.

Sure thing! Thanks.

Someone in another forum suggested that the problem is that my inside and outside interfaces are on the same subnet and that won't work. Only, they're not...unless I'm misunderstanding something. I'm using a subnet mask of 255.255.255.192 on my network, and the interfaces are on the A.B.C.192 and A.B.C.128 networks, respectively. (In case you want to pass that bit along as well...it might have something to do with where my problem lies).

Suggestion: Get a REAL firewall. NetScreen.

www.netscreen.com

:-)

- Jon

If only it was my call.....

I think your problem is that the following line in your config:

nat (inside) 0 A.B.C.130 255.255.255.255 0 0

Should be:

nat (inside) 0 A.B.C.130 255.255.255.192 0 0

- trs

Yeah..I thought that, too. However when I try it, I make two observations...

1) I get a warning message stating that the IP and netmask are inconsistent. I don't understand why that is, though.
2) It doesn't fix the problem.

In fact I tried it that way first, since it seemed fairly logical, but eventually the only time it didn't throw that error at me was when i used the 255.255.255.255 netmask. I'm guessing whatever my problem is has something to do with this command, but I've tried a range of options and none of them seem to work.

Try nat (inside) 0 A.B.C.128 255.255.255.192 0 0

I'm not a PIX expert and the CL interface appears to be designed to keep said experts in employment. Anyway, that link you provided is inconsistent with regards to the nat line. In the '2 interfaces without nat' example, they give the interface address with the network submask, as suggested previously (which gives you an error). However, in the '3 interfaces without nat' example, they give the network address with its submask...

OK, just to double check, you're using public ip addresses on your network, right? Or are they private?

- trs

No dice.

Actually in your suggestion you have the *outside* network specified, and it looks like the inside network specified on the example you're referring to. I tried both...neither work for me. Though on the bright side...neither gives me that silly "inconsistent" error.

They're public. We've been using them as such for years.

This is great..I'm getting some great suggestions here. I knew this was a great place to take my query. With the brains on this forum this is probably a good place to find solutions for most any kind of technical problem.

I apprecaite the help, everyone. Thanks so much!

My answer seems a tad bit elusive, though.

OK, 3rd tries a charm. Try this for the nat config:

nat (inside) 0 A.B.C.193 255.255.255.192 0 0

Also, I'm concerned with the fact that your gateway appears to be on a different subnet as your pix's outside interface.

You have:

route outside 0.0.0.0 0.0.0.0 A.B.C.129 1

And I would think that you would have something more along the lines of:

route outside 0.0.0.0 0.0.0.0 A.B.C.131 1 (not saying that .131 is your gateway address, but I would assume that it would be on the same subnet as your outside interface)

Also, you might want to run the command 'clear xlate' after making these changes and before trying to get out through the pix.

- trs

nat (inside) 0 A.B.C.193 255.255.255.192 0 0

Tried this and get "inconsistent" error. Actually what happens when I get that message is it puts the value A.B.C.192 in the config...I guess it assumes I wish to refer to the network and not the PIX inside interface. In any event, this doesn't seem to be working either.

Also, I'm concerned with the fact that your gateway appears to be on a different subnet as your pix's outside interface

How so? With a subnet mask of 255.255.255.192, the "outside" interface is on the A.B.C.128 network, which should allow host IPs ranging from .129-.190

My outside router is .129, and my PIX (outside) is .130

Also, you might want to run the command 'clear xlate' after making these changes and before trying to get out through the pix

*nods* Thanks (though I was aware, and doing so).

the "outside" interface is on the A.B.C.128 network, which should allow host IPs ranging from .129-.190

Ah yes. Sorry about that. I was thinking .130-.192 for some reason.

Well, I'm all outta ideas. Sorry I couldn't help.

- trs

I don't think you have a problem with the NAT thing (since you aren't really using it). I believe you have a routing problem.

Have you configured it with RIP, OSPF, EGRP or something like it?
Yes, it's a firewall, but it's a Cisco, so it's a router at heart ;-)

I've taken a CCNA course at school (twice even), but it's really rusty... Never got around to taking the actual Exam either.
Anyway, whenever we experienced the problem it seems you have, it was because we had [censored] something up in the routing stuff.

Well, I'm all outta ideas. Sorry I couldn't help.

Hey..thanks a lot for the effort. Even if we haven't licked it yet, I do appreciate the help.

I don't think you have a problem with the NAT thing (since you aren't really using it). I believe you have a routing problem

I'm inclined to agree with you. You can't really not configure nat..you *have to* use it on some level, as I understand it...even if you're using it to tranlsate an address back to itself (or what they call identity NAT). We've spent a lot of time looking at the nat command, but I'm not sure anymore that it's where my problem lies.

I kept thinking about the route command and maybe a misconfiguration there, but that seems pretty straightforward.

Have you configured it with RIP, OSPF, EGRP or something like it?

Yeah..I did try enabling both RIP and EGRP on the device at various times (though not concurrent) to see if that would help move things along, but to no avail.

I'm sure I'm getting closer, and probably still yet missing something obvious that I'm going to slap myself for later.

I'm wondering maybe if this doesn't have anything to do with the PIX configuration at all, but maybe rather my router. This is the double-Jeopardy bonus question...

Assuming my PIX passes along a packed from an untranslated IP on the A.B.C.192 subnet to the router, which has its interface on the A.B.C.128 subnet, will it know what to do with it? Does PIX in this instance perhaps do something to the request that makes it valid on the .128 subnet? If not, how does one get the router on the outside to field requests on the .192 subnet?

Food for thought. Maybe why this is why I have much better luck when configuring using NAT/PAT, because the request itself "becomes" a request from the PIX's outside interface on the .128 network, which the router can field from there.

FIIK.

I'm wondering maybe if this doesn't have anything to do with the PIX configuration at all, but maybe rather my router.

I bet you're right. We had a very similar problem with a PIX 501 that we installed a little over a year ago. For some reason it wasn't playing well with the routers, so we solved the problem by adding static routes for our ip block to the pix outside interface. You might want to give that a try and see what happens.

- trs

Okay, stupid question, but since I don't know how your network was configured before:

Do you now have the hosts trying to traverse the PIX with the internal interface of the PIX as their default route?

Oh, and I'm going to have to second the other opinion that the PIX is about the worst firewall ever, with the possible exception of SonicWall products. The PIX CLI is awful, whereas the Cisco router CLI makes a lot of sense, IMO. I wonder if they acquired PIX from somewhere else?

Do you now have the hosts trying to traverse the PIX with the internal interface of the PIX as their default route?

Yes I do. At least the host that is now behind the PIX for test purposes. I'm using the .192 segment specifically for trying to get the firewall configuration knocked out. The rest of my network use the router's IP at .129 as it always has, since they're all on the same network as the router (and now, the outside interface on the PIX).

I'll take into consideration all the advice I'm getting about firewall makes and models the next time I'm making the purchasing decision, but so far that's never been my role.

Yep. Found the solution...

Turns out my PIX config was correct all along, and I just needed to create a static route on the outside router to point traffic for that subnet back to the PIX. This in hindsight seems quite logical, but..isn't that the way hindsight works?

Hehe... At least you figured it out ^_^

Hindsight is, annoyingly, always 20/20 or better.

Oh man, that's awesome you got it working. I should have mentioned the router problem right from the start, I don't know why I didn't. We had basically the exact same problem as you. Keep in mind in the future, though that those static routes exist. We just recently had some down time due to the fact that we changed some of our router configuratiuons and forgot about the static routes to our pix. Just a little foresight for ya.

- trs

That's exactly what I was going to suggest after you said that you'd reconfigured the network. I guess I should check the BBS more often.