Relays in Ingate Firewall
Ingate Firewall has a number of relays: TCP relay, UDP relay, address rewriting HTTP relay, FTP relay, and DHCP relay. All relays (except for the DHCP relay) have access control, meaning that they can be configured to allow traffic only from certain IP addresses. Relays can also be configured to be active only for certain time intervals, such as only working hours or only during the weekend. This is accomplished by defining and using time classes for the relays.
Relays
A relay performs a simple forwarding of traffic from one address to another. The relay receives traffic that comes to a certain port at a certain IP address of the firewall, and sends it on to a specific port on a specific computer. You set the IP addresses and ports for each relay.
One example of using a relay is if there is a mail server on the internal network when NAT is on. The name server, which will be used by everyone on the external network, directs all e-mail to 197.17.42.7.
Now we create an alias for the IP address 197.17.42.7 in the firewall and set up a relay to receive connections on port 25 for this IP address. We specify that all e-mail should be sent on to port 25 of the computer with the IP address 172.22.42.17, the mail server's IP address on the internal network.
Another typical area of use is a web server on the internal network. We have set up www.company.se on a name server, with an IP address which our firewall has on the outside. In the firewall, we set up a relay that sends WWW traffic on to the web server on the inside.
Suppose an organization has two web servers. One is for internal use and the other is available from the outside. Both servers are running on a computer with IP address 172.22.10.17 on the internal network. The internal server uses port 80 and the external one uses port 8080. By configuring a TCP relay to listen to port 80 on the external interface of the firewall, and relaying the traffic to port 8080 at 172.22.10.17, the web server is available from the outside.
TCP and UDP relays
With a TCP relay, the client machine connects to an IP address and a port in the firewall. The client machine only sees the firewall. The TCP relay receives a TCP packet, generates a new TCP packet with the same content and forwards the traffic to the server. What the server sees is a connection from the firewall; it does not see the actual client.
A UDP relay works in the same way as the TCP relay, but forwards UDP traffic.
Port forwarding
With regular TCP port forwarding, the client machine connects to an IP address and a port in the firewall. The client machine only sees the firewall. The TCP relay forwards the traffic to the server after rewriting the sender address to that of the firewall. What the server sees is a connection from the firewall; it does not see the actual client.
UDP port forwarding works in the same way as the TCP port forwarding, but forwards UDP traffic.
Semi-transparent port forwarding
With semi-transparent TCP port forwarding, the client machine connects to an IP address and a port in the firewall. The client machine only sees the firewall. The TCP relay forwards the traffic to the server without rewriting the sender address to that of the firewall. What the server sees is a connection from the actual client. The exception from this is when the client and the server are connected to the firewall via the same interface; then, the sender address is rewritten just as for the regular port forwarding.
Semi-transparent UDP port forwarding works in the same way as the semi-transparent TCP port forwarding, but forwards UDP traffic.
Address rewriting HTTP relay
The address rewriting HTTP relay works in approximately the same way as a standard relay, except that the relay looks at all outgoing traffic from the web server on the inside. The relay replaces the web server's IP address with the IP address that the firewall has on the outside for this relay in all outgoing traffic. This relay is somewhat slower than a standard relay. The relay does not understand HTTP or HTML and can sometimes exchange too much data, so it is usually better to use a standard relay for WWW traffic.
FTP relay
Another relay is FTP, which manages connections to an FTP server. For the client computer the FTP relay acts like an FTP server. The relay tries to establish contact with the FTP server just like a standard client. The FTP server only sees the relay and interprets it as a client.
FTP has two types of connections, active and passive. In an active connection, the client connects to the command port on the server, usually port 21. When a file is transferred, the server connects to the client for data transfer. For active FTP, the FTP relay assumes that FTP data is the port number under the one for FTP commands. This applies both to the port the FTP relay is listening to and the Relay to Port. Usually, the server uses port 21 for FTP commands and 20 for FTP data.
Arrows indicate in which direction the connections are set up. The direction of the data flow is independent of this.
In a passive connection, the client connects to the command port on the server. To send a file, the client connects again to a port with a number over 1023 on the server for the data transfer.
Active and passive FTP are both supported by Ingate Firewall's FTP relay.
DHCP relay
The DHCP relay handles DHCP requests between a client and a DHCP server. This makes it possible to let one single server support clients on several networks, thereby simplifying the IP address distribution.
DHCP requests are BOOTP packets sent from a client who wants to obtain an IP address. Since the client has no IP address and doesn't know about the network configuration, it just broadcasts the request. One or more DHCP servers reply, sending packets addressed to the client. The packets could grant an IP address or reject the request if no IP addresses are available.
Most DHCP servers are configured to hand out dynamically allocated addresses, which means that the client leases an address and must ask for new leases regularly. The server always checks an address before handing it out, to be sure that it really is available. This could be performed using ping, which means that ping also must be let through to the networks that the server supports. The client also checks the newly received address, e.g. using ARP, which means that you also must open for ARP communication between the networks.
Ingate Firewall relay limitations
There are some limitations for the Ingate Firewall relays. These are mostly of the form that some ports can't be used for some of the firewall IP addresses (this renders the error message The same local IP address/port combination is listened to more than once).
In these limitation descriptions, all references to "relays" means relays, port forwardings and semitransparent port forwardings unless otherwise stated.
TCP relay on port 80 or 443
You can't make a TCP relay listen to port 80 (http) or 443 (https) on the IP address used for firewall configuration, i. e. the IP address which you connect to to make configurations on your firewall. This is because these ports are locked for the configuration traffic and can't be used for anything else.
To relay traffic through the firewall to servers on your local network, you must create an Alias on the interface holding the configuration IP address. Then, use this alias for the relays.
UDP relay on port 500
You can't make a UDP relay listen to port 500 (IKE) on any firewall IP address when VPN is installed. This is because these ports are locked for the firewall's own IKE traffic and can't be used for anything else.
The best way to work around this is to terminate VPN tunnels in the firewall.
UDP relay on port 514
You can't make a UDP relay listen to port 514 (syslog) on any firewall IP address. This is because these ports are locked for the firewall's own syslog traffic and can't be used for anything else.
If you need to send syslog traffic through the firewall, try to make the syslog message senders send to a different port.
Relays and VPN
If you haven't entered a Default gateway on the Basic Configuration page, you have to select a VPN peer under Allow access from on the IPsec Peers page if computers should be allowed to use the relay through a VPN connection. If no VPN peer is selected, traffic through VPN connections won't be allowed to use the relay.
If you want to allow computers to use the relay regardless of their using VPN, you have to configure a default gateway for the firewall.