Security

Ask something
Discussion Locked

Fw1 and sqlnet2 difficulties

0 helpful
4 replies

by davem 1 view

Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

I am trying to get a sqlnet2(net8) application to work through a firewall to a server that is translated.
(Cp fw-1 4.1 SP3 running on HPUX 10.20)
The TNS redirect packet from the server (NT-based) is improperly translated when passing through the firewall, the servers address (in the data portion of packet) is correctly translated BUT it also translates the port parammeter (the problem). This results in the client(external) trying to connect to a 'bad' port on the server. The fw does not translate this port back to what the server is expecting (because this is a new connection?). The log shows only the port #'s and never rejects/drops, sqlnet1 service has been removed, automatically generated NAT rule using static type address translation, and rule using the sqlnet2 service.

How can I keep the fw from translating the port parameter in the data portion of TNS redirect packet? What else do I have to do to get net8 working?

4 replies

by bkduke

It sounds as if you are using FW1's NAT hiding feature to NAT your entire internal network behind a single IP address. It normally works great. I personally have not seen it not translate the port back to its original value if used for a defined and supported IP service such as sqlnet1 or sqlnet2.

The sqlnet1 service simply matches on TCP port 1521, whereas the sqlnet2 service matches on port 1521, 1525 or 1526 in addition to digging into the packet and validating the contents, which is much more secure.

One thing that was not clear on your description was whether or not you were NAT'ing your outbound connection from the client to the server, or the NAT was the inbound side, at the server end.

If you are using NAT hiding on the outbound side try defining an Address Translation rule for the destination ahead of the NAT hiding rule already in place, ie.

orig src your internal host
orig dst sqlnet2 destination
orig svc any

tran src external translated addr (static)
tran dst sqlnet2 destination
tran svc any

You will also need to add a route on your firewall from the translated host back to the original internal host or appropriate gateway.

I realize this is only for a single internal host.However this should eliminate port translation as the cause of the problem.

You might also try defining a sqlnet2a service that just validates the sqlnet2 ports 1521, 1525 or 1526. Its less secure but it could at least let you run.

My own experience with sqlnet2 across the Internet was that we had a more difficult time with timeouts due to propigation delay than anything else. I hope your application is tuned accordingly.

Hope this helps. Good luck.

by davem

The route did the trick...I figured it out this morning...but you got the right answer.

This discussion is closed to new replies.