Access Control Lists

The h323-proxy uses only single layer ACL (see access-control(7)) called session-acl.

When a connection arrives, configuration is consulted, proper session-acl is selected and according to it, connection is allowed or not.

When a transparent connection arrives (i.e., a connection destined for another server is transparently redirected to h323-proxy — see transparency(7) for details), the proxy will connect to the original destination server.

When a non-transparent connection arrives (i.e., a connection destined directly for one of the sockets h323-proxy is listening on) and is allowed by policy, either the proxy must be configured to connect to a specific remote server by the plug-to configuration directive (see below) or the caller must identify destination in H.245 Setup packet.

If a plug-to directive is used for a transparent connection, it has precedence over the original destination. This means that h323-proxy will ignore the original destination and connect to the plug-to server.

Common Kernun Features

The proxy uses common Kernun mechanism for listening on its sockets, forking new processes as needed and killing old redundant processes, optionally changing root directory and running with alternative user privileges. For more detailed information, see application(5) and tcpserver(7).

The proxy uses common Kernun mechanism for network input/output operations. Configuration allows for specifying several parameters like buffer sizes and timeouts, for client and server connections and multimedia data channels. They can be included in client-ctrl, server-ctrl and data-channel configuration sections, respectively. For more detailed information, see netio(7).

The proxy uses common Kernun mechanism for name resolving (see resolving(7)).

The proxy uses common Kernun mechanism for logging (see logging(7)). When a connection comes to the proxy, the SESSION-START (MMCP-808-I) and the ACL (MMCP-810-I) messages are logged. After successfull decision about the server being connected, the SESSION-INIT (MMCC-808-I) message is logged. After closing the session, the SESSION-END (MMCP-809-I) message is logged.

The proxy uses common Kernun mechanism for traffic shaping. For more detailed information, see traffic-shaping(7).

Program Options

The program options are as follows:

Open gatekeeper mode

In this case, clients use a gatekeeper without authentication and the gk-proxy can modify content of RAS packets so that instead of clients' private addresses only firewall's public address appears on the net. The gk-proxy uses for each client separate port from the dedicated block and the h323-proxy must manage NAT rules for these ports. This is the meaning of the client-block configuration item. Address must be set identically in both proxies and size defined for h323-proxy must be at least as large as gk-proxy connection table size. Additionally, the h323-proxy must listen also on one special port, to which gk-proxy redirects sessions requested by local clients and destined to outside world.

Example:

    gk-proxy open-gk {
        listen-on {
            transparent fw-int : 1719;
        }
        udpserver { max-sessions 10; }
        map-file  "/tmp/ras.yp";

        session-acl open-gk {
            to transparent open-gk.abc.com;
            register       fw-ext : 40000;
            h323-address   loopback : 3420;
        }
    }

    h323-proxy mm-proxy {
        listen-on {
            non-transparent loopback : 3420;
            non-transparent fw-ext : 40000;
        }
        map-file "/tmp/ras.yp";
        client-block fw-ext : 40000 10;

        session-acl outgoing {
            from [192.168.0.0/16];
            to transparent *;
        }

        session-acl gk-served {
            to non-transparent *;
            source-address client;
        }
    }

Authenticated gatekeeper mode

When clients use a gatekeeper with authentication the gk-proxy cannot modify content of RAS packets because authentication would fail. That's why it uses client mode of registration (unfortunately, private addresses occur on the net). In this case, an H.323 connection is always initiated by local client, so only the h323-proxy special port is needed, to which the gk-proxy redirects (by means of NAT) all connections. That's the reason for apparent discrepancy between listen-on (non-transparent) and session-acl (transparent) directives.

Example:

    gk-proxy auth-gk {
        listen-on {
            transparent fw-int : 1719;
        }
        udpserver { max-sessions 10; }
        map-file  "/tmp/ras.yp";

        session-acl auth-gk {
            to transparent auth-gk.abc.com;
            register       client;
            h323-address   loopback : 3420;
        }
    }

    h323-proxy mm-proxy {
        listen-on {
            non-transparent loopback : 3420;
        }

        session-acl outgoing {
            from [192.168.0.0/16];
            to transparent *;
        }
    }