This section contains "cookbook" style instructions for the following tasks:
Telnet proxy service with and without proxy user authentication
FTP proxy service with and without proxy user authentication
HTTP proxy service
SMTP proxy service
Configuring RADIUS Authentication
Telnet and FTP proxy service with RADIUS user authentication
SecurID clients supported by SunScreen
Telnet and FTP proxy service with SecurID user authentication
Port-by-port using mixed mode with proxies
The following information is used in this example:
Proxy User name: pu3
Authorized User name: none
Authorized User password: none
Backend user name: BkEndUsrName
Backend FTP server name: BackendServer
SunScreenProxy server name: qa22-efs-hem1
Client machine name: tiny
Type the following to make sure the backend FTP Server is accessible:
ping -s BackendServer |
Add an entry in the /etc/hosts file, if it is accessible.For example:
1.2.3.4 BackendServer |
Create a new Service for the FTP proxy service:
Log in to the administration GUI.
On the Policies List page, select the policy and click the Edit... button.
The Policy Rules page appears.
In the Common Objects section, select Service from the Type choice list.
Click New Single... from the Add New choice list.
The Service dialog window appears.
Type the name for this new service in the Name field, for example:
proxy-ftp |
Click the Add Filter button and select ftp.
Click the field under Port, and type 21.
Click the OK button.
There is no need to create an Authorized User.
Create the Proxy User:
In the Common Objects section, select Proxy User from the Type choice list.
Select New Single... from the Add New choice list.
The Proxy User dialog window appears.
Type a name for this Proxy User in the Name field, for example:
pu3 |
Click the User Enabled check-box.
Leave the Authorized User Name field empty.
Type a name in the Backend User Name field, for example:
BkEndUsrName |
Click the OK button.
Create a Policy Rule:
Save the changes:
From the Client Machine:
Make sure the physical connections are good.
Make sure the client machine can access SunScreen Proxy Server:
ping -s qa22-efs-hme1 |
Test the FTP proxy service:
Command issued: ftp qa22-efs-hme1
Username: pu3@BackendServer
Password: put_anything@BkEndUsrName"s password OR: <none>@BkEndUsrName"s password For example, zzz@cherrycoke (Password is not seen because it is echo suppressed.)
tiny# ftp qa22-efs-hme1 Connected to qa22-efs-hme1. 220- Proxy: SunScreen FTP Proxy Version 3.0 : Username to be given as <proxy-user>'@'<FTP-server-host> : Password to be given as <proxy-password>'@'<FTP-server-password> 220 Ready. Name (qa22-efs-hme1:root): pu3@BackendServer 331- Proxy: Authenticate & connect: 331 Password needed to authenticate 'pu3'. Password: <zzz@cherrycoke> OR Password: <@cherrycoke> 230- Proxy: : Authentication mapped 'pu3' to backend user 'BkEndUsrName'. : Connecting to BackendServer (1.2.3.4) - done. Server: 220 BackendServer FTP server (SunOS 5.6) ready. Proxy: Login on server as 'BkEndUsrName'. Server: 331 Password required for BkEndUsrName. Proxy: Supplying password to server. 230 Server: User BkEndUsrName logged in. ftp> ls |
The following information is used in this example:
Proxy User name: pu1
Authorized User name: au1
Authorized User password: hello
Backend user name: BkEndUsrName
Backend FTP server name: BackendServer
SunScreen Proxy server name: qa22-efs-hem1
Client machine name: tiny
Type the following to make sure the backend FTP Server is accessible:
ping -s BackendServer |
Add an entry in the /etc/hosts file, if it is accessible. For example:
1.2.3.4 BackendServer |
Create a new Service for the FTP proxy service:
Log in to the administration GUI.
On the Policies List page, select the policy and click the Edit... button.
The Policy Rules page appears.
In the Common Objects section, select Service from the Type choice list.
Click New Single... from the Add New choice list.
The Service dialog window appears.
Type the name for this new service in the Name field, for example:
proxy_ftp |
Click the Add Filter button and select ftp.
Click the field under Port, and type 21.
Click the OK button.
Create the Authorized User:
In the Common Objects section, select Authorized User from the Type choice list.
Select New... from the Add New choice list.
The Authorized User dialog window appears.
Type a name for this Authorized User in the Name field, for example:
au1 |
Click the User Enabled check-box.
Type the password:
hello |
Click the Enabled check-box after Password: field.
Retype the password:
hello |
Click the OK button.
Create a Proxy User:
In the Common Objects section, select Proxy User from the Type choice list.
Select New... from the Add New choice list.
The Proxy User dialog window appears.
Type a name for this Proxy User in the Name field, for example:
pu1 |
Click the User Enabled check-box.
Type the following in the Authorized User Name field:
au1 |
Type a name in the Backend User Name field, for example:
BkEndUsrName |
Click the OK button.
Create a Policy Rule:
Click the OK button.
Save the changes:
Test the FTP Proxy Service
From the Client Machine:
Make sure the physical connections are good.
Make sure the client machine can access SunScreen Proxy Server:
ping -s qa22-efs-hme1 |
Test the FTP proxy service:
Command issued: ftp qa22-efs-hme1
Username: pu1@BackendServer
Password: For example, zzz@cherrycoke (Password is not seen because it is echo suppressed.)
tiny# telnet qa22-efs-hme1 Trying 70.70.70.1... Connected to qa22-efs-hme1. Escape character is "^]". SunScreen Telnet Proxy Version 3.0 Username@Hostname: pu1@BackendServer Password: <enter au1"s password> Trying BackendServer (1.2.3.4) ... Connected to BackendServer SunOS 5.6 login: BkEndUsrName Password: |
The following information is used in this example:
Proxy User name: pu3
Authorized User name: none
Authorized User password: none
Backend user name: BkEndUsrName
Backend Telnetnserver name: BackendServer
SunScreen for Solaris Version 3.1 Proxy server name: qa22-efs-hem1
Client machine name: tiny
Type the following to make sure the backend Telnet Server is accessible:
ping -s BackendServer |
Add an entry in the /etc/hosts file, if it is accessible.For example:
1.2.3.4 BackendServer |
Create a new Service for the Telnet proxy service:
Log in to the administration GUI.
On the Policies List page, select the policy and click the Edit... button.
The Policy Rules page appears.
In the Common Objects section, select Service from the Type choice list.
Click New Single... from the Add New choice list.
The Service dialog window appears.
Type the name for this new service in the Name field, for example:
proxy_telnet |
Click the Add Filter button and select tcp.
Click the field under Port, and type 23.
Click the OK button.
There is no need to create an Authorized User.
Create the Proxy User:
In the Common Objects section, select Proxy User from the Type choice list.
Select New Single... from the Add New choice list.
The Proxy User dialog window appears.
Type a name for this Proxy User in the Name field, for example:
pu3 |
Click the User Enabled check-box.
Leave the Authorized User Name field empty.
Type a name in the Backend User Name field, for example:
BkEndUsrName |
Click the OK button.
Create a Policy Rule:
Click the Add New... button in the Policy Rules area of the Policy Rules page.
The Rule Definition dialog window appears.
Edit each field as follows by clicking the down arrow to display the choice list.
Service: proxy_TELNET
Source Address: *
Destination Address: *
Action: ALLOW
PROXY list: PROXY_TELNET.
Save the changes:
Test the Telnet Proxy Service
From the Client Machine:
Make sure the physical connections are good.
Make sure the client machine can access SunScreen Proxy Server:
ping -s qa22-efs-hme1 |
Test the Telnet proxy service:
Command issued: telnet qa22-efs-hme1
Username@Hostname: pu3@BackendServer
Password: Press the Return key
tiny# telnet qa22-efs-hme1 Trying 70.70.70.1... Connected to qa22-efs-hme1. Escape character is "^]". SunScreen Telnet Proxy Version 3.0 Username@Hostname: pu3@BackendServer Password: <press return> Trying BackendServer (1.2.3.4) ... Connected to BackendServer SunOS 5.6 login: BkEndUsrName Password: |
The following information is used in this example:
Proxy User name: pu1
Authorized User name: au1
Authorized User password: hello
Backend user name: BkEndUsrName
Backend Telnet server name: BackendServer
SunScreen for Solaris Version 3.1 Proxy server name: qa22-efs-hem1
Client machine name: tiny
Type the following to make sure the backend Telnet Server is accessible:
ping -s BackendServer |
Add an entry in the /etc/hosts file, if it is accessible. For example:
1.2.3.4 BackendServer |
Create a new Service for the Telnet proxy service:
Log in to the administration GUI.
On the Policies List page, select the policy and click the Edit... button.
The Policy Rules page appears.
In the Common Objects section, select Service from the Type choice list.
Click New Single... from the Add New choice list.
The Service dialog window appears.
Type the name for this new service in the Name field, for example:
proxy_telnet |
Click the Add Filter button and select tcp.
Click the field under Port, and type 23.
Click the OK button.
Create an Authorized User:
In the Common Objects section, select Authorized User from the Type choice list.
Select New... from the Add New choice list.
The Authorized User dialog window appears.
Type a name for this Authorized User in the Name field, for example:
au1 |
Click the User Enabled check-box.
Type the password:
hello |
Click the Enabled check-box after Password: field.
Retype the password:
hello |
Click the OK button.
Create the Proxy User:
In the Common Objects section, select Proxy User from the Type choice list.
Select New... from the Add New choice list.
The Proxy User dialog window appears.
Type a name for this Proxy User in the Name field, for example:
pu1 |
Click the User Enabled check-box.
Type the following in the Authorized User Name field:
au1 |
Type a name in the Backend User Name field, for example:
BkEndUsrName |
Click the OK button.
Create a Policy Rule:
Click the Add New... button in the Policy Rules area of the Policy Rules page.
The Rule Definition dialog window appears.
Edit each field as follows by clicking the down arrow to display the choice list.
Service: proxy_telnet
Source Address: *
Destination Address: *
Action: ALLOW
PROXY list: PROXY_TELNET.
Click the OK button.
Save the changes:
Test the Telnet Proxy Service
From the Client Machine:
Make sure the physical connections are good.
Make sure the client machine can access the SunScreen Proxy Server:
ping -s qa22-efs-hme1 |
Test the Telnet proxy service:
Command issued: telnet qa22-efs-hme1
Username: pu1@BackendServer
Password: au1"s password For example, hello. (Password is not seen because it is echo suppressed.)
tiny# telnet qa22-efs-hme1 Trying 70.70.70.1... Connected to qa22-efs-hme1. Escape character is "^]". SunScreen Telnet Proxy Version 3.0 Username@Hostname: pu1@BackendServer Password: <enter au1"s password> Trying BackendServer (1.2.3.4) ... Connected to BackendServer SunOS 5.6 login: BkEndUsrName Password: |
User authentication does not apply.
The following information is used in this example:
Backend HTTP Server name: gobaby
Backend HTTP Server URL: gobaby/Sun.Net
SunScreen Proxy server name: qa22-efs-hem1
Client machine name: tiny
Disable the HTTP daemon (for example, httpd), if it is running.
Type the following to make sure the backend HTTP Server is accessible:
ping -s BackendServer |
Add an entry in the /etc/hosts file, if it is accessible. For example:
1.2.3.4 BackendServer |
Create a new Service for the HTTP proxy service:
Log in to the administration GUI.
On the Policies List page, select the policy and click the Edit... button.
The Policy Rules page appears.
In the Common Objects section, select Service from the Type choice list.
Click New Single... from the Add New choice list.
The Service dialog window appears.
Type the name for this new service in the Name field, for example:
proxy_http |
Click the Add Filter button and select tcp.
Click the field under Port, and type 80.
Click the OK button.
User authentication does not apply.
Create the Proxy User:
In the Common Objects section, select Proxy User from the Type choice list.
Select New... from the Add New choice list.
The Proxy User dialog window appears.
Type a name for this Proxy User in the Name field, for example:
pu1 |
Leave the Authorized User Name field blank.
Leave the Backend User Name blank.
Click the OK button.
Create a Policy Rule:
Click the Add New... button in the Policy Rules area of the Policy Rules page.
The Rule Definition dialog window appears.
Edit each field as follows by clicking the down arrow to display the choice list.
Service: proxy_http
Source Address: *
Destination Address: *
Action: ALLOW
PROXY list: PROXY_HTTP
Cookies, ActiveX, Java, and SSL: ALLOW/DENY
Click the OK button.
Save the changes:
Test the HTTP Proxy service
From the Client Machine:
The screen output appears on the web page.
User authentication does not apply.
Configure addresses and rules for DNS servers and address(es) for SMTP server(s) as follows:
ssadm edit Initial edit> add Address dns0 HOST 1.2.3.4 edit> add Address dns1 HOST 1.2.3.5 edit> add Address dns-servers GROUP { dns0 dns1 } { } edit> add Address smtp-server HOST ... edit> add Rule dns localhost dns-servers ALLOW |
Test Spam filtering:
edit> add Rule smtp "*" smtp-server ALLOW PROXY_SMTP RELAY (To allow any address to all inbound mailboxes, no relay checking.) edit> save |
Type the following to create a basic mail spam list (list of domains and/or addresses which won"t be allowed to send mail):
ssadm edit Initial mail_spam add spam.com ssadm edit Initial mail_spam add 0.0.0.0..255.255.255.255 |
Type the following to activate the configuration:
ssadm activate Initial |
This refuses mail from any named host in spam.com, any host which has an unregistered address, and any originator name (in MAIL FROM: command) within spam.com.)
Connection from an unregistered host, or from a registered host under the domain spam.com:
% telnet efs 25 Trying 1.2.3.4... Connected to efs Escape character is "^]". 455 Smells like ... bacon ... no, spam! Connection closed by foreign host. |
The reverse-translated name (or lack thereof) has determined the originator is a spammer.
Connection from a registered host not under the domain spam.com:
% telnet efs 25 Trying 1.2.3.4... Connected to efs Escape character is "^]". 220 efs ESMTP Sendmail 8.7.4/8.7.3; Thu, 11 Mar 1999 19:34:40 -0800 (PST) helo me.com 250 efs Hello me.com [3.4.5.6], pleased to meet you mail from: elvis-lives@spam.com 455 Smells like ... bacon ... no, spam! Connection closed by foreign host. |
Connection aborted because originating user was determined to be a spammer. An alternate syntax for the mailbox is: elvis-lives@spam.com.
Test relay blocking:
Type the following to replace the previous rule with a rule that checks relaying:
edit> add Rule smtp "*" smtp-server ALLOW PROXY_SMTP |
This allows only configured domains in inbound mailbox names.
Type the following to create a basic mail relay list (a list of domains and/or hosts which will/will not be allowed as recipient):
ssadm edit Initial mail_relay add good.org ssadm edit Initial mail_relay add !too.good.org ssadm edit Initial mail_relay add !too-mailer ssadm edit Initial mail_relay add plenty.org |
The ! prefix indicates that the domain or host is not to be allowed; if you are using csh, remember to escape the !, as it is a shell meta-character.
Relay processing first compares the recipient domain(s) to those which are NOTs (that is, begin with !); if the recipient is found there, the message is refused.
Second, the recipient domain(s) are compared to the list of OK domains (that is, without " !); if found, the recipient is allowed.
Activate the configuration.
This refuses mail to any mailbox in the subdomain too.good.org or for the host too-mailer, but accepts messages bound for any mailbox in other parts of good.org, or any mailbox in plenty.org (from RCPT TO: command).
Mail for allowed recipients, ending in one which will not be relayed-to:
% telnet efs 25 Trying 1.2.3.4... Connected to efs Escape character is "^]". 220 efs ESMTP Sendmail 8.7.4/8.7.3; Thu, 11 Mar 1999 19:34:40 -0800 (PST) helo me.com 250 efs Hello me.com [3.4.5.6], pleased to meet you mail from: me@me.com 250 me@me.com... Sender ok rcpt to: <johnny.b@good.org> 250 Recipient ok rcpt to: extra@extra@good.org 250 Recipient ok rcpt to: <chinz@plenty.org> 250 Recipient ok rcpt to: but.not@too.good.org 454 Relay refused Connection closed by foreign host. |
Connection aborted because the recipient would require a forbidden relay operation.
Other examples of relay addresses which will not be allowed are:
bad1@too-mailer
bad2@too-mailer@good.org
bad3@too.good.org@good.org
@good.org,bad4@too.good.org
@too.good.org,bad5@ok.good.org
Note that the last two bullet items are examples of older, ARPANET-style path naming, and most modern sendmails are not configured to accept them, regardless of whether or not they pass our relay filtering.
Also note that mailbox names surrounded by <> are treated as if they there are no <>s.
Test default relay:
If there is no configured relay list, the domain name of the SunScreen host itself is used as the allowed domain. For example, if the SunScreen name is host@domain.com, the relay checking behaves as if the following command was configured as the entire relay list:
ssadm edit Initial mail_relay domain.com |
Mail which actually get through:
% telnet efs 25 Trying 1.2.3.4... Connected to efs Escape character is "^]". 220 efs ESMTP Sendmail 8.7.4/8.7.3; Thu, 11 Mar 1999 19:34:40 -0800 (PST) helo me.com 250 efs Hello me.com [3.4.5.6], pleased to meet you mail from: me@me.com 250 me@me.com... Sender ok rcpt to: you@good.com 250 Recipient ok rcpt to: really@really.good.org 250 Recipient ok rcpt to: i-got@plenty.org 250 Recipient okrcpt to: good@and.plenty.org 250 Recipient ok data 354 Enter mail, end with "." on a line by itself Subject: I Love Candy I really, really love good candy ... yummm! Send me some!. 250 UAA01234 Message accepted for delivery quit 221 efs closing connection Connection closed by foreign host. |
After the . (ending the mail session), the proxy (and mailer) returns to the state where it expects a next message (starting with a MAIL FROM: command.
Backslash \ and end of line denote command line continuation.
Identify the RADIUS servers:
# ssadm edit <Policy>> vars add prg=auth name=RADIUSServers \VALUES={ host=radius_server_name } \ DESCRIPTION="RADIUS server name(s) or addresses to query" |
Add the node secret used by RADIUS protocol to secure traffic between the RADIUS client and server:
# ssadm edit <Policy>> vars add sys=screen_name prg=auth name=RADIUSNodeSecret VALUE="xxxxxxxx |
Where xxxxxxxx is the RADIUS Node Secret.
Add a Rule to allow the SunScreen machine to communicate with the RADIUS servers:
# ssadm edit <Policy>edit > add rule radius EFS_hostname radius_server_name ALLOW edit > save # ssadm activate <Policy> |
Follow the steps in the previous section, "Configuring RADIUS Authentication for SunScreen."
Add a rule to allow the Telnet Proxy for a pre-defined RADIUS user:
# ssadm edit <Policy>edit > Add Rule telnet USER radius ALLOW PROXY_Telnet edit > save # ssadm activate <Policy> |
Test the Telnet Proxy with RADIUS authentication:
# telnet EFS_Screen_nameUsername @Hostname : /radius/ radius_user@server Password: radius_user_pw |
The following information is used in this example:
Proxy User name: pu1 (May be same as user1)
Authorized User name: au1
Authorized User password: au1_pw
Backend user name: BkEndUsrName (May be same as user1)
Backend FTP Server name: BackendServer
SunScreen for Solaris Version 3.1 Proxy server name: EFS_hostname
Client machine name: tiny
Although the example uses different names for Proxy User name, Authorized User name, and Backend User name, they may all use the same name, which will simplify administration.
To simplify administration, the Proxy User name and the Authorized User name may use the same name as the Backend User name.
Proxy User name: user1
Authorized User name: May be same as user1
Authorized User password: user1_auth_pw
Backend user name: May be same as user1
Backend FTP Server name: BackendServer
SunScreen for Solaris Version 3.1 Proxy server name: EFS_hostname
Client machine name: tiny
Follow the steps in the section above, "Configuring RADIUS Authentication for SunScreen."
Configure the FTP Proxy Service:
Create a Proxy user group, for example, ftp-grp.
Add pre-defined users radius and securid to ftp-grp.
# ssadm edit <Policy>> proxyuser add ftp-grp GROUP> proxyuser addmember ftp-grp radius > proxyuser addmember ftp-grp securid |
For each user that will be using the FTP Proxy:
Create a record in the Authorized User database.
Create a record in the Proxy User database.
Add the user as member of ftp-grp:
# ssadm edit <Policy>> authuser add au11 PASSWORD=\{ au1_pw \}> proxyuser add pu1 auth_user_name=au1 \ backend_user_name=BkEndUsrName > proxyuser addmember ftp-grp pu1 |
This example assumes C shell, the back slash, \ before the brackets is the escape key from special characters { and }. For Bourne shell, the backslash is not necessary.
Since there are typically many users to administer, this can be done through a script.
Add a rule to allow the FTP proxy for the proxy user group, ftp-grp.
# ssadm edit <Policy>edit > Add Rule ftp USER ftp-grp ALLOW PROXY_FTP \FTP_GET FTP_CHDIR edit > save # ssadm activate <Policy> |
Test the FTP Proxy with RADIUS authentication:
# ftp EFS_Screen_nameUsername @Hostname: radius_user@ftp_server Password: radius_user_pw@password_at_ftp_server |
SunScreen supports two mechanisms for SecurID clients:
Install ACE/Agent 3.3 on each user desktop. ACE/Agent 3.3 is supported only on the Solaris 2.6 SPARC platform.
Or:
Install the SunScreen SecurID stub client on the SunScreen machine, which supports Solaris 2.6. Solaris 7 and Solaris 8 on both SPARC and x86.
As root, install a copy of sdconf.rec from the ACE server after it has been configured to have SunScreen as the ACE client.
Type the following in the directory containing sdconf.rec:
# /opt/SUNWicg/SunScreen/lib/securid_stubclient_setup sdconf.rec |
Differences between the two mechanisms for SecurID clients:
The ACE/Agent 3.3 is supported only on Solaris 2.6 SPARC platform.
It will replace the system login module by an ACE login module. By installing it on each user desktop, ACE accounting will show that the user is authenticated through the user's desktop.
The EFS SecurID stub client supports Solaris 2.6, 2.7, on both SPARC and Intel platforms.
It needs to be installed only on the SunScreen EFS firewall. ACE accounting will show that the users are authenticated through the EFS machine.
Follow ACE documentation to set up ACE server and configure Securid users.
Install either ACE/Agent 3.3 on each user desktop or SunScreen SecurID stub client on EFS machine.
Add a rule to allow the SunScreen machine to communicate with the ACE servers:
# ssadm edit <Policy>edit > Add Rule securid EFS_hostname secureid_server_name ALLOW edit > save # ssadm activate <Policy> |
Follow the steps in the section above, "Configuring SecurID Authentication for SunScreen."
Add Rule to allow telnet proxy for pre-defined 'securid' user
# ssadm edit <Policy>edit > Add Rule telnet USER radius ALLOW PROXY_Telnet edit > save # ssadm activate <Policy> |
Test the Telnet Proxy with SecurID Authentication:
# telnet EFS_Screen_nameUsername @Hostname : /securid/securid_user@server Password: securid_passcode |
The following information is used in this example:
Proxy User name: pu1 (May be same as user1)
Authorized User name: au1
Authorized User password: au1_pw
Backend user name: BkEndUsrName (May be same as user1)
Backend FTP Server name: BackendServer
SunScreen for Solaris Version 3.1 Proxy server name: EFS_hostname
Client machine name: tiny
Although the example uses different names for Proxy User name, Authorized User name, and Backend User name, they may all use the same name, which will simplify administration.
Proxy User name: user1
Authorized User name: user1
Authorized User password: user1_auth_pw
Backend user name: user1
Backend FTP Server name: BackendServer
SunScreen for Solaris Version 3.1 Proxy server name: EFS_hostname
Client machine name: tiny
Follow the steps in the section above, "Configuring RADIUS Authentication for SunScreen."
Configure the FTP Proxy Service
Create a Proxy user group, for example, ftp-grp.
Add pre-defined users radius and securid toftp-grp:
# ssadm edit <Policy>> proxyuser add ftp-grp GROUP> proxyuser addmember ftp-grp radius > proxyuser addmember ftp-grp securid |
For each user that will be using the FTP Proxy:
Create a record in the Authorized User database.
Create a record in the Proxy User database.
Add user as member of ftp-grp:
# ssadm edit <Policy>> authuser add au1 PASSWORD=\{ au1_pw\}> proxyuser add pu1 auth_user_name=au1 backend_user_name=BkEndUsrName > proxyuser addmember ftp-grp pu1 |
Since there are typically many users to administer, this can be done through a script.
Add a rule to allow FTP proxy for proxy user group ftp-grp:
# ssadm edit <Policy>edit > Add Rule ftp USER ftp-grp ALLOW PROXY_FTP \ FTP_GET FTP_CHDIRedit > save # ssadm activate <Policy> |
Test the FTP Proxy with SecurID Authentication:
# ftp EFS_Screen_name Username @Hostname: /securid/securid_user@server Password: securid_passcode@BkEndUsrName_password |
This example covers a Port by Port scenario using Mixed Mode With Proxies).
Network 1 Topology is designed so that Routing networks communicate with Routing networks, and Stealth networks communicate with Stealth networks (that is, host A [Stealth] cannot talk to host B [Router]).
NAT works in Stealth networks only, since Routing networks are not able to NAT through a Stealth network (that is, not able to NAT host A to talk to host B).
Proxies cannot be used from the Stealth networks to the Stealth networks.
Routing network to Routing network (EFS_qfe0 -> EFS_qfe1)
Telnet or ftp from A to Server2 through the EFS Proxy Server:
telnet 172.32.16.1
ftp 172.32.16.1)
Routing network to Routing network:
EFS_qfe0 -> EFS_qfe1
Telnet or ftp from A to Server2 directly:
telnet 192.9.61.84
ftp 192.9.61.84)
Stealth network to Stealth network:
SPF_hme0 -> EFS_qfe2)
Telnet or ftp from B to Server2 directly:
telnet 192.9.61.84
ftp 192.9.61.84)
Routing network to Routing network:
EFS_qfe0 -> EFS_qfe1
Surfing the Web Server (Server1) from A through the Routing Proxy Server:
Set up browser to use proxy server172.32.16.1 on A.
Routing network to Routing network:
EFS_qfe0 -> EFS_qfe1)
Surfing the Web Server (Server1) directly from A:
Do not set up browser to use proxy on A.
Stealth network to Stealth network:
SPF_hme0 -> EFS_qfe2)
Surfing the Web Server (Server1) directly from B:
Do not set up browser to use proxy on B.
Stealth network to Stealth network:
SPF_hme0 -> EFS_qfe2
Set up Static and Dynamic NAT rules to hide Web Server and FTP/Telnet Server addresses.
NAT works only in Stealth networks, since Routing networks are not able to NAT through a Stealth network (that is, not able to NAT host A to talk to host B).
Cannot telnet or ftp directly from A (Routing network) to B (Stealth network) or B to A without using a Proxy.
Routing network to Stealth network:
EFS_qfe0 -> EFS_qfe 1-> SPF_qfe2 -> SPF_hme0
Telnet or ftp from A to B through the Routing Proxy Server:
telnet172.32.16.1
ftp 172.32.16.1)
Routing network to Routing network:
EFS_qfe0 -> EFS_qfe1
Telnet/ftp from A to Server2 through the Routing Proxy Server:
telnet172.32.16.1
ftp 172.32.16.1)
Stealth network to Routing network:
SPF_hme0 -> SPF_qfe2 -> EFS_qfe1 -> EFS_qfe0
Telnet or ftp from B to A through the Routing Proxy Server:
telnet 207.88.218.2
ftp 207.88.218.2)
Stealth network to Stealth network:
SPF_hme0 -> SPF_qfe2
Telnet or ftp from B to Server2 through the Routing Proxy Server:
telnet 207.88.218.2
ftp 207.88.218.2
Routing network to Routing network:
EFS_qfe0 -> EFS_qfe1
Telnet or ftp from A to Server2 directly:
telnet 192.9.61.84
ftp 192.9.61.84)
Stealth network to Stealth network:
SPF_hme0 -> SPF_qfe2)
Telnet or ftp from B to Server2 directly:
telnet 192.9.61.84
ftp 192.9.61.84
Routing network to Stealth network:
EFS_qfe0 -> EFS_qfe1 -> SPF_qfe2 -> SPF_hme0
Surfing the Internet directly from A:
Set up the browser to use Proxy server 172.32.16.1 on A.
Routing network to Routing network:
EFS_qfe0 -> EFS_qfe1
Surfing the Web Server (Server1) from A through the Routing Proxy Server:
Set up browser to use proxy server 172.32.16.1 on A.
Stealth network to Stealth network:
SPF_hme0 -> SPF_qfe2
Surfing the Web Server (Server1) from B through the Routing Proxy Server:
Set up the browser to use Proxy server 207.88.218.2 on B.
Routing network to Routing network:
EFS_qfe0 -> EFS_qfe1
Surfing the Web Server (Server1) directly from A:
Do not set up browser to use Proxy on A.
Stealth network to Stealth network:
SPF_hme0 -> SPF_qfe2
Surfing the Web Server (Server1) directly from B:
Do not set up browser to use proxy on B.