> I am wondering if it is possible to have port
> redirection in either Pix or Raptor, ie:
> Destination IP= A.A.A.A, port 1111, redirected to
> A.A.A.B, port 1111, where both IP's are behind
> the firewall?
I can't speak for the PIX. With the Raptor, yes, absolutely.
There are two ways to do this on the Raptor:
With passing any type of traffic on a Raptor, a three step
principle applies. As I used to teach it:
1) Give everything a name.
Create 'entities' for both endpoints, and the protocol
you wish to pass. (defining things like names, ip
addresses, mac addresses, etc as appropriate).
2) Create the mechanism to pass the traffic.
Confirm there is an application level gateway available
to pass what you want, if not, create a GSP (Generic
Service Passer) for it. The GSP will refer to the
protocol you may have defined in step one. Create a
service redirect where necessary[a]
3) Create a rule to allow the traffic to pass.
'Allow Entitiy-A to contact Entity-B using protocol x'
To deal with your specific question:
Lets say, for example, you want to offer non-transparent
access to two external pop3 servers from inside your
network. The two pop3 servers are 1.1.1.1 and 2.2.2.2. They
both listen on port 110/tcp.
We will allow internal users to both servers by connecting
to the internal interface of our firewall, IP 192.168.1.1
Connecting to 192.168.1.1 port 110 should get us to server
1.1.1.1, 192.168.1.1 port 111 should go to server 2.2.2.2.
These are the steps:
1) Name everything: Create entities as follows:
host pop_server_a 1.1.1.1
host pop_server_b 2.2.2.2
protocol pop3 110/tcp [b]
protocol pop3_extra 111/tcp
network internal_net 192.168.1.0/255.255.255.0
2) Create two GSPs (generic service passers, plug proxies)
gsp_pop3[c] protocol = pop3
gsp_pop3_extra protocol = pop3_extra
Create two service redirects:
connections to 192.168.1.1 port 110/tcp --> 1.1.1.1 port 110/tcp
connections to 192.168.1.1 port 111/tcp --> 2.2.2.2 port 110/tcp
3) Create rules [d]
Allow internal_net to contact pop_server_a using gsp_pop3 [e]
Allow internal_net to contact pop_server_b using gsp_pop3_extra
Save and reload, and you're away. Test by telnetting to
192.168.1.1 110, and 192.168.1.1 111.
The second way to do this in the Raptor is similar, but slightly
different. In the course of setting up the GSPs, there is an
option called "pass traffic sent directly to server to:" (words
to that effect) and you may specify the destination servers
(1.1.1.1 and 2.2.2.2) in there. The way I've detailed above is
the more common approach, and more flexible when you need to
expand later...
[a] The Raptor acts as a 'transparent' device by default.
ie: clients talk _through_ the Raptor, not _to_ it.
In a situation where you want a client to talk _to_ the
Raptor and have the traffic redirected, you specify the
redirection specifically.
[b] I am simplifying here. The protocol specification allows
for source and destination ports. In most cases where tcp
is used, your source range is 1024-65536/tcp
[c] The names can be anything you like. I try to teach
nameing that is meaningfull, so you can look at it
and know what it is immediately. Keep it simple keeps
it secure.
[d] You could create an entity-group called
'external_pop3_servers', put the two pop serves in it,
then make one rule allowing the two out. Permutations
and combinations abound.
[e] You have lots more options for timeframes, notification,
etc, etc...
For the record, yet another approch (perhaps with pop clients
that aren't port-flexible) is to set up redirects thus:
connections to 192.168.1.1 port 110/tcp --> 1.1.1.1 port 110/tcp
connections to 192.168.1.2 port 110/tcp --> 2.2.2.2 port 110/tcp
The firewall will start answering ARP requests for 192.168.1.2
as well, and redirect traffic as appropriate.
Hope this helps,
Geoff
--
CREDIT | FIRST Geoff Breach, [EMAIL PROTECTED], +61293944040
SUISSE | BOSTON Global Network Services - Asia Pacific Engineering
Opinions expressed herein are mine, not my employer's
This message is for the named person's use only. It may contain confidential,
proprietary or legally privileged information. No confidentiality or privilege is
waived or lost by any mistransmission. If you receive this message in error, please
immediately delete it and all copies of it from your system, destroy any hard copies
of it and notify the sender. You must not, directly or indirectly, use, disclose,
distribute, print, or copy any part of this message if you are not the intended
recipient. CREDIT SUISSE GROUP, CREDIT SUISSE FIRST BOSTON, and each of their
subsidiaries each reserve the right to monitor all e-mail communications through its
networks. Any views expressed in this message are those of the individual sender,
except where the message states otherwise and the sender is authorised to state them
to be the views of any such entity.
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
