For the static IP address option, the ISP should provide:

	Note: cOS Core ignores the broadcast address
	The broadcast IP address need not be specified. It is automatically calculated by cOS Core but is not responded to.

Creating IP Objects

Before defining any new addresses, the address book already contains a number of useful addresses by default. One of the most useful is the all-nets address, which corresponds to the IPv4 address 0.0.0.0/0 (all hosts and networks).

To create the IP objects necessary for Internet access, go to Objects > Address Book in the Web Interface or InControl and then select Add > IP address.

The following IP objects should be added or modified:

Interface Naming

cOS Core uses certain naming conventions for particular objects, such as gw-world for the ISP gateway. These need not be followed by the administrator but if they are followed, it makes examination of a configuration by support personnel easier.

The IP addresses defined in the previous section can alternatively be retrieved automatically from the ISP using the DHCP protocol. This is done by enabling DHCP on the Ethernet interface. The address book will now be automatically populated with all relevant IP addresses as they are received from the ISP via DHCP.

See Chapter 5, DHCP Services for more information about this topic.

Device:/> set Interface Ethernet wan DHCPEnabled=Yes

An important cOS Core principle that is repeated throughout this guide and which will be stated again here, is that there are a minimum of two cOS Core configuration components required for data traffic to flow through the firewall:

The creation of the appropriate route and IP rule set entries for Internet access is discussed in the sections that follow.

Initially, no route will exist in the main routing table that allows traffic to reach the Internet so this must be defined. The routes parameters will be as follows:

Notice that the destination network for this route is all-nets. When cOS Core needs to determine which interface the received traffic should be forwarded out from, it looks in a routing table for the "narrowest" destination network match. This all-nets route is therefore a catch-all route that will be used when no other, more specific, matching route exists. There should therefore only be one all-nets route.

The all-nets route is, in fact, created automatically by cOS Core when the gateway IPv4 address is specified for an Ethernet interface.

To create the route manually in the Web Interface or InControl, go to Routes > New Route.

The route to access wan_net via the wan interface will be automatically created when the wan_net object is edited and the gateway defined.

See Chapter 4, Routing for more information about routes.

Device:/> cc RoutingTable main

Device:/main> add Route Interface=wan
			Network=all-nets
			Gateway=isp_gw_ip

Device:/main> cc
Device:/> 

Before traffic can flow to the ISP, an appropriate IP Policy object should be created to the allow the traffic.

For web browsing of the Internet, DNS and HTTP traffic should be allowed to flow. It may also be necessary to use NAT to share a single public IP address assigned to the firewall so that the internal network topology of private IPv4 addresses is hidden.

For example, if web surfing is going to be done from clients on the internal network lan_net attached to the lan interface to the Internet connected to the wan interface, then the IP rules for DNS and HTTP would be:

The service http-all includes both the HTTP and HTTPS protocols but not DNS so a second rule of policy is needed. The single service all_services could have been used in a single rule but this is not recommended as this would mean connections could be opened on any port number and this can compromise security. The best approach is to define the IP rule set filter as narrowly as possible, which has been done here.

Device:/> add IPPolicy Name=surf_http
			SourceInterface=lan
			SourceNetwork=lan_net
			DestinationInterface=wan
			DestinationNetwork=all-nets
			Service=http-all
			Action=Allow
			SourceAddressTranslation=NAT
			NATSourceAddressAction=OutgoingInterfaceIP

Device:/> add IPPolicy Name=surf_dns
			SourceInterface=lan
			SourceNetwork=lan_net
			DestinationInterface=wan
			DestinationNetwork=all-nets
			Service=dns-all
			Action=Allow
			SourceAddressTranslation=NAT
			NATSourceAddressAction=OutgoingInterfaceIP

See Section 3.6, IP Rule Sets and Section 3.6.2, Creating IP Policies for more information about rules and policies.

cOS Core needs external DNS servers to be defined in order to resolve certain FQDNs. This is particularly important for certificate handling. Up to three DNS servers can be manually specified to cOS Core and at least one should be configured for DNS lookup to function.

Device:/> set DNS DNSServer1=dns_server_1 DNSServer2=dns_server_2

Automatic DNS Configuration through DHCP

When DHCP configures the DHCP servers in cOS Core, names are automatically assigned to these servers so they can be referenced later in user interfaces. The names used are of the form <if-name>_dns1, <if-name>_dns2 and so on, where <if-name> is the interface name on which the DHCP addresses are received.

When cOS Core itself acts as a DHCP server, the DNS addresses it hands out are, by default, the same as those received through DHCP unless different DNS servers are explicitly specified.

Default DNS Server Address Names with DHCP

When viewed in the Web Interface or InControl, these DNS addresses always have the value 0.0.0.0. To see the actual value after it has been assigned with DHCP, use the CLI command dhcp -show. For example, to see the status of the DNS servers on the wan interface, use the command:

Device:/> dhcp -show wan

See Section 3.10, DNS for more information about this topic.