Subject: Example for running WebForms through a Firewall based on Linux 2.2 and ipchains Type: BULLETIN Creation Date: 21-SEP-2000 PURPOSE ------- The idea is to provide a relatively simple and cheap test environment for running webforms through a firewall based on Linux 2.2.x and an ipchains firewall. SCOPE & APPLICATION ------------------- For everyone with basic knowledge of firewalls and network technology who is interested in running webforms through a firewall in HTTP mode. This article provides a test area, fast in setting up, simple in use but not secure and therefore not applicable for a production environment. EXAMPLE FOR RUNNING WEBFORMS THROUGH A FIREWALL BASED ON LINUX 2.2 AND IPCHAINS ------------------------------------------------------------------------------- Introduction/Basic Idea: ======================== Relatively simple and cheap test environment, Linux 2.2.x & ipchains firewall Architecture: ============= 1 or more clients ('the world') 1 firewall PC (linux) -> server side proxy 1 PC behind the firewall (intranet) hosting the webserver and forms server Hub to connect the computers -------- ---------- --------- -------- | test | ----- | test | | normal | | test | | client |----| Hub |----| firewall |------| company |----| server | | PC | ----- | | | network | | 1 | -------- ---------- --------- -------- 192.168.100.23 192.168.100.1 140.84.20.236 | \ -------- | \ | test | | \--| server | | | 2 | | -------- | company internet firewall IP Addresses for the PC's in this example: client PC: 192.168.100.23 firewall PC from 'outside': 192.168.100.1 firewall PC from 'inside': 140.84.20.236 server host: 140.84.20.165 Background: =========== To run Web Forms, two connections are needed: A normal HTTP connection to download the HTML and JAR files and the Forms Runtime connection, which can either operate in Socket or in HTTP 1.1 mode. We don't have to look very much at the standard HTTP connection, which is used for downloading only, because this is a "well-known" matter in setting up firewalls. However, we do have to look at the Forms Runtime connection, because this kind of traffic is still somewhat unknown to firewalls. Our test firewall is thought to enable us to find out details about firewall configurations that can be used for the Forms Runtime connection. As we use a Linux PC and a private network, this type of test firewall can be set up everywhere. Implementation of ipchains firewall, masquerading IP addresses: =============================================================== In your test firewall PC have 2 network interface cards eth0 and eth1. Make sure that your Linux kernel is built to support Firewalling/Socket Filtering and Masquerading: Check whether the pseudo-files ip_masquerade, ip_fwchains, ip_fwnames and ip_masq/* exist in the /proc/net directory. Configure the card eth0 for your normal company network: $ ifconfig eth0 140.84.20.236 netmask ... $ route add default gw ... Configure the card eth1 for your private network: $ ifconfig eth0 192.168.100.1 netmask ... Connect one or more client computers to your private network and configure them appropriately. Enable kernel-level IP forwarding. Otherwise the Linux kernel won't forward packets between network interfaces $ echo 1 >/proc/sys/net/ipv4/ip_forward Make a basic firewall configuration: ==================================== $ ipchains -f => This command will erase all existing firewall rules. $ ipchains -P forward DENY => Sets the default forwarding policy to DENY, i.e. when an incoming IP packet must be forwarded to a different network the default policy will be not to allow this. $ ipchains -A forward -s 192.168.100.0/24 -d 192.168.100.0/24 -j ACCEPT => To allow traffic from the "outside" network to be sent to the "outside" network again. $ ipchains -A forward -s 140.84.20.0/255.255.252.0 -d 0/0 -j ACCEPT => To allow traffic from the "inside" network to everywhere (so you can use your firewall machine as a normal host in your normal company network). $ ipchains -A forward -p udp -s 192.168.100.0/24 1024: -d 0.0.0.0/0 domain -j MASQ => To allow nameserver queries from the "outside" network to everywhere. Because the simulated "outside" network does not have any name resolution mechanisms, we simply allow our test clients to use the company network's DNS servers - of course you can set the -d option to something more restrictive, like your DNS server's IP address. => The string "domain" is found in /etc/services and specifies the port to which nameserver queries are going. => -j MASQ means that the IP packets will not only be allowed to be forwarded, but masqueraded, i.e. rewritten to look as if they came from the firewall. This is neccesary because your normal company network does not know how to route 192.168.100.x IP addresses. (192.168.x.x addresses are officially specified to be for "private" purposes.) Configuration, sample script: ============================= Now start testing by defining firewall rules that allow traffic to certain servers on certain ports, e.g. $ ipchains -A forward -p tcp -s 192.168.100.0/24 1024: -d 140.84.23.134/32 www -j MASQ $ ipchains -A forward -p tcp -s 192.168.100.0/24 1024: -d 140.84.23.134/32 9000 -j MASQ to allow connections to host 140.84.23.134 on ports 80 and 9000. => Again, connections must be masqueraded to be sent to your "official" company network. You can view your firewall rules with the following command: $ ipchains -n -L To display all options of the rules use $ ipchains -n -v -L To try to convert IP adresses to names in all rules use $ ipchains -L or $ ipchains -v -L but this will generate DNS queries and will therefore only work if your nameserver can be reached from the firewall host. !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! The firewall configuration described here is not intended to be secure, because direct connections to and from the firewall are allowed on any ports from both networks. Furthermore, a really secure firewall would need checking for network interfaces, through which IP packets are coming in, and would not only rely on the source IP addresses. Several other details like logging of denied requests, etc. are missing in our test firewall, too. !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! When testing forms with your firewall allow and deny network connections successively, i.e. when just running with the "basic firewall configuration", your client PC will not even be able to retrieve a form's HTML page. When you then allow connections to the webserver port on your webserver machine (or proxy port on your proxy machine, depending on the configuration of your client's web browser), the HTML and JAR files will be loaded, but the Forms Applet won't be able to connect to the Forms Server (FRM-99999 or FRM-92050). When you then allow connections to the Forms Server's port (usually 9000) - you have to restart the client browser at this point - the form will start up fine. This firewall configuration (allowing connections to the Forms Server port) will also work for Web Forms (>6.0+Patch???) in Socket mode, which is Forms' default mode. Configuration of the forms server (HTTP mode): ============================================== You need a Forms Server installation and any webserver (e.g. the Oracle WebDB listener which is included on the Forms/Reports 6i Production CD). For installation hints see Note 109399.1. Ensure that the webserver listener is running and virtual directories are set correct (also see Note 109399.1). The forms server process needs to be started in HTTP mode. Either start from command line or install as service using the parameter 'mode=HTTP'. Examples: ifsrv60 [-listen [port=nnn] [mode=socket|http|https]] [-install servicename [port=nnn] [mode=socket|http|https]] [-uninstall servicename] example 1, remove the NT service: >ifsrv60 -uninstall Forns60Server example 2, start the server up on NT from the command line on port 9999 in HTTP mode: >ifsrv60 -listen port=9999 mode=HTTP example 3, install as service on port 9999 in HTTP mode: >ifsrv60 -install Forms60Server port=9999 mode=HTTP example 4, start the server up on Unix on port 9999 in HTTP mode: $ f60ctl start port=9999 mode=HTTP Then change your form's HTML page to include the connectMode parameter: For JInitiator in Internet Explorer have this line after the opening tag: For JInititator in Netscape have this option in the tag: For AppletViewer or Internet Explorer 5 without JInitiator have this line after the opening tag: Now you can run a webforms application from a Netscape or IE browser on the client PC. JInitiator is required as a plugin for the browser to provide the Java runtime environment. An exception is the use of MS Internet Explorer 5.0 with Developer 6.0 (see the 'Client Platform Support Statement of Direction' white paper on Oracle Technology Network for more details). If you activate the Java console (Start-> Oracle JInitiator Control Panel 1.1.7.x-> Show Java Console) you can see in the log: connectMode=HTTP. Firewalls in the internet: ========================== In the 'real world' usually the client has to penetrate several firewalls to communicate with the forms server. If the connect mode is 'socket' then in all involved firewalls the forms server port would have to be opened. -------- --- --- --- --- -------- | client | | | | | | | | | | forms | | PC |----|fw1|--|fw2|----Internet----|fw3|--|fw4|----| server | | | | | | | | | | | | | -------- --- --- --- --- -------- Using HTTP proxies avoids this problem. HTTP proxies that are used for the Web Forms transport layer must be fully HTTP 1.1 compliant. When connecting to the Forms Server, the Forms Applet uses the proxy which is configured in JInitiator. You can change these settings on the 'Proxies' tab in the JInitiator Control Panel (see above). (Note that the parameters proxyHost and proxyPort in the HTML file to start the web application, are obsolete. They were used for the beta version of the HTTP connect mode only.) These settings, however, just configure the client proxy to be used to connect to the "internet". On the server side you will either have to allow connections through the firewall(s) to the Form Server's port, or you can use an HTTP 1.1 compliant transparent reverse application proxy. To test forms through an HTTP proxy go on as before. Have a proxy at hand and allow connections to the proxy through the firewall. Configure JInitiator on the client PC to use that proxy. => When loading JAR files JInitiator will now no longer display "no proxy" but tell the proxy that is used to load the JAR file. Access the form. Shut down the proxy or deny connections through the firewall, and try to access the form again. Notice: Using HTTP proxies with Web Forms is a bit tricky, because some proxies that are advertised as being HTTP 1.1 compliant do not seem to work with Web Forms. This may on the one hand be due to proxy configuration errors, but it's also possible that the proxy cannot cope with Web Forms' persistent HTTP 1.1 connections. Bottom line: If you want to use Web Forms with HTTP proxies do many tests with many different proxies to check whether Web Forms can work with all of them. RELATED DOCUMENTS ----------------- Note:62528.1 Using Connection Manager as a MultiProtocol Interchange Note:68652.1 Solving Firewall problems on NT Note:66382.1 How Firewalls Work in Relation to a Windows NT Server Note:45226.1 SQL*Net and Firewalls Note:109399.1 Installing and deploying Forms/Reports 6i and WebDB listener on Windows NT Linux IPCHAINS-HOWTO - http://www.linuxdoc.org/HOWTO/IPCHAINS-HOWTO.html Linux Firewall-HOWTO - http://www.linuxdoc.org/HOWTO/Firewall-HOWTO.html Linux IP Masquerade HOWTO - http://www.linuxdoc.org/HOWTO/IP-Masquerade-HOWTO.html