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 Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

ACLs for a range of ports (Pix525 version6.1) 1

Status
Not open for further replies.

yowza

Technical User
Nov 28, 2001
121
US
I have been reading this forum for a couple of weeks and am astounded at the wealth of helpful information in here. I have to admit that I don't understand alot of what I read but I'm getting better..) Using this forum and the Cisco Pix Command Ref Manual I have been able to set up a basic configuration that allows traffic from any host coming in using ports 389, 390, 443, and 636 destined for 4 hosts behind the Pix. I think that these 4 hosts can respond out of the Pix using the same ports. My config is listed below. These are not my real addresses.
My questions are:

1. I need to allow a backup server (located outside) access to everything inside the pix to back up these servers. The server 229.22.1.5 requires the following ports: 512 thru 5000, 13720, 13721, 13722 and 13782. Will the following acl's work? I don't have a way to test this because I don't have the Veritas software.

access-list acl_bkup permit tcp host 229.22.1.5 any range 512-5000
access-list acl_bkup permit tcp host 229.22.1.5 any range 13720-13722
access-list acl_bkup permit tcp host 229.22.1.5 any 13782
access-list acl_bkup permit udp 229.22.1.5 any range 512-5000
access-list acl_bkup permit udp host 229.22.1.5 any range 13720-13722
access-list acl_bkup permit udp host 229.22.1.5 any 13782
access-group acl_bkup in interface outside

2. Will the above statements allow traffic to flow back from the inside to outside or do I need another access-group for in interface inside?

3. You may have noticed the use of ports 390 & 637. These are officially assigned for UIS and LANSERVER, however, we (customer) are using these addresses for something else. I personally don't think we should but this is how the customer has been doing it for the last couple of years. Any thoughts on this?

4. I don't need the fixup protocols. Would it hurt to precede all of the fixup statements with no?

5. I welcome any comments/suggestions and criticism with the configuration. This is my first time working with the Pix or any network device and I always learn by my mistakes. I don't even know if its kosher to use someone else's IP addresses as an example like I did.

Thanks!

PIX Version 6.1(3)
nameif ethernet0 outside security0
nameif ethernet1 inside security100
nameif ethernet2 intf2 security10

fixup protocol http 80
fixup protocol rtsp 554
fixup protocol sqlnet 1521
fixup protocol h323 1720
fixup protocol skinny 2000
fixup protocol sip 5060
fixup protocol smtp 25
fixup protocol rsh 514
fixup protocol ftp 21
names
access-list acl_out permit tcp any host 169.117.38.23 eq 389
access-list acl_out permit tcp any host 169.117.38.23 eq 636
access-list acl_out permit tcp any host 169.117.38.23 eq 390
access-list acl_out permit tcp any host 169.117.38.23 eq 443
access-list acl_out permit tcp any host 169.117.38.27 eq 389
access-list acl_out permit tcp any host 169.117.38.27 eq 636
access-list acl_out permit tcp any host 169.117.38.27 eq 390
access-list acl_out permit tcp any host 169.117.38.27 eq 443
access-list acl_out permit tcp any host 169.117.38.26 eq 389
access-list acl_out permit tcp any host 169.117.38.26 eq 636
access-list acl_out permit tcp any host 169.117.38.26 eq 390
access-list acl_out permit tcp any host 169.117.38.26 eq 443
access-list acl_out permit tcp any host 169.117.38.13 eq 389
access-list acl_out permit tcp any host 169.117.38.13 eq 636
access-list acl_out permit tcp any host 169.117.38.13 eq 390
access-list acl_out permit tcp any host 169.117.38.13 eq 443
access-list acl_out permit icmp any any
access-list ping_acl permit icmp any any
interface ethernet2 auto
mtu outside 1500
mtu inside 1500
mtu intf2 1500
ip address outside 169.117.38.30 255.255.255.0
ip address inside 123.252.202.90 255.255.255.0
ip address intf2 192.168.0.1 255.255.255.0
ip audit info action alarm
ip audit attack action alarmstatic (inside,outside) 169.117.38.13 123.252.202.20 netmask 255.255.255.255 0 0

access-group acl_out in interface outside
route outside 0.0.0.0 0.0.0.0 169.117.38.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 h323 0:05:00 si
p 0:30:00 sip_media 0:02:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server RADIUS protocol radius
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable
no sysopt route dnat
telnet timeout 5
ssh timeout 5
terminal width 80
: end
no failover
failover timeout 0:00:00
failover poll 15
failover ip address outside 0.0.0.0
failover ip address inside 0.0.0.0
failover ip address intf2 0.0.0.0
arp timeout 14400
nat (intf2) 1 0.0.0.0 0.0.0.0 0 0
static (inside,outside) 169.117.38.23 123.252.202.100 netmask 255.255.255.255 0 0
static (inside,outside) 169.117.38.27 123.252.202.50 netmask 255.255.255.255 0 0
static (inside,outside) 169.117.38.26 123.252.202.10 netmask 255.255.255.255 0 0
pager lines 24
logging on
logging buffered debugging
logging trap debugging
logging history debugging
logging host intf2 192.168.0.2
interface ethernet0 auto
interface ethernet1 auto
 
HI.

>> access-group acl_bkup in interface outside
You can not apply more then a single access-list per interface, so you should add entries to the existing "acl_out" instead.

>> Will the above statements allow traffic to flow back from the inside to outside ...
Yes, the pix is statefull, so it should allow return traffic without the need for you to specify it.

>> 4. I don't need the fixup protocols. Would it hurt to precede all of the fixup statements with no
It should not make a problem.

>> 5. I welcome any comments ...
I understand that this pix works inside a LAN, not as perimeter device, right?
>> logging buffered debugging
>> logging trap debugging
>> logging history debugging
Such debugging can degrade performance.
You can disable logging buffered and maybe logging history because you have the syslog server, and better use level 6 (info) or lower, depending on the level you need.
Level 6 also generates a lot of messages but lower levels will not tell you about traffic that passed the firewall, so it depends on your specific scenario.

For auditing legitimic traffic and blocked traffic, use level 6 at the expense of logging overhead and syslog server disk space.
For auditing blocked traffic only, use level 4.

Bye



Yizhar Hurwitz
 
Many thanks Yizhar!! I greatly appreciate your help. Can I assume (uh-oh) that my proposed access list statements are correct and that they will do what I expect them to as stated in nbr 1. ?

Regards,
yowza
 
HI.

You can assume it will work but must try it before, and also check for other issues not directly related to the pix like name resolution, ip addressing and routing, etc...

The host from outside will be able to access only internal hosts that have "static" mapping, unless you are adding "nat 0 access-list" to support backup server access to other internal hosts.

Bye
Yizhar Hurwitz
 
Thanks again yizhar. I have the static (inside,outside). I will read up on what the nat 0 access-list thing is. I don't remember running across that.

yowza
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top