Setup of PIX501 6.3(5)

            netgear router
              (All traffic forwarded to, except for ort 80 and 25 which goes to

                     |                                                                                                           |
   (static of 0.3 also)                                                                        
               Pix 501                    --- Exchange/web/OWA----------------------           ISA Server

Above is my setup which up until this evening has worked perfectly for everything with the ISA dealing with all incoming/outgoing traffic. The Pix had no ACL's at all apart from the standard setup and just allowed me to play.

This evening i tried to setup some ACL's on the PIX so that I could remove and rebuild my ISA server. As soon as I put any form of ACL on to the PIX, all traffic seemed to stop through it. However, if I don't put an ACL on, my incoming mail obviously doesn't get through.

Although I have six useable IP addresses, all my DNS records point to the external IP address of my netgear and this forwards all traffic to the Pix (does now anyway).

The acl's I tried were these:  (I thought I'd need to give the internal Exchange/web box an IP from the DMZ area between the netgear and the PIX)

static (inside,outside) netmask
access-list Outside-In permit tcp any host eq 25
access-list Outside-In permit udp any host eq 80
access-group Outside-In in interface outside
access-list Inside-Out permit tcp any any eq 25
access-list Inside-Out permit tcp any any eq 80
access-list Inside-Out permit udp host any eq 53
access-list Inside-Out permit tcp any any eq 443
access-list Inside-Out permit tcp any any eq 21
access-group Inside-Out in interface inside

Any pointers would be appreciated as I feel I am being a numpty and something is staring me in the face but I'm not seeing it.

LVL 51
Keith AlabasterEnterprise ArchitectAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Keith AlabasterEnterprise ArchitectAuthor Commented:
access-list Outside-In permit tcp any host eq 80

sorry, mistyped the line
Chris StauntonCommented:
Have you tried to remove the Inside-Out access lists and see if it works?

Keith AlabasterEnterprise ArchitectAuthor Commented:
As mentioned, with no ACL's everything works fine. However, it seems that as soon as I put an ACL on the incoming, the outgoing stops as well.

What I need to achieve is:

Allow incoming traffic from outside to get to my Exchange server for both port 25 and 80
Allow everything and anything to go out (and relevant responses to get back in)

Introduction to R

R is considered the predominant language for data scientist and statisticians. Learn how to use R for your own data science projects.

There is an implied "deny all" at the end of every PIX access list.  The list you are apply to the inside interface is blocking everything except www, smtp and some FTP traffic.  I believe you are only allowing to do DNS lookups, which will effectively break everything unless your desktops are using an in-house DNS server.  

We don't generally apply an access-list to the inside interface.  Maybe I'm just sleepy but I'm not sure what you're trying to accomplish with yours.  Try removing it (no access-group  Inside-Out in interface inside) and I think you'll find that everything works as desired.

Hope that helps.  Happy New Year.

Keith AlabasterEnterprise ArchitectAuthor Commented:
Happy new year to you as well.

Same thing Jeff. Removed all ACL's

Everything is working perfectly except incoming web/smtp.
As soon as I re-apply just this section

static (inside,outside) netmask
access-list Outside-In permit tcp any host eq 25
access-list Outside-In permit tcp any host eq 80
access-group Outside-In in interface outside

I cannot get to the Internet at all from any of my client machines.
Chris StauntonCommented:
Can you paste the entire config?  I'm guessing that there's something that we're not seeing that's causing this problem.  The ACL looks good, so I'm guessing there's sometihing else in your config that's hanging you up.

Keith AlabasterEnterprise ArchitectAuthor Commented:
Building configuration...
: Saved
PIX Version 6.3(5)
interface ethernet0 auto
interface ethernet1 100full
nameif ethernet0 outside security0
nameif ethernet1 inside security100
enable password yhGZphzWgDCS6Lb3 encrypted
passwd yhGZphzWgDCS6Lb3 encrypted
hostname kapix
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
no fixup protocol smtp 25
fixup protocol sqlnet 1521
fixup protocol tftp 69
name smtp_in
access-list inside_outbound_nat0_acl permit ip any
access-list Outside-In permit tcp any host smtp_in eq smtp
access-list Outside-In permit tcp any host smtp_in eq www
pager lines 24
logging timestamp
logging trap notifications
logging history notifications
logging facility 16
mtu outside 1500
mtu inside 1500
ip address outside
ip address inside
ip verify reverse-path interface outside
ip verify reverse-path interface inside
ip audit info action alarm
ip audit attack action alarm
ip local pool vpn-in
pdm location inside
pdm location outside
pdm location smtp_in outside
pdm location inside
pdm history enable
arp timeout 14400
global (outside) 1 interface
nat (inside) 0 access-list inside_outbound_nat0_acl
nat (inside) 1 0 0
static (inside,outside) smtp_in netmask 0 0
access-group Outside-In in interface outside
route outside 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 sip-disconnect 0:02:00 sip-invite 0:03: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
http server enable
http inside
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable
sysopt connection permit-pptp
sysopt noproxyarp outside
sysopt noproxyarp inside
telnet inside
telnet timeout 30
ssh timeout 30
console timeout 0
vpdn group PPTP-VPDN-GROUP accept dialin pptp
vpdn group PPTP-VPDN-GROUP ppp authentication mschap
vpdn group PPTP-VPDN-GROUP ppp encryption mppe 40
vpdn group PPTP-VPDN-GROUP client configuration address local vpn-in
vpdn group PPTP-VPDN-GROUP pptp echo 60
vpdn group PPTP-VPDN-GROUP client authentication local
vpdn username keith.alabaster password *********
vpdn enable outside
terminal width 80
: end

Chris StauntonCommented:
Looks like a very clean config... only question I can think of is are you sure that ethernet1 is 100full?  Maybe set it to auto and test.


Keith AlabasterEnterprise ArchitectAuthor Commented:
No, thats fine Chris. As I say, simply removing the ACL and everything works. However, there is then nothing there to let the email through to my internal server. Going to sleep on it for a while, maybe I have just been looking at it for too long tonight.

There are a couple of statements that seem unusual to me.

I do a bunch of the 500 series firewalls but I had to look up the "ip verify reverse-path" command.  Here's what I found on Cisco's site:

the "ip verify reverse-path interface inside" command statement protects the inside interface from network egress attacks from users on the internal network

Sounds to me like it prevents certain packets from leaving the internal network.  It seems like it would be worth trying things without the two "ip verify reverse-path" statements, just as a test if nothing else.

The other statements that seem odd to me (just my $0.02) are the "sysopt noproxyarp" commands.  These are familiar to me, but seem out of place in your config.  Maybe I'm missing something, but I'd try removing those as well.

My thought is that one or both of these only take affect when ACLs are used and are otherwise unused.

Hope that helps.  That's all for me for tonight, too -- it's time for me to go make the band louder.  :-)

Good luck.  


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
"ip verify reverse-path" is the PIX implementation of anti-spoofing - the important parts to have in place here is routing.  I don't think they are causing harm in this setup.

I agree with cci94 that the noproxyarp is a problem though.  At least on the outside.  The router will arp for, and without proxyarp the PIX won't reply - packet lost.  But that only explains the inbound traffic, I have to look further for theory on the outbound..
I just can't see why the outbound traffic shouldn't work.  Got any logs that could shed some light?
Keith AlabasterEnterprise ArchitectAuthor Commented:
Ran ethereal on the outside interface between the router and the PIX and you were spot on. The netgear was was trying to identify 'who has'.

Removed noproxyarp from the external interface and bingo. All outgoing has burst into life and email is coming in perfectly. The part I am unclear on is why this would affect the traffic other than the smtp?
Is it possible that the statement <<access-list Outside-In permit tcp any host smtp_in eq www>> would act upon returning port 80 traffic rather than new port 80 traffic initiated from the outside?

Happy new year by the way.

Happy new year!

No I don't think so - I don't believe the access-list does anything.  It's all about the static.

And re-reading a post, I suddenly got an idea:

>I believe you are only allowing to do DNS lookups, which will effectively break everything unless your desktops are using an in-house DNS server.

Is it so that is doing the lookups?  Then that could explain it..  Did you try outbound access from any other machine than this, using pure IP?

Cuz with the static in place (and no proxyarp) is "broken".
Keith AlabasterEnterprise ArchitectAuthor Commented:
All machines have their DNS performed by
The problem stayed though after I had removed the outbound ACL. From that point, as no ACL was in place (for outbound), that restriction would no longer be in force.

I think this is though, in essence, the crux of it. removing the noproxyarp seems to have fixed it all but I was curious as to why it affected the other traffic that did not need proxy arp'ing such as the traffic that would have come back directly to which is the physical interface.

>The problem stayed though after I had removed the outbound ACL.
Yes, but that is because the problem was the combination of the static and noproxyarp.

>From that point, as no ACL was in place (for outbound), that restriction would no longer be in force.
But (which was doing DNS) would still be mapped to the "unreachable"

My guess is your outbound access worked (aside from this one server), but it seemed not to because this one server did the DNS.
Keith AlabasterEnterprise ArchitectAuthor Commented:
Yep, agreed.


It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Networking Protocols

From novice to tech pro — start learning today.