Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations biv343 on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Default outbound ports on Pix 515R 1

Status
Not open for further replies.

Zelandakh

MIS
Mar 12, 1999
12,173
GB
I'm trying to allow an application on an internal machine to go out to an externally hosted site.

For security reasons I don't want to say which port but it is fixed. Let's call it 9021.

I thought the Pix allowed anything out by default...?

I have this at the top:
nameif ethernet0 outside security0
nameif ethernet1 inside security100

so I should be ok.

If all ports are not allowed out by default, how do I allow specific ports out (and then data coming back, back in again)?

This used to work and the only thing that has been changed is someone changed us to access lists...
 
Well, that depends....do you have an acl on your inside interface ? That could be your problem.

Jan

Network Systems Engineer
CCNA/CQS/CCSP
 
I have an acl as follows:

access-list acl_outside in interface outside

This I THINK is the outside interface. I seem to be able to go out from inside using any protocol specified on the fixup list (ftp, smtp etc).
 
Well, if you don't have an inside acl then all traffic is permitted out, the only thing you need to permit is from the outside, but only if the session is initiated from the outside or the return packets in a session use another port than the one the client has established a session on.

Jan

Network Systems Engineer
CCNA/CQS/CCSP
 
If you don't have an outbound access list applied then ALL ports are allowed from the INSIDE to the OUTSIDE based on the Pix ASA, traffic from the high security interface is allowed to the low security interface by default.

If your application isn't working then unless you can see logging on the Pix showing the traffic being blocked your problem could be elsewhere. If I had a penny for everytime a user has blamed the firewall first for something not working but it's turned out to be something else wrong then I'd be able to retire now!

Chris.


**********************
Chris Andrew, CCNA, CCSA
chris@iproute.co.uk
**********************
 
Hehe, i would be richer than Bill G. himself if that were to happen.

Jan

Network Systems Engineer
CCNA/CQS/CCSP
 
How about a translation? Do you have nat and globlal statements configured?
 
NAT and Global are connected.

Since the Pix went down 3 weeks ago (a story to be told over a beer as it wasnt our fault), everyone has blamed me/the firewall for everything not working.

So I assumed it was a firewall issue.

Chris - turns out I can't even get to the server on port 80. Tracert fails after 23 hops.

The ISP is checking to see why.

Doh! Sometimes I wish I was a farmer...
 
Issue a "show local-host <internal-ip>" command to determine if a transaltion exists for your client. If it exists then try to look into syslogs to see if the PIX is deniying this traffic. If it isn't, run the following debug on the pix:

debug packet outside dst <destination-ip> netmask 255.255.255.255

You should be able to see the packets on the console, if you see the packets then your problem may be on the outside router or somewhere else outside the PIX. Try to sniff the outside network to determine if the replies are coming back.

By the way you disable the debug with the command:

no debug packet outside
 
Thanks themut - have a star on me! 3 really useful little lines.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top