Setup of PIX501 6.3(5)

       xxx.yyy.82.118/28
            netgear router
              10.168.0.1/24          (All traffic forwarded to 10.168.0.2/24, except for ort 80 and 25 which goes to 10.168.0.3)

                     |--------------------------------------------------------------------------------------
                     |                                                                                                           |
            10.168.0.2/24 (static of 0.3 also)                                                                                  10.168.0.2/24
               Pix 501                    --- Exchange/web/OWA----------------------           ISA Server
            192.168.0.254/24             192.168.0.100/24                                        192.168.0.1/24

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) 10.168.0.3 192.168.0.100 netmask 255.255.255.255
access-list Outside-In permit tcp any host 10.168.0.3 eq 25
access-list Outside-In permit udp any host 10.168.0.3 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 192.168.0.100 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.

Thanks.
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 10.168.0.3 eq 80

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

Chris
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)

Cheers
Keith
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.

cci94Commented:
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 192.168.0.100 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.

--Jeff
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) 10.168.0.3 192.168.0.100 netmask 255.255.255.255
access-list Outside-In permit tcp any host 10.168.0.3 eq 25
access-list Outside-In permit tcp any host 10.168.0.3 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.


Chris
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
domain-name internal.com
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
names
name 10.168.0.3 smtp_in
access-list inside_outbound_nat0_acl permit ip any 192.168.1.0 255.255.255.128
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 10.168.0.2 255.255.255.0
ip address inside 192.168.0.254 255.255.255.0
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 192.168.1.1-192.168.1.100
pdm location 192.168.0.1 255.255.255.255 inside
pdm location 192.168.1.0 255.255.255.128 outside
pdm location smtp_in 255.255.255.255 outside
pdm location 192.168.0.100 255.255.255.255 inside
pdm history enable
arp timeout 14400
global (outside) 1 interface
nat (inside) 0 access-list inside_outbound_nat0_acl
nat (inside) 1 192.168.0.0 255.255.255.0 0 0
static (inside,outside) smtp_in 192.168.0.100 netmask 255.255.255.255 0 0
access-group Outside-In in interface outside
route outside 0.0.0.0 0.0.0.0 10.168.0.1 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 192.168.0.1 255.255.255.255 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 192.168.0.0 255.255.255.0 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
Cryptochecksum:8bf321a0534e04dc4ab36b1ccbcda005
: end
[OK]

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.


Cheers

Chris
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.

Cheers
Keith
cci94Commented:
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.  

--Jeff

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
Voltz-dkCommented:
"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 10.108.0.3, 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..
Voltz-dkCommented:
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 10.168.0.3'.

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.




Voltz-dkCommented:
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 192.168.0.100 to do DNS lookups, which will effectively break everything unless your desktops are using an in-house DNS server.

Is it so that 192.168.0.100 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) 192.168.0.100 is "broken".
Keith AlabasterEnterprise ArchitectAuthor Commented:
All machines have their DNS performed by 192.168.0.100.
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 10.168.0.2 which is the physical interface.

Voltz-dkCommented:
>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 192.168.0.100 (which was doing DNS) would still be mapped to the "unreachable" 10.168.0.3

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.

Thx

Keith
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.