1      NetWork

1.1                Open Ports on SecureOffice Firewall

The SecureOffice firewall restricts (blocks) WAN access to local LAN, a security feature, to keep hackers out.

If public access to internal services provided by SecureOffice is required, the service ports need to be opened to become visible to SecureOffice service listeners and internet clients.

As an example, assume that the SecureOffice web server (Nginx) is required to serve public web pages using port 8080. After the web content has been created and Nginx configured to serve the content, port 8080 must be opened to allow internet users to access the content, otherwise the site would only be accessible from the local LAN at "<your lan address>:8080" from a browser on your LAN.

Using a web browser, from a computer on your LAN, login to the OpenWrt / SecureOffice web GUI and navigate to "Network->Firewall->Traffic Rules". The "Open ports on router" configuration section will display near the bottom of the page, as shown below.

Figure 1: Define Port to Open

Name the input rule "open-8080", select TCP as the protocol, enter 8080 for "External Port", click "Add", then "Save & Apply". The new input rule will display as shown below.

Figure 2: Port 8080 Opened

1.2                Forward Ports on SecureOffice Firewall

The SecureOffice firewall restricts (blocks) WAN access to local LAN, a security feature, to keep hackers out.

If publicly accessible services are provided by external (not by SecureOffice) servers on the LAN, for example other computers or virtual machines on the LAN, the service ports need to be forwarded to the LAN IP address (must be static) of the server.

An alternative to port forwarding is to define a virtual host and let Nginx take care of (proxy) the forwarding (see proxy locations). All Nginx virtual hosts share ports 80 and 443.

Port forwarding is used if public access to services using Nginx virtual host addressing (recommended approach) is not desired, or public access to non-web services.

If you are running publicly accessible services such as websites and email / file servers, clients on the internet (WAN) need to get through the firewall to access the services on the local LAN. This is achieved by port forwarding. It is very important to use ports that are not in use. Ports 80 and 443 are reserved for Nginx for Luci web GUI and virtual host access.

To forward a port, using a web browser, from a computer on your LAN, login to the OpenWrt / SecureOffice web GUI and navigate to "Network->Firewall->Port Forwards". The "New Port Forward" configuration section will display at the bottom of the page, as shown below.

Figure 3: Define Port Forward

• Enter a descriptive name such as "Allow service X".
• Select protocol, TCP and / or UDP.
• Select external zone (wan).
• Enter External port YY (must not be in use). Enter (command prompt) "netstat -tunlp" to determine ports in use.
• Enter Internal Zone (lan).
• Enter Internal IP Address (for example, the LAN address of your server or virtual machine)
• Enter Internal Port ZZ.

Press "Save&Apply".

The page will refresh and the new firewall entry will display, as shown below.

Figure 4: Http Port Forwarded

1.3                IP Address Numbering Plan

Many devices requiring IP addresses including virtual machines and docker containers can be connected to or served by SecureOffice. Some of these devices require static IP addresses. If two devices on the LAN have the same IP address, conflicts will occur, breaking connectivity. This section discusses measures to prevent IP address conflicts for SecureOffice.

The default SecureOffice LAN configuration is:

• "netmask": "255.255.255.0" ("/etc/config/network"). The LAN supports 255 addresses of which <LAN base subnet>.0 (reserved), <LAN base subnet>.1 (SecureOffice LAN address) and <LAN base subnet>.255 (broadcast) where "<LAN base subnet>" is the first three digits of the LAN IP address assigned in "/etc/config/network".
• "start": "100" ("/etc//config/dhcp"). DHCP address assignments will start at <LAN base subnet>.100 (default: 192.168.10.100)
• "limit": "150" ("/etc//config/dhcp"). 150 addresses can be assigned by DHCP. Last DHCP assigned address will be <LAN base subnet>(start + limit -1) (default: 192.168.10.249).

Static (fixed) IP addresses must be assigned outside of the DHCP assignment range (default: <LAN base subnet>.2 to <LAN base subnet>.99 and <LAN base subnet>.100 to <LAN base subnet>.249). This leaves addresses <LAN base subnet>.2 to <LAN base subnet>.99 and <LAN base subnet>.250 to <LAN base subnet>.254 free for static IP address assignment.

If intending to use docker containers with SecureOffice:

• IP addressees for docker containers are allocated (by docker) on a first come, first serve basis. This means, as containers are spun up (in same order as enabled by docker config files in "/etc/config/docker/"), the first container is allocated <LAN address + 1>, second, <LAN address + 2>, etc. This means that a block of IP addresses must be left free for docker containers. This is done by the lan, option "start" (default: 100) entry in "/etc/config/dhcp". <LAN address + 1 to 99> are free for container IP addresses.
• It is suggested that a block of IP addresses starting at <LAN base subnet>.2 (default 192.168.10.2) with enough range (below DHCP address assignment) be reserved for docker container IP addresses.
• To do so, determine how many containers you intend to run and reduce the "start" value ("/etc/config/dhcp") to accommodate. For example, a "start" value of "10" means that DHCP address assignments will start at <LAN base subnet>.10 and addresses <LAN base subnet>.2 to <LAN base subnet>.9 (192.168.10.2 to 192.168.10.9) will be available for eight docker containers. This makes room for non-docker static IP assignments (above DHCP) from <LAN base subnet>(start + limit) or <LAN base subnet>.(10 + 150) or, 192.168.10.160 to 192.168.10.254. The DHCP and static IP ranges for non-docker devices can be further altered using the "limit" value.
• Alternatively, do not change default settings, start (non-docker) static IP assignments at <LAN base subnet>(2 plus number of docker IP addresses desired). Reserving for eight docker containers as above, other static IP assignments can start at <LAN base subnet>.10. Using defaults, this means addresses 192.168.1.10 to 192.168.1.99 are available for non-docker device static IP addresses. There will be a hard to diagnose IP address conflict if more than eight docker containers request IP addresses.

In summary, alter the DHCP start and limit values to ensure that enough LAN addresses are available for docker containers, DHCP and static IP addresses or, start static IP assignments above a block of IP addresses reserved for docker containers.

1.4                IP Device Naming Plan

Device names (like URL's) are a human recognizable alias for a device on the network which allows the device to be referred to by name which is easier to remember than an IP address. For example, if you have many IP cameras and IOT devices, you can refer to them by name as opposed to IP address.

It is suggested to use the following naming convention for devices. Names cannot have spaces:

<Manufacturer>-<Model>-<Device>-N

For example, if you have five Foscam FI9928P IP cameras, they would be named:

Foscam-FI9928P-Camera-<1 to 5>

As another example, if you have two Sonoff Basic switches flashed with Tasmota firmware and one original with ewelink firmware, they would be named:

Sonoff-Basic-tasmota-switch-1

Sonoff-Basic-tasmota-switch-2

Sonoff-Basic-ewelink-switch-1

This allows them to be referenced by an easily remembered name: "Sonoff-Basic-tasmota-switch-2" as opposed to "hard to remember IP address"

Further, when devices are referenced by name in configuration, IP addresses can be controlled and changed at one central location, reducing confusion, as discussed in the next section.

1.5                Assign Fixed IP Addresses to LAN Devices

Any well managed network needs an IP address numbering plan, where the IP addresses of network devices remain constant (the same) across boots. This is crucial for devices which provide internet services, since the firewall must be configured to forward external ports to the device, or, Nginx must proxy the device which requires fixed IP addresses.

There are two ways to assign network devices fixed IP addresses:

• Directly configure the IP address on the device. This is how the Sme-Server VM is configured. A drawback of this method is when network changes occur, such as changing LAN address, all devices must be manually reconfigured with new static IP addresses. Another drawback is that separate records must be kept relating IP address assignments to device. Lack of IP address records also makes tracking down IP address conflicts (two or more devices using same IP addresses) far more difficult.
• Configure the SecureOffice DHCP server to assign fixed IP addresses / leases based on device MAC (hardware) address. The configuration consists of a list of MAC addresses, associated IP addresses and device names, making it easy to avoid and track down IP address conflicts. This is the preferred method to achieve, manage and easily change your IP address numbering plan.

If you are considering changing the IP address of Sme-Server virtual machine from static assigned (VM configuration) to dynamically assigned a constant IP address by DHCP, do not attempt this. Sme-Server in server-only mode requires a static IP address and does not support DHCP.

Prior to proceeding, the MAC (Ethernet hardware address) of the device needs to be identified and a unique LAN IP address chosen, outside of the DHCP assignment range.

For virtual machines, the MAC address can be determined by using VmWare Workstation to open the virtual machine and navigating to "Player->Virtual Machine Settings->Network Adaptor->Advanced". In the window, you will see "Mac Address" of the form "AA:BB:CC:DD:EE:FF" composed of hexadecimal values. If, for some reason, a new MAC address is desired, press "Generate" for a different one. All network devices require a unique MAC address. Copy or write down the MAC address for subsequent configuration.

For other devices, the MAC address can be determined by configuring the device for DHCP and inspecting "Active DHCP Leases" using SecureOffice web GUI. Navigate to "Network->DHCP and DNS". Note that it may take time for the device to appear on the list. Confirm that you have the correct device by pinging its IP address (will correctly respond), disconnect the device from the LAN and ping it again. If ping fails, you have the correct device. Copy or write down the MAC address for subsequent configuration.

Choose an unused IP address, outside of the DHCP assignment range of SecureOffice to assign to this device.

Using a web browser, from a computer on your LAN, login to the OpenWrt / SecureOffice web GUI and navigate to "Network->DHCP and DNS->Advanced Settings" will display the "Static Leases" configuration at the bottom of the page, as shown below.

Figure 5: Add Static Lease

Press the "Add" button. A new static lease entry will display, as shown below.

Figure 6: Edit Static Lease

Fill in a descriptive name for "Hostname" such as what the device is. Scroll down to "custom" for "MAC Address" and enter the MAC address of the device. Scroll down to "custom" for "IPv4 Address" and enter the desired LAN IP address for the device. Press "Save & Apply". The new static lease assignment will display, as shown below. Your values will vary.

Figure 7: Static Lease Entered

Alternatively, IP address assignments can be done by directly editing file "/etc/config/dhcp" and creating an entry like below:

Figure 8: DHCP Static IP Assignment

If the device was previously configured with a static IP address, it must be reconfigured to use DHCP to obtain the assigned IP address. How to do this is device specific. Consult the device or virtual machine documentation.

After making static IP address assignments, disconnect the corresponding device. Using a command prompt, enter "rm -f /tmp/dhcp.leases; /etc/init.d/dnsmasq restart" to clear out previous DHCP leases and load the new configuration. Reconnect the device and it should be at the assigned IP address. This can be confirmed by entering "cat /tmp/dhcp.leases" to observe the updated IP assignment for the device.

1.6                Only Allow Specific WiFi Clients

It is possible to restrict WiFi access to a specific client list or restrict certain clients, based on client MAC address (AA:BB:CC:DD:EE:FF).

To do so, edit "/etc/config/wireless" and add (leave rest alone) the "macfilter" and "maclist" options.

Figure 9: Allow / Restrict WiFi Access

To determine the MAC address of a client device, connect it to WiFi and enter "cat /tmp/dhcp.leases". The MAC address will be associated with the DHCP IP address assigned to the device.

2      Diagnosing Network Problems

Unless stated otherwise, all network tests use the SecureOffice command prompt, either via SSH using PuTTY or directly using a monitor and keyboard physically connected to SecureOffice.

2.1                Isolate the Problem

Identify the failure symptom(s) and follow the tests / recommendations in subsequent sections.

If these troubleshooting steps fail, collect information regarding failure symptoms, what you have tried and post a help request in the SecureOffice user forum.

2.2                DHCP / LAN Connection Issues

Symptom: Client PC's on LAN cannot connect to SecureOffice using PuTTY. Windows Local Area Connection has no internet access.

Causes: Bad Ethernet cable, Reversed SecureOffice WAN / LAN ports, PC Local Area Connection misconfiguration, DHCP issues.

2.2.1      Ensure Client Has Valid LAN IP Address

Verify the following:

Your PC is connected to the SecureOffice LAN port (or WiFi) and the WAN and LAN Ethernet ports have not been reversed on SecureOffice.

To confirm this, configure your PC Ethernet port for an unused static IP address on the LAN (eg: "192.168.10.10") with a netmask of "255.255.255.0". From a windows command prompt, enter "ping LAN address of SecureOffice". Where "LAN address" is the "ipaddr" value in the "lan" section of "/etc/config/network" (default: "192.168.10.1"). Also ensure that the "netmask" value for "lan" is "255.255.255.0" (default), or what you intend it to be. A valid ping response means that your PC is connected to the SecureOffice LAN. An invalid ping response means that either SecureOffice Ethernet ports are reversed or the SecureOffice LAN address is not what you think. Reverse the Ethernet port connections on SecureOffice and ping again. An invalid ping response (with ports reversed or not) means the static IP address and / or netmask in "/etc/config/network" do not match your PC Ethernet interface settings. If unsuccessful with these tests, check for a bad Ethernet cable and connections are secure. Once ping is working properly, place labels on the SecureOffice LAN and WAN ports, to avoid this problem in the future. Restore the "Obtain IP Address Automatically" (previous link) setting for your PC Ethernet interface. You may have to disconnect / connect the Ethernet cable for the new settings to take effect.

From Windows "Control Panel -> Network and Internet -> Network Connections", right click on "Local Area Connection", select "Status" and then "Details". Check that "IPv4 Address" is a valid DHCP address on the SecureOffice LAN and "IPv4 Subnet Mask" are as expected. In particular, the last field of "IPv4 Address" is in the range between "start" and "limit" for the "lan" section in "/etc/config/dhcp" (default 100, 150) and "IPv4 Subnet Mask" is identical to the "netmask" value in the "lan" section of "/etc/config/network". If the DHCP values in "Status" are as expected, DHCP is working and communication with SecureOffice LAN are working properly, the next ping test should pass. If the values in "Status" are incorrect, disable and re-enable "Local Area Connection" on the PC by right clicking it and try again.

From a Windows command prompt, enter "ping <LAN address of SecureOffice>". Where "LAN address" is the "ipaddr" value in the "lan" section of "/etc/config/network" (default: "192.168.10.1"). Also ensure that the "netmask" value for "lan" is "255.255.255.0" (default), or what you intend it to be. A valid ping response indicates that the LAN connection is active and DHCP is working properly. Troubleshooting for this section is complete.

An invalid ping response indicates a DHCP issue. Using a SecureOffice command prompt enter "ps -Af | grep dnsmasq" to determine if the DHCP service is running. The command response should contain "/usr/sbin/dnsmasq", else DHCP is not running on SecureOffice. To enable and start the DHCP service, enter "/etc/init.d/dnsmasq enable; /etc/init.d/dnsmasq restart; ifup lan". Repeat the tests in the previous two paragraphs to ensure the problem has been solved.

If DHCP problems persist, disable and re-enable "Local Area Connection" (control panel on PC) by right clicking on it and try again.

If the problem persists, enter "logread | grep dns" to observe dnsmasq / DHCP error messages for further troubleshooting clues.

Check the OpenWrt DHCP troubleshooting Wiki.

Do not proceed with any further troubleshooting until your PC has a valid connection to SecureOffice LAN.

2.3                Internet Connectivity Issues

Symptom: PC Local Area Connection has no internet access, can ping SecureOffice.

Causes: Misconfigured ISP WAN connection, DNS problems

From a SecureOffice command prompt, enter "ping yahoo.com". A valid response indicates that your ISP and internet interface (modem) is connected and configured properly and that DNS is working.

An invalid ping (yahoo.com) response indicates either a DNS or ISP WAN configuration problem. DNS can be eliminated as a problem by entering "ping 8.8.8.8" (Google DNS server). A valid response indicates a DNS problem, skip to the next section. An invalid response indicates that your ISP is down or misconfigured.

You will have to check the help pages of your ISP for information regarding required configuration of the WAN interface (DHP, static, other), combined with consulting the OpenWrt Troubleshoot Internet Connection Wiki.

Do not proceed until the "ping 8.8.8.8" command succeeds.

2.4                Domain Lookup / DNS Issues

Symptom: ping returns "bad address" for all domain names.

Cause: NameServer mis-configuration.

The "dig" utility can be used to diagnose DNS issues. To install it enter "opkg update; opkg install bind-dig".

Enter "dig +noall +answer <domain>" where <domain> is any domain (eg: google.com) that ping fails with "bad address". There should be no result. Enter "dig +noall +answer @8.8.8.8 <domain>". This instructs dig to use the Google NameServer. If there is a valid response, SecureOffice DNS is misconfigured.

DNS Servers are configured using option "dns" under "wan" section in "/etc/config/network". The defaults are "option dns '8.8.8.8 8.8.4.4'" (Google Name Servers). Ensure that any dns entries are valid DNS servers.

If there are still DNS issues, consult the OpenWrt DHCP Wiki and Network Wiki.

When done, dig can be uninstalled by entering "opkg remove bind-dig"

2.5                DDNS Issues

Symptom: "ping <yourdomain>" fails.

Cause: DDNS service not running or misconfigured

Enter "ps -Af | grep ddns" at a command prompt. You should see a line containing "/usr/lib/ddns/dynamic_dns_updater.sh" for each domain configured for DDNS updates. If there are no such lines, enable and restart the DDNS service by entering "/etc/init.d/ddns enable; /etc/init.d/ddns restart; ifup wan".

It takes several minutes for DDNS to update your IP address after the service starts.

DDNS status and reported errors can be checked by examining the "/var/log/ddns/" logfile or entering "logread | grep ddns".

If "ping <yourdomain>" is still not working, you will have to check your configuration and troubleshoot by consulting OpenWrt Wiki articles DDNS Client, Dynamic DNS Client configuration and any troubleshooting articles your DDNS provider may have on their website.

2.6                Required Ports Not Responding

Symptoms: No public internet access to some service ports.

Causes: Ports not opened and / or forwarded on firewall, service not running

If some service such as public internet access to your website is not functioning, the first thing to do is determine the required ports and check that the ports are accessible from the internet, using an online port checker tool. In the case of website access, the ports are HTTP (80) and HTTPS (443).

Using this online port checker, enter your domain name and the ports to test. The tool will tell you whether the ports are open or not. An open port means that the firewall is not blocking and that the service on the port is responding. A closed port means that either the firewall is blocking or, the corresponding service is not running.

To determine whether the firewall is blocking the port, install the tcpdump utility, to monitor Ethernet packats. Enter "opkg install tcpdump" to install tcpdump.

Enter "tcpdump -i <ethX> <port #>", where <ethX> is the WAN interface and <port #> is the port that is not open. This command monitors the WAN interface and displays all packets on <ethX> with <port #>. Repeat the online port test.

No tcpdump response means that you have a more basic and serious internet connection issue and should repeat the tests in the previous sections to isolate and fix any issues before proceeding.

A tcpdump response means that packets are making it from the internet to the WAN interface. Enter "tcpdump -i br-lan <port #>", where <port #> is the port that is not open. This command monitors the LAN interface and displays all packets on the LAN with <port #>. Repeat the online port test.

No tcpdump response means that you have a firewall issue, blocking the port. Follow the HowTo instructions in Opening Ports on SecureOffice Firewall or Forward Ports on SecureOffice Firewall for SecureOffice internal or external services respectively to ensure that the required ports are open.

Repeat the "tcpdump -i br-lan <port #>" test above. There should be a response; otherwise you still have firewall issues which need to be fixed before proceeding.

If the port test still indicates the port is closed, and tcpdump indicates packets are present on the LAN, the service associated with the port is either misconfigured, or not running.

2.7                Service not Running

Symptoms: ports not blocked, can see (tcpdump) packets destined for service on LAN.

Causes: service misconfiguration, startup issues.

Entering "netstat -tunlp" will display a list of running internal network services and the ports they are listening to. You should see your service listening to the proper ports if it is running.

If the service is provided by a virtual machine or device on the LAN, the VM or device is not responding. Enter "ping <device LAN IP address>" to see if it is responding. Whether it does or not, the VM or device must be troubleshooted.

To determine whether a service is running, enter "ps -Af | grep <process or service name>". If the service is running, you should see it. Most likely, the service is mis-configured. Check the service configuration files.

If the service is not running, restart it and determine if it is running. If it is not running, enter "logread" and look for error messages. Also check the service logfile it has one. These steps should provide enough clues to do an internet search for solutions.

If all else fails, explain the symptoms and what you have done in the user forum.