> For the complete documentation index, see [llms.txt](https://docs.editran.onesait.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.editran.onesait.com/documentacion-editran/ibm-editran-v5.3-iseries-en/proxy/introduction.md). # Introduction Editran/Proxy is a software utility implemented together with editran/TCP, and it serves to provide the latter with greater security and control. In the following diagram, a basic design of IP connections in AS/400 is presented, with access controlled by 2 firewalls, normally of different technology. However, in that diagram there are “two different operating situations” (both with the application running under TCP/IP): That all application data, including connections, take the “normal” route, that is, in both directions the route would be: AS400-Router-Firewall-Firewall-IP network-remote. This would be the normal situation with editran/TCP. That all application data, including connections, take the route AS400-Router-Firewall-editran Proxy-Firewall-remote IP network in both directions. This would be the situation with editran/TCP including editran/Proxy (software running on editran Proxy). editran Proxy is a Windows, UNIX, or Linux machine located in the entity’s DMZ.
In the first situation, when working without editran/Proxy, a series of inconveniences arise: * The host is not isolated from the outside world. In some way, it is “seen directly” from the endpoints. * The firewall-router must be managed constantly. When a remote entity gives us its IP address, we will normally need to enable it. When that entity changes IP, we will need to “refresh” it. The same happens with the remote ports (if they are controlled). In turn, when the internal IPs (AS400) change, those changes need to be “refreshed.” All this maintenance situation becomes more complicated with the widespread use of NAT. In the second situation, when working with editran/Proxy, the above uncertainties are resolved: * The host is isolated from the outside world. Its only possible connection and data transmission is restricted to the bidirectional exchange of data between AS400-router-firewall-editran Proxy. For those data to reach the remote entity or be received from the remote entity, a second route is enabled: Server-proxy-firewall-remote IP network. This is not a double data transmission, as will be explained later. * The maintenance and administration of the router-firewall are minimal. The endpoints are provided with the IP and listening port of editran Proxy, so that they only know that IP. This makes it possible to “enable” the entire external network so that access is granted only to the proxy. editran/Proxy will only enable a connection with the host when it is sure that an editran is communicating at the endpoint. The characteristics and elements of the product working with editran/Proxy are as follows: * Editran/Proxy is software that runs in the DMZ, specifically on editran Proxy (there is also software that runs on the AS400). It is not a second intermediate editran. It is software that acts as both a controller and a data gateway. * Editran/Proxy requires editran/TCP on the host. It is contracted separately from the latter and is ultimately a software-hardware solution that adds security to the product transmissions. In this regard, if editran/Proxy receives an external call (EDI or non-EDI remote endpoint), it must also receive some application user data in a recognized format. If it does not receive them or does not recognize them, editran/Proxy closes the socket opened from the outside, without the AS400 editran “noticing or being affected in any way.” * The characteristics of transmission with editran/Proxy are: * The AS400 host communicates via TCP/IP with editran/Proxy software, which runs on WINDOWS (NT, 2000, ...) UNIX (SOLARIS, AIX, HP) and Linux machines. * Editran/Proxy communicates with the endpoints over a connection different from the previous one, but within the same data transmission (not in a second transmission). * In outbound calls from the AS400, it provides editran/Proxy with the necessary TCP/IP information to connect to the remote endpoint (IP address and destination port). It keeps the host socket open and connects a second socket to the remote endpoint. From that moment on, it routes the data from one socket to the other. * In inbound calls to the transaction monitor, the endpoints call the IP address and port enabled in editran/Proxy (through a socket) and send user data to it. If editran/Proxy recognizes their format, it opens a second socket with the transaction monitor (AS400 IP address and port), passes it the user data and the information about the remote IP and port. From that moment on, it routes the data from one socket to the other. * If editran/Proxy detects TCP/IP errors, it provides the AS400 with the diagnostic elements (errno and retcode) to inform it. * Using editran/TCP + editran/Proxy locally, the remote endpoints can have any of the following configurations: * Editran/TCP * Editran/TCP + editran/Proxy * There can be up to 6 editran/Proxy instances in the DMZ; for this purpose, up to 6 Proxy server IP addresses will be specified in editran/P on the AS400. This makes it possible to perform backup in case of an outbound call (for example, if one of the Proxy servers is down), or load balancing (by assigning some sessions to one proxy as first choice, others to another, etc., or indicating to a group 1 of remotes to call Proxy server 1, to a group 2 to call Proxy server 2, etc. * The application can operate simultaneously with several types of connection (X25, TCP/IP, TX and Proxy; that is, it can have some sessions connected by X25, others against private PADs, others against public PADs, others against native TCP/IP, and others against TCP/IP through a proxy. Even the same session can have several types of connection. * Requires remote editran/P version > 4.0 (both endpoints must have at least version 4.1.5).
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.editran.onesait.com/documentacion-editran/ibm-editran-v5.3-iseries-en/proxy/introduction.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.