MultiCom Firewall Samples

These samples have been designed to highlight major features of the Lightning-Linux Operating System.  

• Standard Configurations have examples of all standard features in Lightning Linux 3.5

• IPSec Configurations require the IPSec option to access IPSec features

• Feature Guide is a table of all of the examples and the features activated in them

• Sample Security Configuration File is used when a Security option has been activated on the MultiCom Firewall (IPSec, SSH Port Forwarding, High Availability)

To use these configurations, either load them into the Configurator software or load them directly into a MultiCom Firewall using a web browser http://10.0.0.1/advanced/config/upload/ (where 10.0.0.1 is the LAN interface of the MultiCom Firewall.)  You may not be able to load the configuration IPSec or SSH examples into a MultiCom Firewall that does not have those options activated.

The 3.6 Configurator includes a new feature called IMPORT.  This allows you to import configuration files designed for one type of MultiCom Firewall into a different type of MultiCom Firewall (for example importing a configuration for an Enterprise unit into a SpeedSurf.)  See the Reference Manual for a full explanation of this new feature.

If you experience any problems using these configurations please contact support@lightning.ch

WARNING - These configurations were designed to highlight the features of Lightning-Linux.  They are not meant to be used for production environments without customizing them to meet your specific needs.

Standard Configurations

EXAMPLE 1 Port Mapping, Interfaces

With SecureWall activated, map selected services through to a single internal server.  Normal outbound Internet services are available from LAN to WAN.

WAN: DHCP Client	LAN: 10.0.0.1/8
	server	10.0.0.3

Using Network Address Translation http, ftp, and telnet services are allowed to pass the SecureWall and are redirected to an internal server. 

NOTE - because Interface NAT only works on the configured interface queries from the LAN to external or publicly known IP Address (WAN interface) requesting these services will not be translated.  Unless you activate the DNS server to resolve your domain name to the internal servers, computers on the LAN must use the actual LAN server IP address.  Other samples will overcome this if desired.

EXAMPLE 2 1:1 Passthrough

Bypass the SecureWall by using Network Address Translation to redirect all traffic arriving at the WAN interface to be redirected to a single internal computer.

WAN: DHCP Client	LAN: 10.0.0.1/8
	server	10.0.0.3

This may be useful when it is suspected that some network services are being blocked by the SecureWall, NAT or the ports the software needs are unknown.  Security will have to be done by using Stateful Filtering rules if desired.  

The NAT of the MultiCom Firewall will still allow Single User Internet Access to the Internet.  It is intelligent enough to know the difference between responses to LAN web requests and traffic that is new and incoming on the WAN.  It is the latter, the new incoming traffic to the WAN interface which is redirected to the internal server.  LAN NAT services can be activated but are not required for this, however WAN NAT must be activated.

NOTE - with this configuration you can ping the box on the internal network which will show up as a double response on a traceroute where normally there is only one response from the WAN interface.  (in this case both the WAN interface and the internal server are responding to the Ping.)  

EXAMPLE 3 Port Mapping, Global

Allow access from both the WAN and the LAN to an internal webserver, using SecureWall and  protection. 

WAN: 192.168.0.1/24	LAN:10.0.0.1/8
	web server	10.0.0.3

Additionally all users full access to the Internet.  Both the WAN and LAN can reach the internal webserver by using the external or publicly known IP Address (WAN interface).   Change the static IP address in the NAT>Global table as needed.   Any rules in the Global NAT table will be applied to each interface with NAT activated.   

NOTE -be sure to activate NAT on the LAN interface or it will not reach the internal web server.  Also, using the Global  NAT table requires the use of known IP addresses or else all Web traffic will be redirected to the internal server (including all external web requests from the LAN).  

WARNING - When the NAT is activated on the LAN all traffic passing into the LAN network will appear to come from the LAN interface.  Because of this it is recommended to use the built-in DNS server to redirect the traffic by the domain name and turn NAT off for the LAN interface.

EXAMPLE 4 Port Mapping, Custom

Using Global NAT redirect different ports to the same internal webserver, accessible from LAN or WAN and using SecureWall and Object Filtering protection.

WAN: 192.168.0.1/24	LAN:10.0.0.1/8
	web server	10.0.0.3

Similar to the above configuration except that it additionally resolves a 2nd port 8888 to the web server on the LAN and uses Object Filtering for an additional level of security.  This is useful to show how other ports can be used to provide external services such as mail or web that would not be regular targets to Security attacks.  Using the Global NAT table allows you to create NAT rules that will work on any interface that has NAT activated.

NOTE -be sure to activate NAT on the LAN interface or it will not reach the internal web server.  Also, using the Global  NAT table requires the use of known IP addresses or else all Web traffic will be redirected to the internal server (including all external web requests from the LAN).  

WARNING - When the NAT is activated on the LAN all traffic passing into the LAN network will appear to come from the LAN interface.  Because of this it is recommended to use the built-in DNS server to redirect the traffic by the domain name and turn NAT off for the LAN interface.

EXAMPLE 5 Syslog & SNMP

Activate Syslog reporting and enable SNMP MIB browsing from the LAN to a normal Single Internet User configuration.

WAN: DHCP Client	LAN:10.0.0.1/8
	syslog server	10.0.0.2

Enable Syslog reporting to the specified IP address as well as activating SNMP browsing from the 10.0.0.0/8 subnet .  Syslog in particular is the best  way to get activity output and debug information from the MultiCom devices.  SNMP is a good way to see the status of interfaces and statistics on the network traffic passing through the Firewall.  Optionally you can see the internal Event Log from the built-in web server or by using the Monitor software, however the details are limited.  

The Configurator and Monitor software has a limited Syslog software to receive Syslog messages during debugging.  Freeware and shareware Syslog and SNMP software is available on the MultiCom Companion CD. 

EXAMPLE 6 Object Filtering, Incoming

NAT all traffic to an internal server and use Object Filtering to limit which services are allowed to come in (http, telnet, and ftp). 

WAN: DHCP Client	LAN:10.0.0.1/8
	server	10.0.0.3

All other services will be blocked from the WAN although no services are blocked from being requested by the LAN from the Internet.  Also special input rule (Input>Filter) saying that if anyone other than from 10.0.0.0/8 subnet tries to access the MultiCom webserver/telnet the packet will be dropped.

NOTE - using "WAN Interfaces" in Object filtering is necessary when using PPP connections on the WAN interface.  For instance, when using PPPoE on the WAN, the WAN interface is disabled and any rules associated just to the WAN interface would never be activated since the traffic is now over the PPPoE interface.

WARNING - with SecureWall turned off a request from the WAN which arrives with a destination address corresponding to an internal PC can pass through the firewall unless it is blocked by a Stateful Filtering rule.  Although it should not be possible to route private subnets over the Internet it is recommended to use the SecureWall to protect your internal network.

EXAMPLE 7 Object Filtering, Outgoing

Limit services available from the LAN to the Internet (WAN) and log other service requests.

WAN: DHCP Client	LAN:10.0.0.1/8
	syslog server	10.0.0.2

This is a sample of using both the Stateful Filtering firewall and the SecureWall.  Filtering can limit users access to the Internet and log important activity using Syslog and the Object Filtering has a default of allowing no WAN traffic to pass.

WARNING - Object Filtering only applies to traffic trying to go through the MultiCom Firewall and not directly at it.  Access attempts to reach the Firewall's built in webserver, telnet server or to simply ping the WAN interface will NOT be blocked by the the Object Filtering rules.  Only activating the SecureWall, using the Filter Input/ Output tables, or using NAT to redirect incoming traffic can block external access to the device itself.

EXAMPLE 8 Filtering, Advanced

Block and log pings from the WAN to the Firewall itself but allow pings from the LAN.

WAN: DHCP Client	LAN:10.0.0.1/8
	syslog server	10.0.0.2

Using Input>Filter rules, only pings from the LAN network are allowed through the Stateful Firewall, all other ping requests are dropped.  Otherwise, even with the SecureWall activated, pings will be replied to from all interfaces.  

EXAMPLE 9 Standard Filters

Activate default filter security rules for a home network.

WAN: DHCP Client

LAN:10.0.0.1/8

Using the Configurator's Wizard menu just select Standard Filters.  This activates the default security rules providing protection from

• NetBIOS Broadcasts
• Spoofing
• Denial of Service
• Incorrect TCP flags
• Active FTP
• Aureate Spyware

EXAMPLE 10 Load Sharing with NAT

Activate simple load sharing between multiple internal webservers.

WAN: DHCP Client	LAN:10.0.0.1/8
	mirrored web servers	10.0.0.2-10.0.0.6

This distributes the request for web services from the WAN interface to 1 of 5 different webservers using a Round Robin approach.  Once a connection has been started to one webserver that session will continue on the same webserver.

EXAMPLE 11 Virtual IP

Configure multiple incoming Virtual IP addresses to be completely redirected to different internal servers.

WAN: DHCP Client	LAN:10.0.0.1/8
	web servers	10.0.0.2
		10.0.0.3
		10.0.0.4

This redirects all data requests for the specified IP addresses to be redirected to different internal servers.  Use of Proxy ARP is required by ISP's that cannot change their own routing tables to redirect the other IP's through the IP address of the WAN interface.  Additionally, remapping of outgoing data is done so that it has the expected source IP address (in case of remote firewalls or special software requiring this).

NOTE - The LAN interface must have NAT activated if it will redirect LAN requests to the same servers.   Internal servers must have their default gateway configured to use the LAN interface of the Firewall.  Optionally you can activate NAT on the LAN interface activated to make all traffic look like it is coming from the LAN.  This allows all responses to go directly to the connected LAN interface.

EXAMPLE 12 Virtual IP & Port Mapping

Configure multiple incoming Virtual IP addresses for web access to be redirected to the same web server but to different port numbers on that server.

WAN: DHCP Client	LAN:10.0.0.1/8
	web server	10.0.0.3:80
		10.0.0.3:81
		10.0.0.3:82

This is the same as Example 11 except that it redirects the 3 IP addresses to different ports on the same server.  Use of Proxy ARP is required by ISP's that cannot change their own routing tables to redirect the other IP's through the IP address of the WAN interface.  Additionally, remapping of outgoing data is done so that it has the expected source IP address (in case of remote firewalls or special software requiring this).

NOTE - If this traffic was going to the same IP address and same port number there would be no way to identify returning traffic and remap it to appear from the requested source IP address.  If this is needed you must use separate ports or servers to receive the different IP addresses.  

EXAMPLE 13 DHCP Proxy

Activate remote DHCP proxy

WAN: 192.168.0.1/24

LAN:10.0.0.1/8

Replace 192.168.0.2 with IP address of an actual remote DHCP/BootP server to be relayed.  Requests for DHCP configuration from the LAN will be redirected to the remote DHCP server.

NOTE - This requires advanced configuration of the remote DHCP server to support DHCP relay.  

EXAMPLE 14 Transparent Redirection

Use Squid to transparently proxy HTTP requests on an Ethernet III.

WAN: DHCP Client	LAN:10.0.0.1/8	DMZ:11.0.0.1/8
		web proxy	11.0.0.2:8888

All traffic with a destination port of 80 (standard http/ web traffic) will be redirected instead to proxy server.  The proxy server must be configured to support the transparent proxy request and its requests for web traffic are allowed.  Optionally, limiting the LAN users access to other services on the Internet using Object Filtering may be desired to maximize control of the data traffic.  The Firewall webserver however can be reached at port 8080.

NOTE - Squid  is not configured out of the box to support transparent proxying.  In section 17 of the Squid FAQ there is description of using Squid in this capacity (please read this and the squid.conf file - httpd_acceleration for a full explanation of what the following code is doing.)

http_port 8888
httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_accel_uses_host_header on

EXAMPLE 15

Training configuration with many features activated/ available.  More documentation to come.

SCREENSHOTS Example

This was the example used to populate the screenshots that are included in the Manual.  It is not a working configuration.  It was designed for the Enterprise ADSL unit. 

VPN Configurations (IPSec Option needed) 

IPSEC & SSH basic

If you load this configuration you can see the IPSec & SSH VPN panels of the Configurator software. 

You will still need a MultiCom Firewall with the IPSec option activated to use any configuration that you wish to activate.  This configuration is included solely for allowing access to see the IPSec window of the Configurator software.  Statistics concerning the connections can be seen using the built-in web server of the MultiCom Firewall or using the Monitoring software included on the MultiCom Companion CD.

Don't forget that there is the New IPSec Tunnel wizard in the Configurator 3.5 and greater.  This is the easiest way to build IPSec tunnels.) 

NOTE - These configurations use Preshared keys to authenticate the IPSec connection.  For information on using PKI Certificates refer to the PKI x.509 Certificates section in the IPSec Chapter. 

Status of IPSec connections can be found at http://10.0.0.1/status/ipsec/ where 10.0.0.1 is the IP address of the MultiCom Firewall.

EXAMPLE 20a & 20b IPSec Tunnel

Configure a MultiCom with IPSec to create an encrypted tunnel bewteen 2 subnets.  (IPSec Option needed) 

WANa: 192.168.0.1/24	LANa:10.0.0.1/8
WANb: 192.168.0.2/24	LANb:11.0.0.1/8

Create a key named "secret" with value "secret" and no endpoints defined in key.

All data coming from 10.0.0.0/8 and going to 11.0.0.0/8 will be encrypted via a IPSec in tunnel mode over a network.  All other communication from the MultiCom is blocked by object filtering except configuration access from the LAN. 

NOTE - to reach the remote MultiCom device you will need to access it via the LAN interfaces on the remote subnet since all other (non-encrypted) communication is being blocked.

EXAMPLE 21 IPSec Roadwarrior Gateway

Configure an unknown endpoint connecting to the LAN using IPSec in Tunnel mode, with normal Internet access. (IPSec Option needed) 

WANa: 192.168.0.1/24	LANa:10.0.0.1/8
WANb: unknown	LANb: 11.0.0.0/8

Create a key named "secret" with value "secret" and no endpoints defined in key.  This provides access to the internal network from a remote, unknown IP address (Roadwarrior).  For instance the person may be using a laptop with an IPSec client software from a bluetooth cellphone with a dynamic IP address or have another MultiCom Firewall at home with a dynamic PPPoE account.  Access to the MultiCom itself is possible through the IP address of the LAN interface and Stateful Filtering rules will still apply.  

Because SecureWall is activated, rules must be added to allow the MultiCom Firewall to receive the IPSec traffic (IKE UDP 500, as well as ESP and AH protocols, UDP4500 for NAT Traversal.)  Additionally NAT Traversal has been enabled in case the incoming Roadwarrior is behind a NAT device.

NOTE - Internet Service will proceed normally but the tunnel will only be opened when it is requested from the Roadwarrior (because the MultiCom does not know the IP address that the Roadwarrior will be on until the Roadwarrior tries to connect).   Roadwarrior configurations must be using the same Preshared Key (PSK) or PKI Certificates.

Additionally, the internal computers must have either

• a default route through the MultiCom Firewall (typical),
• a static route directing traffic to the remote network through the MultiCom or
• NAT must be activated on the LAN interface to make the traffic appear to be coming from the LAN interface itself.

EXAMPLE 22a & 22b IPSec Tunnel with Internet Sharing

Configure a MultiCom with NAT and IPSec to create an encrypted link between 2 subnets while using NAT to provide Internet access. (IPSec Option needed) 

WANa: 192.168.0.1/24	LANa:10.0.0.1/8
WANb: 192.168.0.2/24	LANb:11.0.0.1/8

Create a key key named "secret" with value "secret" and no endpoints defined in key.  All data coming from 10.0.0.0/8 and going to 11.0.0.0/8 will be encrypted via a tunnel over a network.  Traffic with a destination of the remote network does not receive Network Address Translation (as configured on the WAN Interface NAT Output table).  Routes for the remote subnets will be added automatically on the MultiCom Firewall once the configuration is activated.  All other communication through the MultiCom uses the Single Internet User account configuration of the Firewall to allow unencrypted Internet access.  

The Dead Peer Detection is activated on both sides of the connection.  At 2 minute intervals each MultiCom checks if the other side of the tunnel is responding.  This allows for reconnection attempts of tunnels that have closed.  Otherwise the tunnel will stay active according to the IKE & SA proposal settings.

NOTE - to securely reach the remote MultiCom device you will need to access it via the LAN interfaces on the remote subnet since SecureWall otherwise blocks the incoming traffic on the WAN.  Optionally you could open ports on the SecureWall and redirect them directly to the Firewall for remote configuration using HTTPS.

EXAMPLE 23 IPSec Point-to-Point Roadwarrior and Internet Sharing

Configure an unknown endpoint to connect to selected LAN services (http, telnet) using IPSec in Transport mode.  (IPSec Option needed) 

WANa: 192.168.0.1/24	LANa:10.0.0.1/8
WANb: unknown

Also create a key named "Secret" with value "secret" and no endpoints defined in key.  Using transport mode provides security right up to the connected interface on the MultiCom Firewall (in this case the WAN interface).  This is useful to reach a MultiCom Firewall for configuration or passing Syslog/ SNMP data.  Other traffic will not be able to get through or reach the same services on the MultiCom Firewall because the SecureWall is blocking all other traffic.  

EXAMPLE 24 IPSec Point-to-Point and Internet Sharing

Configure an unknown endpoint to connect to selected LAN services (http, telnet) using IPSec in Transport mode and allow outgoing unencrypted Internet traffic. (IPSec Option needed) 

WANa: 192.168.0.1	LANa:10.0.0.1/8
WANb: 192.168.0.2

Also create a key named "Secret" with value "secret" and no endpoints defined in key.  Using transport mode provides security right up to the connected interface on the MultiCom Firewall (in this case the WAN interface).  This is useful to reach a MultiCom Firewall for configuration or passing Syslog/ SNMP data.  Other traffic will not be able to get through or reach the same services on the MultiCom Firewall because the SecureWall is blocking all other traffic.  

EXAMPLE 25 SSH Port Forwarding

Configure an unknown endpoint to connect using SSH Port Forwarding and allow outgoing unencrypted Internet traffic. (SSH Option needed) 

WANa: 192.168.0.1	LANa:10.0.0.1/8
WANb: unknown

SSH Port Forwarding works with known TCP ports.  Once activated, the MultiCom Firewall will wait for users to authenticate from any IP address (optionally public keys can be used as well.)  Authentication will be from the user list of the MultiCom Firewall (maximum of  10 users).  The MultiCom just needs to have the server activated and the rest of the configuration using the remote users SSH Client software.

EXAMPLE 26a & 26b IPSec Roadwarrior Gateway with High Availability

Configure an unknown endpoint connecting to the LAN using IPSec in Tunnel mode, with normal Internet access and High Availability. (IPSec & VRRP Option needed) 

WANa: 192.168.0.1/24	LANa:10.0.0.1/8
WANb: 192.168.0.2/24	LANb: 10.0.0.2/8
WAN-remote: unknown	LAN-remote: 11.0.0.0/8

Using the same configuration as 21, two MultiCom Firewalls are configured using the High Availability (VRRP) option.  This means that if the Roadwarrior Gateway goes down then the backup will automatically take over for it.  Incoming Roadwarriors will authenticate with the new device.  It is recommended to use Dead Peer Detection if both sides support this to quickly and efficiently close the broken IPSec tunnel.  Otherwise the tunnel will timeout according to the IKE/SA configuration.

The VRRP protocol used for providing High Availability will send out multicast heartbeats using 224.0.0.18/32.  Any interface being protected with High Availability that is also using the SecureWall or SPI Firewall will need to allow this traffic. Additionally, if using NAT on an interface a NAT rule will need to be created to redirect this traffic to the MultiCom Firewall without checking the Destination (as is usually the case for NAT redirected traffic). 

CAUTION - When using High Availability with IPSec services, the NAT rules allowing incoming IPSec traffic (IKE UDP 500, as well as ESP and AH protocols, UDP4500 for NAT Traversal) must not check the Destination (as is usually the case for NAT redirected traffic).

It is required to use different VRRP Router ID's because High Availability is being used on both the WAN and the LAN interface in this example.  More information on the High Availability option can be found in the High Availability chapter of the Reference Manual.

Feature Guide

a only allows incoming traffic that is a response to an outgoing demand or matches a NAT Input or Global rule
b not needed for multiple IPs when using PPPoE for WAN configuration
c this is the only way to NAT ICMP traffic to internal servers
d allows rules to be valid on any interface with NAT activated
e allows remote traffic to look like it originates from LAN, useful for routing issues or to use NAT Global
f must have static route added for default traffic
g only for traffic passing through the firewall to another network (from the LAN to the Internet for example)
h for IP traffic directed at the built-in services of the Firewall itself such as its Webserver, telnet server, or ftp server
i for traffic originating from the Firewall, responses to web configuration, replies to pings, returned telnet data
j  when using a static WAN IP address don't forget to add a default route to your ISP's gateway