Home  Prev  cOS Core 15.00.01 Administration Guide  Next

1.3. Basic Packet Flow

This section outlines the basic flow in the state-engine for packets received and forwarded by cOS Core. The following description is simplified and might not be fully applicable in all scenarios, however, the basic principles will be valid for all cOS Core deployments.

  1. An Ethernet frame is received on one of the Ethernet interfaces in the system. Basic Ethernet frame validation is performed and the packet is dropped if the frame is invalid.

  2. The packet is associated with a Source Interface. The source interface is determined as follows:

    • If the Ethernet frame contains a VLAN ID (Virtual LAN identifier), the system checks for a configured VLAN interface with a corresponding VLAN ID. If one is found, that VLAN interface becomes the source interface for the packet. If no matching interface is found, the packet is dropped and the event is logged.

    • If the Ethernet frame contains a PPP payload, the system checks for a matching PPPoE interface. If one is found, that interface becomes the source interface for the packet. If no matching interface is found, the packet is dropped and the event is logged.

    • If none the above is true, the receiving Ethernet interface becomes the source interface for the packet.

  3. The IP datagram within the packet is passed on to the cOS Core Consistency Checker. The consistency checker performs a number of sanity checks on the packet, including validation of checksums, protocol flags, packet length and so on. If the consistency checks fail, the packet gets dropped and the event is logged.

  4. If consistency check passes, the packet can now be examined by the AI Anomaly Detection feature if this functionality is enabled. The AI Anomaly Detection does not do anything to the packet other than forward meta data of the packet to the AI Engine for examination and the packet continues uninterrupted to the next phase of the packet flow.

  5. cOS Core now tries to lookup an existing connection by matching parameters from the incoming packet. A number of parameters are used in the match attempt, including the source interface, source and destination IP addresses and IP protocol.

    If a match cannot be found, a connection establishment process starts which includes steps from here to 11 below. If a match is found, the forwarding process continues at step 12 below.

  6. The source interface is examined to find out if the interface is a member of a specific routing table. Routing Rules are also evaluated to determine the correct routing table for the connection.

  7. The Access Rules are evaluated to find out if the source IP address of the new connection is allowed on the received interface. If no Access Rule matches then a reverse route lookup will be done in the routing tables.

    In other words, by default, an interface will only accept source IP addresses that belong to networks routed over that interface. A reverse lookup means that we look in the routing tables to confirm that there is a route with this network as the destination on the same interface.

    If the Access Rule lookup or the reverse route lookup determine that the source IP is invalid, then the packet is dropped and the event is logged.

  8. A route lookup is being made using the appropriate routing table. The destination interface for the connection has now been determined.

  9. The IP rule set is now searched for an entry that matches the packet. The following parameters are part of the matching process:

    • Source and destination interfaces.
    • Source and destination network.
    • IP protocol (for example TCP, UDP, ICMP).
    • TCP/UDP ports.
    • ICMP types.
    • Point in time in reference to a predefined schedule.

    If a match cannot be found, the packet is dropped.

    If a rule is found that matches the new connection, the Action parameter of the rule decides what cOS Core should do with the connection. If the action is Drop, the packet is dropped and the event is logged according to the log settings for the rule.

    If the action is Allow, the packet is allowed to flow. A corresponding state will be added to the connection table for matching subsequent packets belonging to the same connection. In addition, the service object which matched the IP protocol and ports might have contained a reference to an Application Layer Gateway (ALG) object. This information is recorded in the state so that cOS Core will know that application layer processing will have to be performed on the connection.

    Finally, the opening of the new connection will be logged according to the log settings of the rule.

    [Note] Note: Additional actions

    There are actually a number of additional actions available such as address translation and server load balancing. The basic concept of dropping and allowing traffic is still the same.

  10. The IDP rule set is now evaluated in a similar way to the IP rule set. If a match is found, the IDP data is recorded with the state. By doing this, cOS Core will know that IDP scanning is supposed to be conducted on all packets belonging to this connection.

  11. The Traffic Shaping and the Threshold Limit rule sets are now searched. If a match is found, the corresponding information is recorded with the state. This will enable proper traffic management on the connection.

  12. From the information in the state, cOS Core now knows what to do with the incoming packet:

    • If ALG information is present or if IDP scanning is to be performed, the payload of the packet is taken care of by the TCP Pseudo-Reassembly subsystem, which in turn makes use of the different Application Layer Gateways, layer 7 scanning engines and so on, to further analyze or transform the traffic.

    • If the contents of the packet is encapsulated (such as with IPsec, PPTP/L2TP or some other type of tunneled protocol), then the interface lists are checked for a matching interface. If one is found, the packet is decapsulated and the payload (the plaintext) is sent into cOS Core again, now with the source interface being the matched tunnel interface. In other words, the process continues at step 3 above.

    • If traffic management information is present, the packet might get queued or otherwise be subjected to actions related to traffic management.

  13. Eventually, the packet will be forwarded out on the destination interface according to the state. If the destination interface is a tunnel interface or a physical sub-interface, additional processing such as encryption or encapsulation might occur.

The next section provides a set of diagrams illustrating the flow of packets through cOS Core.

Home  Prev   Next