access-lists

[dsingleterry]

I have a question... or two... :) about access-lists.

My current access-lists looks like the following:

access-list acl_outbound permit icmp any any

access-list acl_outbound permit tcp 192.168.50.0 255.255.255.0 any eq 80

access-list acl_outbound permit tcp 192.168.50.0 255.255.255.0 any eq 21

access-list acl_outbound permit tcp 192.168.50.0 255.255.255.0 any eq 22

access-list acl_outbound permit tcp 192.168.50.0 255.255.255.0 any eq 8080

access-list acl_outbound permit tcp 192.168.50.0 255.255.255.0 any eq 443

access-list acl_outbound permit ip any any

access-list acl_inbound permit icmp any any

access-list inside_nat0_outbound permit ip 192.168.50.0 255.255.255.0 host Bluff_Outside

access-list outside_cryptomap_9 permit ip 192.168.50.0 255.255.255.0 host Bluff_Outside

1. I'm not getting any echo-reply to outside IP addresses with my permit icmp's. Do I need to specify what sort of ICMP traffic such as echo-reply on the end of the permit statement? I assumed that not putting a specific function of the permit ICMP would allow all ICMP traffic, but I guess I was wrong.

2. Also any suggestions on how to improve my access-lists would be appreciated. Just because it might 'work' doesnt mean its the best way.

Such as I noticed I had to have the permit ip any any to make it work right, but am not sure exactly what goes on when I apply that statement in order to allow the permit tcp statement to work properly.

My goals are as follows:

allow specified hosts web traffic (including https, and ftp)

allow ICMP pings to cross from inside to outside and reply

allow VPN tunnels to be established

Thank you all for your help. This forum has been very informative and helpful with previous posts as I am sure it will be with this one as well.

Dave

[tvanginneken]

Hi,

here are a few answers to your questions:

1. This access-list (which you already implemented) should allow all ICMP (so also reply) packets in:

access-list acl_inbound permit icmp any any

Did you apply this access-list to the interface on which the reply packets are arriving? If the reply packets are arriving at the outside interface. Use this command:

access-group acl_inbound in interface outside

When you don't specify a specific icmp type, then all types are included.

2. Let's look at the rest of the access-lists now. As it is right now, everything (icmp and ip) is permitted from the inside to the outside. When you want to allow only icmp, http(s) and ftp, use this access-list:

access-list acl_outbound permit icmp any any

access-list acl_outbound permit tcp 192.168.50.0 255.255.255.0 any eq 80

access-list acl_outbound permit tcp 192.168.50.0 255.255.255.0 any eq ftp

access-list acl_outbound permit tcp 192.168.50.0 255.255.255.0 any eq 8080

access-list acl_outbound permit tcp 192.168.50.0 255.255.255.0 any eq 443

and apply the access-list to the inside interface

access-group acl_outbound in interface inside

By default, all the other traffic that doesn't match the access-list is denied.

When you use these access-lists, all icmp traffic is allowed. This is fine for testing, but specify the specific icmp types afterwards to make it more secure.

If you are allowing http over port 8080, also add this line

fixup protocol http 80 8080

This way the pix know http traffic is transmitted on port 8080 and allow specific http inspection.

Keep these access-lists for you VPN traffic:

access-list inside_nat0_outbound permit ip 192.168.50.0 255.255.255.0 host Bluff_Outside

access-list outside_cryptomap_9 permit ip 192.168.50.0 255.255.255.0 host Bluff_Outside

If you have any more questions, don't hesitate to post them.

Kind Regards,

Tom

[dsingleterry]

Then I must have something set wrong again that preceeds even the access-lists...

I look at my run config and it seems to make sense, but tonight when I decided to do a test run after everyone left of this firewall (not in production yet), I couldnt get any traffic across the interfaces again. Where 2 nights ago i was getting traffic across with what seems to be the same config. I know I've got something set wrong, but for the life of me cant figure out what.

The only thing that seems really fishy is when setting NAT on the inside interface ( nat (inside) 1 0 0 ) I get this warning:

Warning: Start and End addresses overlap with broadcast address.

outside interface address added to PAT pool

Here's my full run config, sorry its sorta long but since I dont know where the problem lies, maybe someone will spot it.... (disclaimer, i know my access-lists are wide open, but I did that in order to make sure that the problem lies deeper than them)...

PIX Version 6.2(2)

nameif ethernet0 outside security0

nameif ethernet1 inside security100

nameif ethernet2 intf2 security10

enable password *********** encrypted

passwd ************ encrypted

hostname YRPCI

domain-name somename.com

fixup protocol ftp 21

fixup protocol http 80

fixup protocol h323 h225 1720

fixup protocol h323 ras 1718-1719

fixup protocol ils 389

fixup protocol rsh 514

fixup protocol rtsp 554

fixup protocol smtp 25

fixup protocol sqlnet 1521

fixup protocol sip 5060

fixup protocol skinny 2000

fixup protocol http 8080

names

name x.x.x.x Bluff_Outside

access-list acl_outbound permit icmp any any

access-list acl_outbound permit tcp 192.168.50.0 255.255.255.0 any

access-list acl_outbound permit ip any any

access-list acl_inbound permit icmp any any

access-list inside_nat0_outbound permit ip 192.168.50.0 255.255.255.0 host Bluff

_Outside

access-list outside_cryptomap_9 permit ip 192.168.50.0 255.255.255.0 host Bluff_

Outside

pager lines 24

interface ethernet0 auto

interface ethernet1 auto

interface ethernet2 auto shutdown

mtu outside 1500

mtu inside 1500

mtu intf2 1500

ip address outside pppoe setroute

ip address inside 192.168.50.1 255.255.255.0

ip address intf2 127.0.0.1 255.255.255.255

ip audit info action alarm

ip audit attack action alarm

pdm location 192.168.50.0 255.255.255.255 inside

pdm location Bluff_Outside 255.255.255.255 outside

pdm history enable

arp timeout 14400

global (outside) 1 interface

nat (inside) 0 access-list inside_nat0_outbound

nat (inside) 1 0.0.0.0 0.0.0.0 0 0

access-group acl_inbound in interface outside

access-group acl_outbound in interface inside

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

aaa-server LOCAL protocol local

http server enable

http 192.168.50.0 255.255.255.0 inside

http 192.168.50.0 255.255.255.255 inside

no snmp-server location

no snmp-server contact

snmp-server community public

no snmp-server enable traps

floodguard enable

no sysopt route dnat

crypto ipsec transform-set ESP-DES-SHA esp-des esp-sha-hmac

crypto map outside_map 9 ipsec-isakmp

crypto map outside_map 9 set peer 64.53.71.8

crypto map outside_map 9 set transform-set ESP-DES-SHA

crypto map outside_map interface outside

telnet 192.168.50.201 255.255.255.255 inside

telnet timeout 5

ssh timeout 5

vpdn group pppoex request dialout pppoe

vpdn group pppoex localname **********

vpdn group pppoex ppp authentication pap

vpdn username ********* password *********

terminal width 80

Cryptochecksum:7699e9ce70b42722c165e6a347e6d407

: end

I can ping both sides of the firewall from inside the firewall so I know the pppoe is authenticating to the dsl modem.

my access-lists return the following:

YRPCI(config)# sho access-li

access-list acl_outbound; 3 elements

access-list acl_outbound permit icmp any any (hitcnt=510)

access-list acl_outbound permit ip any any (hitcnt=287)

access-list acl_outbound permit tcp any any (hitcnt=0)

access-list inside_nat0_outbound; 1 elements

access-list inside_nat0_outbound permit ip 192.168.50.0 255.255.255.0 host Bluff

_Outside (hitcnt=510)

access-list outside_cryptomap_9; 1 elements

access-list outside_cryptomap_9 permit ip 192.168.50.0 255.255.255.0 host Bluff_

Outside (hitcnt=0)

access-list acl_inbound; 3 elements

access-list acl_inbound permit ip any any (hitcnt=0)

access-list acl_inbound permit icmp any any (hitcnt=0)

access-list acl_inbound permit tcp any any (hitcnt=0)

It doesnt seem to be crossing the interface, so is it my NAT and global that arent working? I thought I had those set right, but it seems to be the problem, again...

Again, thank you for your time, especially if you are still reading this far...

Dave

[gfullage · Accepted solution]

The issue now is that you have an incomplete crypto map on your PIX, which effectively blocks ALL traffic going out. Add the following line:

> crypto map outside_map 9 match address outside_cryptomap_9

to your PIX. This should get traffic flowing again. Although, going by the hit counters on your ACL's, are you trying to ping the host Bluff_Outside for your ping testing? If so, then your crypto config says to encrypt all that traffic as well, which is probably not going to work unless Bluff is set up correctly. Best to make things as simple as possibl while you're testing, so I would recommend taking the crypto stuff for now with:

> no crypto map outside_map interface outside

Reading back through your original post, when you had the access-list only allowing certain TCP protocols, and you found that this didn't work, was it web browsing that didn't work? If so, if you were browsing by name rather than IP address, and depending on where your DNS servers are, you probably also need to allow DNS lookups through (udp port 53). A LOT of people forget this.

Also, IMHO, most customers I've seen who start out only allowing certain protocols outbound, end up finding it's more of a pain than anything as their users say "I need to use this protocol" and "I need to use that protocol". Just be weary that if you want to go down this track without a valid reason, you may be causing a lot of additional work for yourself. What might be easier is just to make sure that your inside subnet, and only your inside subnet, can get out by doing:

> access-list acl_outbound permit ip 192.168.50.0 255.255.255.0 any

This sort of restricts any other back door connections on your inside network from using your PIX and Internet connection, but still allows all your users to get out and do whatever they want. It's up to you obviously though.