Differences

This shows you the differences between two versions of the page.

--- troubleshooting:application_problems [2010/11/16 13:06] – mats
+++ troubleshooting:application_problems [2010/11/17 09:42] (current) – mats
@@ Line 10: / Line 10: @@
 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, adapting these profiles to one's needs and 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** restrictions.
+It is good policy to stick to the more strict **High** or **AltConf** profiles, possibly adapting **AltConf** profile to one's needs.
-Switching between security profiles is quick and easy, using the ''ALT'' frontpanel key.
+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.
@@ Line 19: / Line 21: @@
 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 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.
+  * 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 //ports// that need to be opened up. If so, you could try the following steps:
+  * 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 **High** (or **AltConf**) 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|Log configuration]] page.
+    - 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 seems 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).
+    - 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 on the firewall log, some applications may need several ports opened, so more ports may have to be added to the "Other TCP/UDP ports" 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".)
+    - 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 considerations. Since even the **Low** profile shut these ones out there is no point in trying a switch to that profile.
+  * 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 are information about necessary measures to be taken when the server is behind a firewall.
+    - 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 Firewall log, in the **Show rejected packets** mode as described above. An attempt from any remote client to run 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 the desired application.
+    - 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 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]]. One must also enter the local IP address of the server that sits on the inside LAN.
+    - 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 IP redirection or an Additional rule can be considered. This is generally for the more experienced user.
+:?: 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 log configuration page.
+:!: 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.