:::Proxy:::
(client sends the request to the web proxy. web proxy retrieves the page on the client’s behalf and the sends it back to the client)
(proxies are used to handle web traffic, but other services can also be handled e.g. DNS proxy)
(Squid web proxy is used on the smoothwall as a proxy engine)(but smoothwall has created a web interface for setting up proxies)
:Two types of proxies configurations:
1.Non-transparent:
(run on a specific port)(browsers are applications are told where the proxy is in order to use it)
2.Transparent:
(works by intercepting web traffic and routing it through the web proxy)
(in order for this to work the traffic need to be physically passed through the interface on the SWG)
(using SWG as the default gateway and using bridged interfaces to achieve this)

:WCCP(Web Content Caching Protocol):(a cisco feature)
(cisco routers and switches can be configured to intercept web traffic and forward it to the web proxy)
(SWG also supports WCCP)

(smoothwall recommends non-transparent proxy as transparent proxy can cause some issues)
(client need to know where the proxy is and what the port number is)

:Dashboard->web filter->Statistics: (shows the web filter health and status of the system)
Uptime: 0d 9h 39m
Web requests: 19
Average request rate: 0.0/min
Median service time (last 5 minutes): 0.00000s
Requests blocked (last 24 hours): 0.0%

:Authentication:
1.Proxy authentication standard gives a pop-up dialog for the user to enter the u/p, which is not recommended.
2.pass through methods such as kerberos and NTLM are recommended. u/p are logged on and verified automatically.
(but some application do not support this)(especially non-web applications)(very common issues from the customers)
(browsers, applications and OS need to support these methods)
(if applications do not support them, it tends to be difficult to tshoot them, as no errors are shown)

:Browsers:
1.SWG works with all web browsers:
1.Safari
2.Firefox
3.Chrome
4.Opera
5.IE
(they all have proxy settings)

:Applications:
(there are numerous applications that use web ports and protocols)
e.g:
1.Google Drive
2.Dropbox
3.Google Earth
(applications that do not support authentication or web proxy in general is difficult)
(all applications have different types of behaviour)
(one method of fixing application proxy authentication problem is to bypass authentication)
(we need to know what domains and IP addresses the application talks to)
(Web proxy » Authentication » Exceptions)(for adding the category groups and/or swurl lists)
(e.g: application like dropbox which talks to only one domain dropbox.com is easy)
(but if an application that talks to dynamic list of IPs such as skype it is difficult) (so by passing an authentication for a destination is not an option)
Solutions:
1.(by passing a web filter requires another proxy to be setup and the application told to use this proxy instead of the proxy that requires authentication)
(e.g: Non-transparent proxy 192.168.136.168:805 / Test location : no authentication)

2.(we can bypass the proxy completely)

3.(we can use another authentication method other than pass through)
(e.g: use SSL login authentication method)(solves any or all authentication issues with applications)

:Mobile Devices:
1.Tablets (iPad and Android tablets)
2.Phones (iPhones, Windows Phones and Android Phones)
3.Kindles
4.Laptops
(non of the mobile devices support pass through authentication support and proxy support is hit and mis)
(some OSes like iOS has fairly good support for proxies, but this doesn’t mean that the applications running on these platforms use those settings)
1.For mobile devices i.e. Wifi or BYOD, there are only 2 viable options:
1.SSL login method
2.802.1x Enterprise method (rely on the DHCP server on UTM)
3.Global proxy settings(only on iOS7)(using smoothwall connect client)(also available for windows OS)

:HTTPS:
(handling https traffic can be daunting too)
(smoothwall has features such as decrypt and inspect and validate certificates)
(SWG can even transparently proxy https traffic)

:::::::Proxy settings and applications::::::::
(you can have any number of proxies using any number of authentication methods)
(you can have multiple authentication methods on the same proxy based on the location the client is coming from)
(most issues are usually related to the proxy authentication)
Web proxy » Authentication » Policy wizard:
:Proxy Authentication Methods:
1.Pass through methods:
(not all applications or OS supports them)
1.kerberos
2.NTLM
(one method for applications which do not support them is to by pass the application from proxy authentication)
(Web proxy » Authentication » Exceptions: in exceptions menu we can add categories which do not require authentication)
(but the same categories also need to be allowed in the everyone group in the web filter policies)

2.Redirect users to SSL login page (with background tab)(with session cookie):
(user can login to SSL login page before getting the web access)(https://192.168.56.99:442/login)
(it requires the users to be logged in first before the application can get access to the web)
(also for the wifi connections before accessing the web)

3.Identification by location:
(place users in a specific IP based group and give access based on this group)
(location to users or user groups mapping is done in the ident by location section:Web proxy » Authentication » Ident by location)

4.NTLM and Kerberos (via redirect methods are used by transparent proxies)
(when a new user connects it asks the user to credentials, before letting the user proceed)

e.g:
(two non-transparent proxies)
Non-transparent proxy 192.168.136.168:800 with 3 locations and authentication methods:
1.server location : identification by location
2.staff PCs : redirect users to SSL login page (with session cookie)(staff uses many applications that use proxy)
3.Everywhere: NTLM authentication
Non-transparent proxy 192.168.136.168:805 with 1 locaiton and authentication method
1.Test location : no authentication
(used to tshoot the applications)
(1 transparent proxy) (intercepts all the traffic on the interface on which the proxy is configured on)
(also intercepts the https traffic)(application need to be complient with SNI for https inspection)
1.Everywhere : no authentication
Filter HTTPS traffic: ticked
Allow HTTPS traffic with no SNI header for the ‘Transparent HTTPS incompatible sites’ category: ticked
(non-SNI supported sites will not be filters, only SNI supported sites will be filtered)

5.Client Proxcy settings:
IE:
1.automatically detect settings:
There are two ways the automatic proxy settings can be configured:
1.DNS server (used by IE and all other browsers)(adding a wpad hostname to the dns as an alias that points to the server that is hosting the proxy script)
(browser set as automatically detect settings will ask for wpad.dat if the wpad hostname is resolved)(which is the same as the proxy.pac file) (knowledgebase)
2.DHCP server (used by IE)(option 252)(option 252 is already configured on smoothwall if used as a DHCP server, but on MS it need to be configured over various scopes) (knowledgebase)
2.use automatic configuration script: address: http://192.168.136.168/proxy.pac
3.manual settings:
proxy server: 192.168.136.168:800
bypass proxy server for local addresses
(proxy is not used if only hostname is used, but will be used domain name is used)
(e.g: http://intranet proxy will not be used)(http://intranet.mydomain.local proxy will be used)
(when an application is using a proxy the client will not do DNS lookup, it sends the request to the proxy and the proxy does the DNS lookup on client’s behalf)
(if client or application is not using a proxy or is behind the transparent proxy then it will definitely do DNS lookup and then send requests out to IP address)
(good for tshooting)

(mobile devices usually do not support automatic proxy settings)
(both android and iOS has proxy settings available in the wifi settings section)
(iOS supports proxy.pac files and is recommended to be used)
(android does not support proxy.pac file)(settings need to be manually defined)

(smoothwall can auto generate proxy.pac and wpad.dat files)(
(these files can be customised in the web proxy->automatic configurations section)(exceptions can be added and also regular expressions can be used)

(some non-web applications can use system proxy settings and some don’t have settings at all)
(commonly they don’t support any authentication methods other than the basic proxy authentication)
(thsoot is is difficult as no messages are generated)(use the transparent test proxy)

(when using a transparent proxy application may have some issues with https)(recommended to use non-transparent proxy)
(www.support.microsoft.com/kb/271361)

::::::6 Policy Objects::::::
1.Category Groups:
Guardian » Policy objects » Category groups:
(collection of blocked list categories)(categories and sub-categories)
(can be used for block or allow)
(it is a convenience feature, instead of adding individual categories, group of categories can be added)
advanced view to drill down each category to fine tune each category(5 components):
1.content filtering (dynamic content filtering)(dynamic content analysis)(phrase matches)
2.url pattern (/flashads)(/banner)
3.search filtering (block searches from searh engines)(google, bing, yahoo etc.)
4.flash filtering
5.domain/url filtering
e.g:
if a customer want to block sepecific gambling sites, but allow searching for gambling content
(simply tick the domain/url filtering and enter the sites and use it in a block policy)
e.g:
if a school want to block online flash games

2.User-Defined categories:
Guardian » Policy objects » User defined:
1.Search tool: (to see if the url is contained in a category)
2.Domains and URLs
3.Search term filtering
4.URL patterns
5.headers to override
6.File types
(custome (user-defined) categories can be found Guardian » Policy objects » Category groups->custom categories)
(custom allowed content and custom blocked content are builtin custom categories used for quick allow/block)
(swurl list also shows up in the custom category section here aswell as in the user-defined section)

3.Time slots:
Guardian » Policy objects » Time slots:
(to implement policies for certains days and time)

4.locations:
Guardian » Policy objects » Locations:
(single IP, hostnames, range of IP, subnet)
(used in web filter policies, different authentication methods based on the location of the client, location blocking and identification by location)
(Exceptions field can be used to add IPs in exceptions if you want it to exclude in the range of IPs mentioned above)

5.quotas:
Guardian » Policy objects » Quotas:
(limit access to specific content for a certain amount of time everyday)
(default qouta specified can not be removed, but can be edited)
(when default qouta is used user can have 1 hour qouta and will be prompted evry 10 mins)
(new qouta is created for specific users or user groups with duration, prompt and reset time)

6.user groups:
(retreived from the AD or directory connection)
(these are the security groups in AD mapped to the UTM groups)

:::::Web filter policies:::::
(policy enteries can be moved up and down to set the sequence and priority, as they are read from top to bottom)
(changing anything in the web filter, does not require restart of proxy)
1.Manage Policy:
2.Policy Wizard:
(first 4 steps are building the policies using the objects that we defined)
1.who:(users and groups)(you can select just one user aswell)
2.what: (category groups or user defined groups)(category groups/individual categories/swurls lists) (content modification categories are not used here)
3.where (location)(IPs, ranges of IP or subnet)
4.when (time rules to activate policy at specific times)
5.action:
block:
allow:
whitelist: (content modification is not performed on whitelisted)(software updates, iTunes or SSL/CRL whitelisting)
soft block: (will allow after pressing the continue button)
limit to quota: (specific mins or hours of usage/pre-defined time-slice)
create a policy folder:
who: network admin
what: blank
where: everywhere
when: always
action: create policy folder
(then click on the folder symbol in policies, but we can not change the who step as it has already been set)
(the policy will then have another policy embedded in it)

3.When designing a policy:
1.blocked polices first
2.then allow and whitelisted can be used to override unintented blocks
(it is advisable that allowed and whitelists are used as certain exceptions and not whole categories)
(but categories like Software Updates is used as a whole in a whitelist)
(software updates should go through the filter with no issues)
e.g:
whitelist software updates category for all
whitelist no authentication category for all
banned users group blocked everything
custom allowed content category for all (builtin category)(for quick allow section in guardian)
allows network administrators to download exe file types
core blocked content category group blocked for all
custom blocked content category group blocked for all (builtin category)(quick block)

4.Logs and reports » Realtime » System:
(will show you a message that web filter has received a reload signal is reloading the dynamic configuration)

5.Guardian » Web filter » Location blocking:
(to quickly and completely block a location)

6.Guardian » Web filter » Exceptions:
1.(to bypass the web proxy for specific devices i.e. src/dst IPs)
(i.e. will not be transparently intercepted by the web proxy)
2.(any IP address entered here will use port 801, thus will proxy the request, but will not authenticate or filter the request)
(to tshoot application on an IP if authentication or filtering issues)
(if the application from that IP works fine, then the issue will be authentication or filtering issue)
(A source exception IP, using a non-transparent connection, will have unfiltered access to the Internet if configured to use port 801. A source exception IP going through an interface where transparent proxy is enabled will not have outgoing HTTP or HTTPS traffic redirected to the proxy.)

::::::DNS Services:::::::
Services » DNS » Static DNS (will create entries on the host file)
(overrides public DNS lookups on the UTM system)
(can be useful when public DNS lookups points to an IP address either not avaiable from internal network locations or a host or domainname which will normally resolve to a public IP address needs to be resolved by the UTM system)

Services » DNS » DNS proxy (enables access to the DNS proxy on the enabled internal interface)
(DNS proxy is used, using the external DNS server set in the external connectivity profile, so resolving internal hostnames is normally not possible when using the DNS proxy)
(in general the internal clinets should be using the internal DNS, whereas the internal DNS should be using the DNS proxy as a forwarder to the external DNS)

Services » DNS » Dynamic DNS

:::::System Administration:::::
System » Administration » External access:
(to control admin access to the system services from an external or internal network)

System » Administration » Administrative users->Add user
(to create and edit the user account for administring the smoothwall system)
(e.g: create a user to run only the reports i.e. logs and real-time logs will be ticked)
(if we login as the user the UI will be restricted to logs and reports Menu)

:::::Important IPs, URLs and ports:::::
1. http://guardian:81 – web management interface
2. https://guardian:441 – web management interface
3. https://swurl.smoothwall.net/login -SWURL
4. https://192.168.56.99:442/login -SSL login page
5. http://192.168.110.1:81 -default IP and port for web interface after install
6. https://192.168.110.1:441 -default IP and port for web interface after install
7. http://v6.netexam.com – training videos (farzand.ali@smoothwall.net)
8. https://mail.google.com/mail/u/0/#inbox (google company emails)
9. http://www.chiark.greenend.org.uk/~sgtatham/putty/ (putty SSH terminal software)
10. http://download.smoothwall.net/support/ (to download teamviewer on client’s PC for remote session)
11. https://customer.smoothwall.net/download/ – to download the smoothwall software by entering the license
12. https://login.salesforce.com/ – salesforce CRM login (queues for all the cases -Triage queue and -support queue)
13. https://192.168.56.99:441 – test environment on firefox as a non-trans proxy
14. http://www.subnet-calculator.com/ (online subnet calculator)
15. http://www.tnhost.com/tools/k-kb-mb-gb-tb-conveter (calculator)
16. http://www.emergingthreats.net (IPS policies)
17. http://www.snort.org (to update IPS signatures)
18. http://winscp.net/eng/download.php (WinSCP tool for transfering files to and from smoothwall)

::::Troubleshooting tools, logs and reports::::
1. Dashboard
2.logs and reports->reports->summary (collection of reports)
3.system->diagnostics->configuration tests (Sanity check)
4.logs and reports->real time->system (real time system logs)
5.logs and reports->real time->web filter (real time web filter logs)
6.logs and reports->real time->firewall (real time firewall logs)
7.logs and reports->real time->traffic graphs (real time interfaces traffic)
8.system->diagnostics->traffic analysis (TCPDump)
9.system->diagnosics->IP tools (ping/traceroute)
10.system->diagnostics->diagnostics (diagnostics file)
11.guardian->quick links->policy tester (policy tester)
12.system->diagnostics->whois (whois)
13.guardian->policy objects->user defined (search tool to determine th category group)

::::updates and licenses:::::
1.system->maintenance->updates
2.system->maintenance->modules
3.system->maintenance->licenses

4.About link at the footer of every web interface page.

::::System backups and archives:::::
1.system->maintenance->archives
2.system->maintenance->scheduler

::::Different types of Policies set on smoothwall::::
1.Web filter policies.
2.HTTPS inspecion policies.
3.Content modification policies.
4.Anti-malware policies.
5.Block page polices.
6.Web proxy authentication policies.
7.Upstream proxy policies.
8.Message censor policies.
9.Networking outgoing policies.
10.Bandwidth limiting policies.
11.Central management policies.
12.IDS policies.
13.IPS policies.
14.External access Admin rules.
15.Ports and Port Group rules.

::::Policy Objects::::
1. (who) Users (i.e. user groups) (retrived from active directory connections)
2. (what) category groups (pre-defined/built-in) or user-defined categories (custom category) or swurl
3. (when) time-slots
4. (where) locations
5. (action) Allow, block, Quotas etc.

 

:::::Linux Commands (Debian)/CLI Tools (SSH client – Putty/port 222/root user login)::::

#ifconfig (all active network interfaces and some interface statistics)(add or change IP addresses)

#clear (to clear the screen)

#ping 192.168.1.1

#traceroute 192.168.1.1

#reboot

#ethtool ethA (for example to change the MTU size on the fly for testing purposes)

#setup (to change the default interface or changing the interface IPs etc)

#tcpdump -nqi ethA port 80 (will list all the packets ariving at ethA interface for port 80)
(you can listen-in on any interface to see if the traffic is going to and fro)

#tcpdump -nqi ethA -s 0 -w /root/dump.pcap (to capture the traffic for analysing it in wireshark)(use WinSCP to browse files)
(-s switch sets no limitation on the size of the packet recorded)
(-w shows the file where the information is saved)
(use WinSCP to browse the file in the under the root directory on smoothwall system)
:Transfer file to and from the UTM system:
WinSCP tool
http://winscp.net/eng/download.php
UTM has builtin SCP tool
#scp -P 222 /root/dump.pcap root@smoothwall.ip.address:/root/
#tail -f /var/log/messages-2014-12-24 (shows the last 10 enteries in the system logs and replaces when new lines are added to it)
(sort of real time logs viewer for last 10 lines)

#grep monitor /var/log/messages-2014-12-24 (seraches for all the occurances of a specific string)

#cat /var/log/messages-2014-12-24 (to list the contents of the whole file)

#cat /var/log/messages-2014-12-24 | grep monitor > /root/monitor.txt (to list the contents of the whole file with monitor string)

#cat /var/log/messages-2014-12-24 | grep monitor | wc -l (tells the number of occurences of monitor string)

#less /var/log/messages-2014-12-24 (to list the contents of the whole file)

#top (resource usage and running processes)
(uptime and the load average)
(CPU usage: us for users, sy for system and ni for nice processes)(id is idle time, wa is wait state)
(if the wa is high that means the smoothwall is busy with extensive logs or reports)

#htop (resource usage and running processes)(same as top but better layout)

#vmstat (summary information for system load and usage, but does not show individual processes)

#ps aux (display all processes running on the UTM system)(to search for specific processes or list them all)

#ps aux | grep auth (all the processes that have auth in them)

#ps auxf | sort -nr -k 4 | head -10 (shows the top 10 memory consuming processes)

#cat /proc/cpuinfo (lot of information about the system and the hardware associated)

#cat /proc/meminfo (information on meemory and memory usage)

#cat /proc/mounts (various file systems and where they are mounted and which options have been used)

:to see many services running:
#/etc/actions/secondboot

:to disable ‘navld’ process/L7 depp packet inspection process(as after update 73 the process CPU usage shows high):
#cd /etc/actions/secondboot
#chmod -x 0095navld

:to restart the central monitor service i.e. nagios that shows up on the dashboard:
#/etc/actions/secondboot/nagios
:to see the system logs on CLI for a particular date:
#less /var/log/messages-2014-05-24

:to see the Email and web filter logs on CLI for a particular date:
#less /var/log/woodshed-2014-05-24
:::MS-DOS commands::::
c:/>ipconfig
c:/>tracert
c:/>ping

:::::Hardware failover:::::
(two UTM devices as a hardware failover pair)
(essential in a high avaiability environment)
(Master system – active state
failover system – passive state)
(these two devices communicate using the heartbeat interface)
(all configuration changes made on the master system gets replicated to the failover system)
(if the master system fails, the failover unit changes the state from the passive state to the
active state and takes over the IP addresses and connections from the master and continue where the master left off)
(the failover unit now in active state sends a broadcast to clear the ARP cahce on the switches)
(failover process takes less than 30 seconds before all the services are active depending on the amount of services that need to startup)
(network connectivity is restored within 10-15 seconds)

:managing and maintaining hardware failover is important:
(master can be shut and the failover unit can perform all the updates and then master can be restarted and the failover unit will fail back to master unit)
(this updates the failover unit, performs the failover test and also thefailback to master)
master unit can be accessed by the web interface IP address i.e.
http://192.168.110.1:81
https://192.168.110.1:441

failover unit will not have any active web interface except for the active heartbeat interface.
https://192.168.110.1:440 (sent to the master system and then proxies it and sent to the hearbeat interface)
Warning: shows that it is a failover unit (slave heartneat system) and the when was the last time the settings were copied over from the master unit.

if we want to connect to the CLI of the failover unit, we will have to SSH to he master first and then:
#ssh -p 222 root@10.99.0.2 (where 10.99.0.2 is the heartbeat interface)

:Recommended process:
1. first check all the updates are downloded on the master.
System » Maintenance » Updates-> refresh updates list -> download updates
(within 5 mins all the downloaded updates will transfer to the failover unit)
2. access the GUI of the failover unit using the port 440 and check if all the updates are downloaded
3. install all the avaiable updates on the failover unit.
4. perform a reboot of the failover unit. (should not interfere in the traffic as it is the failover unit)
5. we can then check the master’s system logs to see if the failoer unit is back and has joined as a failover unit.
6. now perform failover test:
first install all the updates which were downloaded on the master system.
7. we won’t reboot, but the master should go into standby mode to test the failover:
System » Hardware » Failover-> enter standby mode
8. after 30 seconds if you try to connect to the web intrerface it will be connected to the failover unit automatically.
9. now the failover unit is active, we need to use the port 440, to connect to the master passive system.
10. so reboot the master. when the master is back the failover will go to the passive status and the master to the active status.
11. wait 3 mins in order for the reboot to occur. then try the web interface login again and you will be connected to the master unit.
(failover pair should be tested regularly)
(split brain syndrome which makes both the systems think that they should be the active systems, it happens when the
connection between the two units has broken somehow)(disconnect everything on the failover unit except for the heartbeat interface)
(try rebooting the failover unit and it should come back to the passive state, if the issue was temporary)
(you can reboot the failover unit through the console CLI connection or the CLI through SSH from the master to the failover unit)
(use ifconfig to see the active interfaces on the failover unit)(only the heartbeat interface, loopback interface and the GRE interface in some cases should be active)
(also check the master system logs)
(simplest way to test the failover is to shutdown the master and failover unit becomes the active device)
(power on the master and then refresh the admin GUI, which shows the failback works)

::::::Hardware failover pair setup(planning deployment and installation)::::::
(one interface is used as a dedicated interface, which is the heartbeat interface)
1.install and configure the master system.
2.enable the hearbeat on the interface: Networking » Interfaces » Interfaces ( no need to restart the networking)
3.Enable SSH: System » Administration » Admin options
4.System » Hardware » Failover->Heartbeat:
Enable: ticked
auto failback: ticked
Keep-alive internal: passive system keeps checking if the active system is available
Dead time: how much time to wait to failover, when the active system goes down
Master heartbeat IP:
Slave heartbeat IP:
Netmask: these IPs shouldn’t be in use in the network anywhere.
5.Reboot: System » Maintenance » Shutdown->reboot
6.Generate failover archive: System » Hardware » Failover (also has recent updates)
(System » Maintenance » Updates->clear cache)(as the archive shouldn’t be more than 100MB)
7.boot the failover unit and install the updates same as the master system.
8.only cable the heartbeat interface.
9.install the archive on the failover unit using the #setup command -> restore configuration
(put the archive on a usb or CD and install it on the failover unit)
(it will setup the failover unit and the interfaces)
10.check the master logs: Logs and reports » Realtime » System->heartbeat (shows the failover unit is up)
11.failover unit’s web interface is accessed by using master’s IP but using the 440 port number.
(master redirects the traffic to go over the hearbeat interface)
Warning: shows that it is a failover unit (slave heartneat system) and the when was the last time the settings were copied over from the master unit.
12. if we want to connect to the CLI of the failover unit, we will have to SSH to he master first and then:
#ssh -p 222 root@10.99.0.2 (where 10.99.0.2 is the heartbeat interface)
13.connect the failover unit to the internal and external networks.(a switch may be required between the UTM units and the router to the IPS, so both units can access the router)
14. we won’t reboot, but the master should go into standby mode to test the failover:
System » Hardware » Failover-> enter standby mode
15. after 30 seconds if you try to connect to the web intrerface it will be connected to the failover unit automatically.
16. now the failover unit is active, we need to use the port 440, to connect to the master passive system.
17. failback(preemptive): so reboot the master. when the master is back the failover will go to the passive status and the master to the active status.
18. wait 3 mins in order for the reboot to occur. then try the web interface login again and you will be connected to the master unit.
(failover pair should be tested regularly)

:if the failover fails:
1.check the list of active interfaces on the master system. #ifconfig (ethA, ethB, ethC and ethD all are active)
2.check the list of active interfaces on the failvoer unit. #ifconfig (only the hearbeat interface should be active)
3.try pinging the heartbeat interface from the master to the failover unit, especially when the failover unit (ifconfig) shows the heartbeat interface as active.
if this happens then the cable is faulty.
(this is easy to diagnose and identify in the appliances, when using a 3rd party system, it is better to move the physical cable to other interface on the failover unit.
then keep pinging from the master unit to the heartbeat interface of the failover unit, and it will come up at some point)
4.issue the reboot command on the failover unit and check the realtime system logs on the master to see if the heartbeat interface is back up.
5.if there is a problem with the failvoer unit archive, simply generate another archive from the master unit.
6.if the failover unit stops working and need to be replaced, it is simply setting up a new failover unit (i.e. generate an archive from the master and setup failover unit)
7.if the master system stops working and need replacing:
1.simply make the failvoer unit to the master now and then setup a new failvoer unit.
connect to the CLI of the failover unit.
#rm /var/hearbeat/settings.tar.gz (remove this file: y)
#echo master>/etc/ha.d/nodeinfo (change slave strings to master in this file)
this will make failover unit into the master and the we can generate failover archive to setup a new failover unit
2.or setup a new master using the backup archive not the failover archive.

http://www.youtube.com/watch?v=a97lW680hFM

 

::::3 types of VPN::::
1.IPSec
2.L2TP
3.SSL

::::2 ways to connect VPNs::::
1.subnets i.e. site to site
2.roadwarrior i.e. client to site/remote access vpn

::::4 options on smoothwall for VPNs::::
1.IPSec subnets (for site to site vpn)
2.IPSec roadwarrior (for client to site/remote access vpn)(windows/MacOSX/linux)
3.L2TP roadwarrior (for client to site/remote access vpn)(windows/iOS/Android)
4.SSL roadwarrior/OpenVPN (for client to site/remote access vpn)
(grant access to local network to individual users)
(based on OpenVPN)(need OpenVPN client software installed on the machine)
(windows/MacOSX/linux/Android/iOS)
(this is the widely used VPN)
(integrated with the AD and user login using the directory credentials)
(SSL VPN is the most appropriate solution if more than 10 clients use VPN service as L2TP and IPSec requires manual setup)

::::SSL VPN Server Setup::::
(smoothwall uses certificates for identification and security purposes)
(e.g. CAs are VeriSign or GlobalSign)

1. create a self-signed CA. (VPN » VPN » Certificate authorities)
(only one CA is required to generate all the certificates. So only one device can be used to generate certificates for all)
2. cretae a self-signed certificate for OpenVPN. (ID type and ID value) (VPN » VPN » Certificates)
(3 ID types: 1.host and domain(FQDN) 2.IP address 3.email address(user FQDN))
(use host and domain name type)
(follow naming convention in your environment)
3. set the newly created certificate as the default local certificate for smoothwall (VPN » VPN » Global)
4. SSL VPN settings
Enable SSL VPN:
transport protocol: TCP(HTTPS)(port 443 can not have any port forwards on the primary IP)
SSL VPN network address: (virtual network)
(SSL VPN has a virtual network setup, whereas all other types of VPN gets the IP from the local LAN)
(setting the DNS is very important in case of SSL VPN as clients don’t get an IP inside the LAN and accessing resources is not possible unless configured)
(also setup zone bridging rule for SSL VPN to access the internal resources)
Enable SSL VPN:
Force clients to use SSL VPN as gateway: (to filter all openvpn client traffic)
SSL VPN client gateway(s): (If the UTM firewall is behind another firewall)
5. L2TP and SSL VPN client configuration settings
Primary and seconary DNS: (internal DNS server)
6. save and then restart.
7. Now the SSL VPN server will be ready to accept incoming client VPN connections.
8. Generate client archive – (all config files and windows OpenVPN client downloaded)
(need admin privileges on windows system to install this client)
9. Open the OpenVPN client and connect.
(users are authenticated using the AD connection or through local user database if no AD user is detected)
(tunnelblick on MacOSX and Linux can also use these configuration files)(https://code.google.com/p/tunnelblick/)
(OpenVPN client on iOS and Android can also use these config files)
10. check if the user is allowed to connect at all. (VPN » VPN » SSL roadwarriors)
(by default all the groups should be allowed to connect)
(select group->untick enable under SSL VPN group settings->save)
11. to allow accedd to the OpenVPN clients to the resources that the user can access on the local network.
(Networking » Filtering » Zone bridging)
source interface: SSL VPN
destination interface: e.g. port1-LAN
src/dst IP
service/port
(add)
12. any issues connecting OpenVPN logs on the client and the smoothwall will give indication of the issue.
(RealTime- Logs and reports » Realtime » System -> section->SSL VPN)
(Static- Logs and reports » Logs » System-> section->SSL VPN)
13. to check the active VPN connections.
(VPN » VPN » Control->SSL road warriors)
(roadwarrior connections can be disconnected using this control, but the client need to connect themselves)

(can also be used to restart the whole VPN engine)(VPN » VPN » Control->Manual control->restart)

::::IPSec VPN (site to site VPN)::::
(e.g. connecting main office to the branch office)

1. create a self-signed CA. (VPN » VPN » Certificate authorities)
(only one CA is required to generate all the certificates. So only one device can be used to generate certificates for all)
2. cretae a self-signed certificate for IPSec VPN. (ID type and ID value) (VPN » VPN » Certificates)
(3 ID types: 1.host and domain(FQDN) 2.IP address 3.email address(user FQDN))
(use host and domain for IPSec tunnel) (does not have to be a registered domain name)
(follow naming convention in your environment)
(crete one certificate for main office and the other for branch office)
(hub.vpn.test and branch01.vpn.test)
3. set the newly created certificate as the default local certificate for smoothwall (VPN » VPN » Global)
(e.g. the main Hub VPN)
4. save and then restart.
5. Create a Tunnnel on the main office:
(VPN » VPN » IPSec subnets)
Name: Tunnel to Branch01
Enabled: ticked
Local IP: is the external IP by default. blank by default. 1.1.1.3
Local network: (192.168.2.0/24)(network to tunnel data from)(or supernetting 192.168.0.0/16)(or create multiple tunnels)
Local ID type: default local certificate ID
Local ID value:
Remote IP or hostname (blank for ANY): 1.1.1.4
Remote network: 192.168.4.0/24
Remote ID type: user specified host and domain name
Remote ID value: branch01.vpn.test
Authenticate by: (certificate presented by the peer)
Initiate the connection: ticked (not the case in case of behing the NAT)
(add)
6. Export the CA in pem file format:
(VPN » VPN » Certificate authorities)
7. Export the certificate in pem file format:
(VPN » VPN » Certificates)
(enter password)
(export certificate and key as PKCS#12)
(contains both public and private keys)
8. Import CA created on the main UTM CA to the branch office UTM:
(VPN » VPN » Certificate authorities)
(it will not be marked as a local CA)
9. Import certificate created on the main UTM CA to the branch office UTM:
(VPN » VPN » Certificates)
(it will not be marked as a local CA)
10. set the newly imported certificate as the default local certificate for smoothwall (VPN » VPN » Global)

11. save and restart.

12. Create a Tunnnel on the branch office:
(VPN » VPN » IPSec subnets)
Name: Tunnel to main office
Enabled: ticked
Local IP: is the external IP by default. blank by deafult. 1.1.1.4
Local network: 192.168.4.0/24 (network to tunnel data from)(192.168.2.0/24)(or supernetting 192.168.0.0/16)(or create multiple tunnels)
Local ID type: default local certificate ID
Local ID value:
Remote IP or hostname (blank for ANY): 1.1.1.3
Remote network: 192.168.2.0/24
Remote ID type: user specified host and domain name
Remote ID value: hub.vpn.test
Authenticate by: (certificate presented by the peer)
Initiate the connection: ticked (not the case in case of behing the NAT)
(add)
13. Bring up the tunnel:
(VPN » VPN » Control->Manual control->Running(green))
(VPN » VPN » Control)(IPSec subnets->up->Open(green))
14.Now configure network access rules:
(Networking » Filtering » Zone bridging)
15. check the logs for any problems on the main office UTM:
(2 phases to complete in the tunnel)
(phase 1 is for IKE(Identity Key exchange) – manage the initial contact and identity exchange)
(starts from initiating main mode and finishes at ISAKMP SA established)
(phase 2 is IPSec phase, where the routing is sorted out and the tunnel is established)
(starts from the Quick mode, then tunnel negotiation and then finishes at IPSec SA established)
(Logs and reports » Realtime » IPSec)

16. check the logs for any problems on the branch office UTM:
(2 phases to complete in the tunnel)
(phase 1 is for IKE(Identity Key exchange) – manage the initial contact and identity exchange)
(responds to the main mode and finishes at ISAKMP SA established)
(phase 2 is IPSec phase, where the routing is sorted out and the tunnel is established)
(responds to the Quick mode, then tunnel negotiation and then finishes at IPSec SA established)
(Logs and reports » Realtime » IPSec)

(in case of a 3rd party device in the branch office advanced option is used)
(VPN » VPN » IPSec subnets)(3rd party can support multiple proposals)
Local certificate:
Interface:
Perfect forward secrecy: ticked / DH(diffie hellman)
Authentication type: ESP(encapsulating security payload)
Phase 1 cryptographic algo: 3DES/AES 128/AES 256
Phase 1 hash algo: MD5/SHA
Phase 2 cryptographic algo: 3DES/AES 128/AES 256
Phase 2 hash algo: MD5/SHA
Key Life (mins): (do not have to match on the peer. ho wmany times to renegotiate the tunnel)
Key Tries (0 means never give up): (attempts to bring up the tunnel if down)
Do not rekey: unticked (used if behind NAT)
Local internal IP:

(multiple locations and subnets ipsec vpn need a proper routing plan)
(same subnets used in to locations traffic can not be routed)
(multiple subnets can not be added to the same tunnel config, but separate tunnels can be created with different subnets)

::::L2TP roadwarrior::::
(requires a certificate for each client and a static IP allocated to the connection)

1. Create a certificate:
VPN » VPN » Certificates
(the only difference while creating the certificate is to set the ID type as the email address and the ID value as the email address)
(easy to identify which certificate was created for which user)
2. export the CA and the certificate and import them on the client.
3. check the settings in the global area:
VPN » VPN » Global->L2TP and SSL VPN client configuration settings-> primary and secondary DNS
L2TP settings->L2TP client internal interface:
4. setup a new connection for the user:
VPN » VPN » L2TP roadwarriors-> Create new tunnel
Name:
Enabled:
Client IP: (IP that the client will be receiving when the client connects)
username:
password:
Authenticate by: (select the certificate we created)
L2TP client OS: Microsoft
Local certificate: default
Interface: primary (expect the incoming connection on the primary external connection)
5. L2TP wizard application on windows can be downloaded from the smoothwall’s website:
6. run L2TP wizard as an admin:
CA.pem and ertificate.p12
IP address->username and password
(multiple users can not connect if they are coming from the same IP address)
(we can use pre-shared key instead of the certificate for L2TP e.g mobile devices)