Conntrack
This chapter covers some aspects related to system conntrack, which is a
feature that allows the user to track connections through OSDx devices.
The conntrack utility provides a featured userspace interface to the Netfilter connection tracking system. It can be used to dump a list of all (or a filtered selection of) currently tracked connections.
Connection Format
All connections can be structured in a similar fashion to the one shown below:
icmp 1 25 src=10.0.0.1 dst=10.0.0.2 type=8 code=0 id=18723 vrf=RED packets=2 bytes=168 src=10.0.0.2 dst=10.0.0.1 type=0 code=0 id=18723 vrf=RED packets=2 bytes=168 mark=33 use=1 appdetect[L3:1]
In the example above, you can see a ping connection using a vrf called RED. It contains both an origin and a reply message (each with its own fields, such as the source (src) and destination (dst) ip address and message code and type), as well as global parameters like the protocol used (icmp), the number of packets and bytes transmitted, and the id.
In addition to the fields mentioned, there are others related to the traffic policies established in the connections. For example, information on whether the connection is bypassed or not (Sc: not-bypass) can be found, as well as on the mark packet, the offloaded flag ([OFFLOAD] or [HW_OFFLOAD]), and app-detect data (appdetect[engineId:appID]). More information about these fields and their configuration is found in Traffic Routing Articles and Firewall Service.
Running the system conntrack monitor command will monitor all current connections (containing the previously described fields) via three different states:
NEW: New conntrack messages.
UPDATE: Updated conntrack messages.
DESTROY: Conntrack messages indicating disconnection.
Logging
system conntrack logging is an option that allows conntrack information to be sent via syslog.
The message types to be captured, NEW, UPDATE, DESTROY or ALL of them (events option with destroy as default value) must be configured, as well as
the log level of those events (log-level option). This last option indicates the log level at which messages will be displayed,
and not their own level. For example, setting this option to err will display the conntrack messages with error format, but
configuring it with debug will show the information with debug style (info level by default).
The expected output when running system journal monitor or system journal show will be as follows:
osdx ulogd[9431]: [NEW] ORIG: SRC=10.0.0.1 DST=10.0.0.2 VRF=RED PROTO=TCP SPT=55406 DPT=80 PKTS=6 BYTES=577 , REPLY: SRC=10.0.0.2 DST=10.0.0.1 VRF=RED PROTO=TCP SPT=80 DPT=55406 PKTS=4 BYTES=653 MARK=33 LABELS=LOCAL APPDETECT[L4:80 http-host:10.0.0.1]
In addition to the default conntrack message, the label field associated to a traffic policy and the app-id related to the traffic detection are also included.
Some examples of this feature and how to configure it can be found here.
App Detection
system conntrack app-detect is an option that enables visualizing the application detection field in
conntrack flows. This field is formed by three values: Engine ID, App ID and detected data.
Running system conntrack show, system conntrack monitor or configuring system conntrack logging
while this configuration option is set will display this field with the following format: appdetect[enginedID:appID “detected data”]
Engine ID
Indicates the abstraction layer associated to that flow. There are three possible values: L4 (Layer 4 protocol, such as an http connection), L3 (Layer 3 protocol, like ICMP) and U (Userspace, which corresponds to any upper layer).
App ID
Indicates the identifier associated to the Engine ID detected. If the engine ID is “L3” (i.e icmp protocol), then this number will reflect the code associated to that protocol (icmp corresponds to protocol code 1, as indicated in RFC792). If the engine ID is “L4” (i.e http protocol), then this field will indicate the port used during the connection (http typically runs in port 80). Finally, if the engine ID is “U”, then the app-id identifies the traffic with a value that can be set using different mechanisms.
One of the mechanisms mentioned above involves creating a traffic policy with a custom app-id and congfiguring that policy in an interface as follows::
set traffic policy Test rule 1 set app-id custom 33
set interfaces ethernet eth4 traffic policy in Test
Sending some traffic with ping <ipv4|ipv6|txt> and running system conntrack show will output the following:
icmp 1 28 src=10.215.168.1 dst=10.215.168.64 type=8 code=0 id=17504 packets=2 bytes=168 src=10.215.168.64 dst=10.215.168.1 type=0 code=0 id=17504 packets=2 bytes=168 mark=0 use=1 appdetect[U:33]
where the appdetect field is displayed with the app-id custom value.
Another mechanism involves defining a dictionary file (xml) containing different applications with different ids, as shown below:
<?xml version='1.0' encoding='UTF-8'?>
<provider engine_id="128" name="Teldat">
<app id="30" name="Teldat Test" version="1">
<fqdn_list>
<fqdn>10.215.168.1</fqdn>
</fqdn_list>
</app>
<app id="31" name="Teldat Test 2" version="1">
<address_list>
<range id="1">
<net_address>10.215.168.64</net_address>
<net_mask>255.255.255.192</net_mask>
</range>
</address_list>
</app>
<app id="69" name="Teldat Test sdwan-lab" version="1">
<fqdn_list>
<fqdn>teldat.com</fqdn>
</fqdn_list>
</app>
</provider>
In this case, configuring system conntrack app-detect dictionary <u32> filename <file> with these applications
and system conntrack app-detect enable_dict_match_priv_ip, setting an SSH connection to 10.215.168.64,
and running system conntrack show will output the following:
tcp 6 3597 ESTABLISHED src=10.215.168.1 dst=10.215.168.64 sport=52360 dport=22 packets=18 bytes=1016 src=10.215.168.64 dst=10.215.168.1 sport=22 dport=52360 packets=21 bytes=2452 [ASSURED] mark=0 use=1 appdetect[U:31]
where app-id 31 corresponds to the “Teldat Test 2” application identifier.
Note
Even though, by default, SSH corresponds to an L4 engine ID with port 22 (app ID), the paths configured rename the engine ID to “U” and the app ID to 31 (as set forth in the dictionary file).
Detected Data
The last field detected by the app refers to specific information on incoming or outgoing traffic in the OSDx device.
This information must be first configured in the system conntrack app-detect path.
If no option is configured, no data will be displayed. The options are:
dns, dns-host, http, http-host, http-referer, http-url, http-user-agent, ssl and ssl-host
For example, if http-host is configured and there is some communication with an http server,
running system conntrack show will display the host the OSDx device has connected to:
tcp 6 17 TIME_WAIT src=10.215.168.64 dst=10.215.168.1 sport=41666 dport=80 packets=6 bytes=583 src=10.215.168.1 dst=10.215.168.64 sport=80 dport=41666 packets=4 bytes=504 [ASSURED] mark=0 use=1 appdetect[L4:80 http-host:10.215.168.1]
where the host of the http server corresponds to ip 10.215.168.64
Note
More information on this last option will be displayed by configuring system conntrack app-detect debug and
running system journal show or system journal monitor