SQLNET (JDBC) through PIX

maraz · ‎03-07-2007

Hello, I have a problem with SQLNET traffic through a PIX. There is an application called OAS - OracleApplicationSuite enterprice 9.1.0.7. Thin JDBC (XML). We have three interfaces on the PIX. From the inside to the DMZ there is no problem accessing this application. From the outside there is a problem and we get this error:

2007-02-16 09:14:28 info 194.71.17.62 %PIX-6-302013: Built inbound TCP connection 9955928 for DMZ:10.251.128.109/40648 (10.251.128.109/40648) to Database:10.251.129.223/1521 (10.251.129.223/1521)

2007-02-16 09:14:28 info 194.71.17.62 %PIX-6-302014: Teardown TCP connection 9955928 for DMZ:10.251.128.109/40648 to Database:10.251.129.223/1521 duration 0:00:00 bytes 85837 TCP Reset-I

2007-02-16 09:31:01 info 194.71.17.62 %PIX-6-302013: Built inbound TCP connection 9959600 for DMZ:10.251.128.109/41209 (10.251.128.109/41209) to Database:10.251.129.222/1521 (10.251.129.222/1521)

2007-02-16 09:31:02 info 194.71.17.62 %PIX-6-302014: Teardown TCP connection 9959600 for DMZ:10.251.128.109/41209 to Database:10.251.129.222/1521 duration 0:00:00 bytes 85835 TCP Reset-I

Debug sqlnet:

ERROR: failed to open secondary connection

INFO: intercepted port is 7169

SQL*Net V1(before):

ERROR: failed to open secondary connection

INFO: intercepted port is 7169

When we disable the SQLNET inspection it also works from the outside. Any ideas? Because we do not want to disable the inspection frpm outside.

Best Regards

Robert Maras

suschoud · ‎03-07-2007

The SQL*Net protocol consists of different packet types that the security appliance handles to make the data stream appear consistent to the Oracle applications on either side of the security appliance.

The default port assignment for SQL*Net is ""1521"". This is the value used by Oracle for SQL*Net, but this value does not agree with IANA port assignments for Structured Query Language (SQL). Use the class-map command to apply SQL*Net inspection to a range of port numbers.

The security appliance NATs all addresses and looks in the packets for all embedded ports to open for SQL*Net Version 1.

For SQL*Net Version 2, all DATA or REDIRECT packets that immediately follow REDIRECT packets with a zero data length will be fixed up.

The packets that need fix-up contain embedded host/port addresses in the following format:

(ADDRESS=(PROTOCOL=tcp)(DEV=6)(HOST=a.b.c.d)(PORT=a))

SQL*Net Version 2 TNSFrame types (Connect, Accept, Refuse, Resend, and Marker) will not be scanned for addresses to NAT nor will inspection open dynamic connections for any embedded ports in the packet.

SQL*Net Version 2 TNSFrames, Redirect, and Data packets will be scanned for ports to open and addresses to NAT, if preceded by a REDIRECT TNSFrame type with a zero data length for the payload. When the Redirect message with data length zero passes through the security appliance, a flag will be set in the connection data structure to expect the Data or Redirect message that follows to be NATed and ports to be dynamically opened. If one of the TNS frames in the preceding paragraph arrive after the Redirect message, the flag will be reset.

The SQL*Net inspection engine will recalculate the checksum, change IP, TCP lengths, and readjust Sequence Numbers and Acknowledgment Numbers using the delta of the length of the new and old message.

SQL*Net Version 1 is assumed for all other cases. TNSFrame types (Connect, Accept, Refuse, Resend, Marker, Redirect, and Data) and all packets will be scanned for ports and addresses. Addresses will be NATed and port connections will be opened.

Regards,

Sushil

Cisco TAC.

maraz · ‎03-07-2007

Hello, Sushil!

I have seen that in the documentation but it does not answer why it works from the inside but not from the outside. But I think I have found the answer myself:

SQL*Net inspection engine?If a control connection for the SQL*Net (formerly OraServ) port

exists between a pair of hosts, then only an inbound data connection is permitted through the

adaptive security appliance.

Best Regards

Robert Maras