====== Application Support Problems ======

Some applications and protocols you currently use may require some sort of support to be able to work seamlessly behind the firewall. 
If you have trouble making your applications work behind the firewall it is likely that you have to do some change of the configuration in the security profile (**High**, **Low** or **AltConf**) you are using.

The Internet Gate firewall works like a barrier to protect your computer or private network. 
Generally, applications that are initiated from the inside LAN are considered to be less "dangerous" than application attempts that are reaching the Internet Gate from the outside (WAN). 
Consequently, the security profile **High** (and **AltConf**) allows a few applications ("surf", e-mail) to be used from the inside going out, but none at all from the outside. 
The profile **Low** is a bit less strict as it allows //all// applications (using TCP and UDP) started from the inside but still none from the outside. Thus, despite its name, **Low** is still a fairly safe profile.

These are the quite tight settings by factory, and they may be changed as the user opens up "holes" in the firewall, typically port numbers that allow applications to be initiated from the inside, and possibly also servers on the LAN to be accessed from the outside. 
It is good policy to stick to the more strict **High** or **AltConf** profiles, possibly adapting **AltConf** profile to one's needs. 
One can keep the **Low** as a more open profile that can be switched to temporarily when troubleshooting or when trying to run an application that does not work under the **High** or **AltConf** restrictions. 

Switching between security profiles is quick and easy, using the ''ALT'' frontpanel key. See also [[web_gui:security_page|here]] about the security profiles.

:!: Opening up the firewall should be done with care.

===== Making it work =====

If you have problems running an application or service behind the firewall:

  * Check if the Internet Gate supports the application or service that you try to run through the firewall. Click [[Supported_services|here]] for a list of supported applications. Alternatively, simply browse to the [[web_gui:security_profile|security profile]] page and check if there is a checkbox that corresponds to the application.

  * If not in the list of supported applications (nor suitable checkbox/fields found on the security profile page), and the application is started from the inside LAN, there may just be a question of one or more TCP/UDP //[[wp>Port_numbers|port numbers]]// that need to be opened up. If so, you could try the following steps:
    - Switch to security profile **Low** that allows all outgoing traffic
    - Does the application start to work? If not, it is not just a question of opening some ports from the inside. Consult the application documentation and web resources, or the product support.
    - If it works in **Low**, you probably want to know why, so you can adjust the settings of the firewall profile:
    - Switch back to the profile you really want to use (**High** or **AltConf**).
    - Use the firewall log, set it in the mode **Show rejected packets**. This is done on the [[web_gui:log_configuration_page#Firewall Log|Log configuration]] page.
    - Try the application again, and soon after, browse to the [[web_gui:firewall_log_page|Firewall log]] page.
    - Look for packets that are red-marked ''DENY'' and that seem to relate to your application's attempt. Read the port number in the **Dest.** column of the log, and also the protocol name in the **Proto/Type** column (TCP or UDP).
    - Go to the [[web_gui:security_profile#Applications from inside|security profile]] page for the profile you want to use (**High** or **AltConf**) and write the port number in the **Other TCP ports** (or **Other UDP ports**) field under **Applications from inside**.
    - Try the application again. If it still does not work, have a new look again at the [[web_gui:firewall_log_page|firewall log]]. Some applications may need several ports to be opened, so more ports may have to be added to the **Other TCP(UDP) ports** list (use comma to separate). In fact, some applications may need a whole range of ports. If so, the application's documentation should be consulted. (A port range is written like "XXX-YYY".)

  * Applications, e.g. servers, that run on the LAN and should be accessible from the outside need other settings. Since even the **Low** profile shut these ones out it will probably not work by switching to that profile.
    - If not in the list of supported applications, consult the application's documentation, sometimes there is information about necessary measures to be taken when the server is behind a firewall.
    - One could also try to use the [[web_gui:firewall_log_page|Firewall log]], in the **[[web_gui:log_configuration_page#Firewall Log|Show rejected packets]]** mode as described above. An attempt from any remote client to contact the server would probably show up as ''DENY'' entries in the log. Take notice of the protocol and (destination) port numbers in those entries, and try to verify that the entries really are resulting from requests to the desired application.
    - If, by one way or another, the obstructed port numbers now are known, one can add a **port redirection** in the security profile settings to let those packets through the firewall. This is described [[web_gui:security_profile#Port redirection|here]]. There one must also enter the local IP address of the server that sits on the inside LAN.

:!: It is potentially more "dangerous" to enter port redirections (from outside-to-inside) than just opening up ports/protocols from the inside.

:?: For some applications that don't have a built-in support in the Internet Gate, none of the above measures might be sufficient. In these cases, an [[web_gui:security_profile#IP redirection|IP redirection]] or an [[web_gui:security_profile#Additional rules|Additional rule]] can be considered. This is generally for the more experienced user.

:!: If you have used the firewall log for experimenting as described above, please remember to shut it off again on the [[web_gui:log_configuration_page#Firewall Log|log configuration]] page.