RE: Problem with TCP 1433, conduits and ACLs...

["Wes Noonan" <mailinglists () wjnconsulting com>]

Yes, I had an access group. I had 15 other ACLs on that interface, including
others for that server, that worked great.

Thanks.

Wes Noonan
281-208-8993
wnoonan () houston rr com
http://www.wjnconsulting.com 


> -----Original Message-----
> From: Wes Noonan [mailto:mailinglists () wjnconsulting com]
> Sent: Wednesday, November 26, 2003 13:22
> To: 'firewall-wizards () nfr net'
> Subject: Problem with TCP 1433, conduits and ACLs...
>
> Had a strange problem last night doing a PIX upgrade. Here is the
> scenario:
>
> 2 PIX515E in failover configuration. Upgraded the PIXOS to 6.3(3) from
> 6.1(4). Installed new activation key for 3DES (they have UR license). The
> next step was to convert a bunch of conduits and statics to ACLs.
>
> The original statics were "open". IP x to IP y kind of stuff. We converted
> them to port specific statics. The conduits were also converted to ACLs.
> Seemed pretty straight forward. When we applied the changes, everything
> seemed to be working except for one webserver. The server build the web
> pages from a SQL database running on the internal network. The server
> would not load any pages and displayed a custom error message that
> essentially stated "I can't access the database". Every other system
> worked fine however, and for the real kicker I could telnet from the
> webserver to TCP 1433 on the SQL server and get the SQL session to come
> up.
>
> The original conduit/static was as follows:
> static (inside,dmz) 172.16.11.134 172.16.4.134 netmask 255.255.255.255 0 0
> conduit permit tcp host 172.16.11.134 eq 1433 host 172.16.8.101
>
> The new ACL/static was as follows:
> static (inside,dmz) tcp 172.16.11.134 1433 172.16.4.134 1433 netmask
> 255.255.255.255 0 0
> access-list dmz_ingress_01 permit tcp host 172.16.8.101 host 172.16.11.134
> eq 1433
>
> In looking at the logs, I could see the hit count on the ACL increasing. I
> could also see the sessions being created, but I never saw any data
> passing. I added the "log" option to the ACL as well as putting an
> explicit "deny ip any any log" entry and never saw anything that indicated
> why the system wouldn't work. I was not running the sqlnet fixup on that
> port number.
>
> I am pretty much at a loss for what the problem was. In the end we decided
> to roll back the ACLs for the DMZ and put the old conduits back in place
> with the new static statements. As soon as we did that, it started working
> fine. Clearly there seems to be an issue with how the PIX is handling the
> ACL traffic as opposed to the conduit traffic, but I can't see what that
> might be. TIA.
>
> Wes Noonan
> 281-208-8993
> wnoonan () houston rr com
> http://www.wjnconsulting.com


_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards