IPCop.org FAQs (frequently-asked questions)

The web interface provided by IP-Cop is the best way of administering your Firewall. It needs no software on the client computer that isn't already installed.

If you need to do anything more complicated, for example after installing a new network card, then replugging a keyboard and monitor would be one option (and the only one if the network is now down).

The other method is to use SSH. SSH is a secure command line interface, which is very powerful. There are SSH clients for most operating systems.

Many well documented exploits, along with readily available Telnet password sniffing tools, makes Telnet too insecure to be included in IPCop. Use SSH instead.

Anything is possible, but we would recommend not. SSH is a secure replacement with the same functionality.

SSH is (S)ecure (SH)ell and uses cyptography to overcome known weaknesses with Telnet. When logging on to a server using telnet both your user name and password is transmitted in clear text. This can then be replayed by an attacker to gain access to your account.

SSH sessions encrypt traffic with block ciphers that prevent sensitive data from being sniffed from the wire. Telnet is commonly used in the Windows world because Windows doesnt come with a SSH client.

Windows
PuTTY - http://www.chiark.greenend.org.uk/~sgtatham/putty/

Macintosh
NiftyTelnet SSH - http://www.lysator.liu.se/~jonasw/freeware/niftyssh/

Unix
OpenSSH - http://www.openssh.org

You can find more extensive lists of SSH clients for various (other) operating systems on http://www.freessh.org

SSH usually listens on port 22. However IPCop uses port 222. All SSH connections to the machine need to specify the 222 port. And remember to turn on SSH.

Open the web interface to IPCop.

Select the Remote Access menu item. In v1.2 this was moved to the System > ssh menu item.

Check the box next to SSH and press the SAVE button.

Open the web interface to IPCop.

Select the Services/External Service Access menu item.

Add an entry for:

TCP
Add an address* or blank for access from any address
Port 222
Check the Enabled box

Press the SAVE button.

* You can restrict this access to a single ip address or a subnet for more security than just opening it to the entire world.

To use a single ip address, simply enter the address you wish to allow. To use a subnet, use the CIDR address of the subnet, like 52.124.37.0/24. This would allow access from any ip starting with 52.124.37.

The FTP daemon is not running on IPCop for security reasons. FTP passes usernames and passwords as clear text inside the packets, which makes them very easy to sniff.

To copy files to and from IPCop please use one of the following SCP clients: pscp (Windows), WinSCP (Windows), NiftyTelnet SSH r3 (Mac) or scp (Unix). A more extensive list can be found on http://www.freessh.org. Please remember that these SCP clients connect to the SSH server running on port 222 on your IPCop - You will have to edit the connection details to connect using port 222 not the default 22.

HTTP usually listens on port 80. However IPCop uses port 81 to ease portforwarding issues of port 80. To browse to a IPCop machine you need to use the following style of URL.

http://192.168.0.1:81/

Note you should replace the IPAddress with the correct address or name of your IPCop machine. Also note that some browsers require the protocol (the http:// bit) to be entered when using non-standard port numbers.

Similar to the above, HTTPS usually listens on port 443. However IPCop uses port 445 to ease portforwarding issues of port 443. To browse to a IPCop machine you need to use the following style of URL.

https://192.168.0.1:445/

Note you should replace the IPAddress with the correct address or name of your IPCop machine. Also note that some browsers require the protocol (the https:// bit) to be entered when using non-standard port numbers.

The problem is caused because certificate issuer did not match fqdn (hostname.domainname)

This is related to an upgrade from v1.3 with backup or when hostname or domain name has been changed after the certificate has been created on the first boot after installation.

From v1.4.8, there is a script wich help to repare this problem
Under a console, use
/usr/local/bin/httpscert read to know if there is this problem.
/usr/local/bin/httpscert new remake the certificate to match fqdn in use.