Access List Problems

9clord · ‎02-06-2004

We have an issue with a particular access list. We need to allow traffic from a single server outside a pix 506 to access a server inside the firewall over port 3306. Software version is 6.3.1.

The problem is, we can allow access between the two servers over any other port except the one that we need. Also, we can allow access from any other location to the server behind the firewall over port 3306. If I say allow all traffic to the internal server over 3306 then you can access it from anyplace except from the server we relly need to be able to talk over 3306. If I telnet from a workstation outside the firewall to 3306, then the count on the access list increases by one and we are able to get a response. If I try to telnet to 3306 from the server that needs to talk over 3306, then the count on the access list does not increment by one and we do not get a response.

There was originally a static mapping for the server on the inside that allowed for traffic to pass between the two servers, but it was a no nat statement (e.g. static (inside,outside) 10.1.1.1 10.1.1.1 255.255.255.255). This along with a host file on the server outside the firewall and a static route in the gateway router allowed for traffic to pass between the two servers. Note that the server that needs access to the internal server is "directly" outside the firewall (plugged into a hub basically on the outside interface of the PIX). The problem is that in this configuration the internal server cannot access the internet. This was the situation that we inherited.

I created a static mapping to a real public address and then created access lists to allow traffic through to the internal server from the outside. This works on all ports except the one that I need. I tried specific access lists allowing traffic from outside to the port 3306, but those did not work either. When I allow traffic on all ports, I can telnet to port 80 (for example) but not on port 3306. So I know that the routing and access lists are working.

I have seen similar situations where access lists have had this problem when adding new ports and have resolved by blowing away the static mapping and the acl and then manually re-creating. I tried this and this did not resolve the issue either. Has anyone else run into a similar situation and if so, did you find a workaround that didn't involve a full reload of the config? This FW has all kinds of VPN connections to it so a reload will cause the reconfig of all of those connectiosn on both ends (I believe anyway). Any ideas on this would be greatly appreciated.

Thank You,

Chad

mostiguy · ‎02-07-2004

whoa, I think you need to start all over with that post. I am bewildered as to what your config is:

1. the outside server cannot talk to the inside server on tcp 3306?

2. can any other internet host talk to the inside server on tcp 3306?

3. do you know for certain that there is a service running on the nside server on tcp 3306?

4. do you have any logs of blocked packets?

5. can you postyour config?

9clord · ‎02-07-2004

Sorry, here's the short version:

With this config:

static (inside,outside) 209.xxx.xxx.xx2 10.xxx.xxx.xxx netmask 255.255.255.255 0 0

access-group outside_access_in in interface outside

access-list outside_access_in permit ip host 209.xxx.xxx.xx1 host 209.xxx.xxx.xx2

I can telnet from 209.xxx.xxx.xx1 to 209.xxx.xxx.xx2 on any port except 3306.

If I put in a line like:

access-list outside_access_in permit tcp any host 209.xxx.xxx.xx2 eq 3306

I can telnet to port 3306 from any machine anywhere except I can't telnet to port 3306 from 209.xxx.xxx.xx1

To answer your questions:

1. The outside server cannot talk to the inside server on tcp 3306

2. Other hosts can talk to the inside server on 3306 if an access-list is put in to allow it

3. There is definitely a service running on the inside server on 3306.

4. I need to doublecheck the logs, but there was nothing showing up.

5. If the info above isn't enough of the config to explain the situation, I can post it.

Thanks

mostiguy · ‎02-07-2004

that is bizarre. you are doing all of your testing by ip, so name resolution is not an issue?

if you are running a recent pix os (6.2+ iirc), you can use the capture command to do a packet capture on the pix. you might want to break out a packet sniffer on the cable to the inside server, or run one on it if you have it installed.

it is really weird that the outside server can access all services on the inside box when you have an access list that "permits ip host outside host inside". anything different software wise on the outside server than from the other outside machines that you have used to test conns to the inside machine on tcp 3306?

9clord · ‎02-07-2004

It is strange. The only thing I can think of is that something is cached someplace. We've tested conns from every type of machine applicable, both windows and linux platforms. Tested by IP and by name. Names resolve, but access is not granted.

Have restarted everything, cleared caches, taken out and re-added access-lists, etc. But nothing has worked.

The PIX OS is 6.3.1 so maybe I can do a capture. There is nothing in the logs at all.

I am looking at changing the IP's on the boxes to see if that will help.

The inside server used to have a different static mapping. So I don't know if something is hidden in a cache someplace. Have you ever heard of a situation similar to this?

rjackson · ‎02-07-2004

It sounds like the problem is at the network where the other server is. It sounds like they have their access list reversed so it is allowing everything except what you want.

baileja · ‎02-08-2004

Could you post the rest of your config? I would like to see the rest of the ACL especially.

9clord · ‎02-08-2004

Outside host is 209.x.x.9

Note: It has multiple IP's assigned to the NIC (.9, .10, and .11) which is the reason for the 3 access lists allowing traffic to .12. Although all of the traffic appears to be coming in on .9, they are mainly there for testing right now.

Inside host is 209.x.x.12 (10.x.x.245).

static (inside,outside) 10.x.x.242 10.x.x.242 netmask 255.255.255.255 0 0

static (inside,outside) 209.x.x.4 209.x.x.4 netmask 255.255.255.255 0 0

static (inside,outside) 209.x.x.12 10.x.x.245 netmask 255.255.255.255 0 0

access-group outside_access_in in interface outside

access-list outside_access_in permit icmp any any echo-reply

access-list outside_access_in permit tcp host 209.x.x.9 10.x.x.0 255.255.255.0

access-list outside_access_in permit tcp host 209.x.x.4 10.x.x.0 255.255.255.0

access-list outside_access_in permit udp host 209.x.x.4 10.x.x.0 255.255.255.0

access-list outside_access_in permit icmp any host 209.x.x.12

access-list outside_access_in permit ip host 209.x.x.9 host 209.x.x.12

access-list outside_access_in permit ip host 209.x.x.10 host 209.x.x.12

access-list outside_access_in permit ip host 209.x.x.11 host 209.x.x.12

access-list outside_access_in permit tcp any host 209.x.x.12 eq ssh

Have tried:

access-list outside_access_in permit tcp 209.x.x.9 host 209.x.x.12 eq 3306

and

access-list outside_access_in permit tcp any host 209.x.x.12 eq 3306

With the second acl above, I can telnet to 3306 from any machine except 209.x.x.9.

Here is a sho access-li:

access-list outside_access_in; 9 elements

access-list outside_access_in line 1 permit icmp any any echo-reply (hitcnt=4277)

access-list outside_access_in line 2 permit tcp host 209.x.x.9 10.x.x.0 255.255.255.0 (hitcnt=197)

access-list outside_access_in line 3 permit tcp host 209.x.x.4 10.x.x.0 255.255.255.0 (hitcnt=0)

access-list outside_access_in line 4 permit udp host 209.x.x.4 10.x.x.0 255.255.255.0 (hitcnt=185)

access-list outside_access_in line 5 permit icmp any host 209.x.x.12 (hitcnt=155)

access-list outside_access_in line 6 permit ip host 209.x,x.9 host 209.x.x.12 (hitcnt=4)

access-list outside_access_in line 7 permit ip host 209.x.x.10 host 209.x.x.12 (hitcnt=0)

access-list outside_access_in line 8 permit ip host 209.x.x.11 host 209.x.x.12 (hitcnt=0)

access-list outside_access_in line 9 permit tcp any host 209.x.x.12 eq ssh (hitcnt=4)

The hittcnt of 4 on line 6 are successful telnet sessions from the outside host to the inside host on port 80. When I try to telnet to 3306, the hitcnt does not increase.

There are other ACL's related to VPN connections, but there is no occurrance of 3306, 209.x.x.12, 10.x.x.245, or 209.x.x.9 in any of the other lists. If you think those would be helpful I can post those too.

Thank You.

baileja · ‎02-08-2004

Very strange. Your config looks ok. Do you have any ACL's applied to the inside interface? Can you ping 209.X.X.9 from 209.X.X.12? This is very strange.....