Log Management
Find out what happened on your network and who changed what, in seconds
Every decision your firewall makes and every action in your organization is recorded inside your cloud portal, searchable without learning a query language.
Why now
- A new application server can't reach the database; the app team blames the network and the network team blames the app. The firewall log shows the rule that rejected the connection in a single line, and the argument ends in five minutes.
- On Monday morning someone notices a server is off, and nobody remembers shutting it down. The audit trail shows who did it and when.
- Thousands of connection attempts hit your remote desktop port over the weekend. Which countries they came from, and whether every one was rejected, shows up by filtering on the action and country columns.
- A customer audit asks you to show that admin actions on your systems are on record. The audit trail is ready without setting up a log server.
- Building a log server, planning disks and learning a query language is too much for a small team. Here the logs live inside the portal and you search them with plain text.
What changes
| Today | With Nesnet |
|---|---|
| Working out why a connection fails takes hours of guesswork. | The log shows in one line which rule allowed or blocked the connection. |
| To find out who changed what, you ask everyone one by one. | Every action in the organization is recorded with who, when and on which object. |
| Searching logs needs a separate log server and a query language. | Logs sit inside the portal and are searched with plain text and an action filter. |
| Firewall rules don't log by default, and you find out when you need them. | Nesnet turns logging on for your organization and turns it back on if it ever goes off. |
| A suspicious action stays quiet until someone happens to notice. | Repeating patterns in the audit trail land in your team's channel as alerts. |
From today to live: how it works
- 1
Logging needs call
You and the Nesnet team agree which gateways should log and who will look at the records. By the end of the call, the setup steps are clear.
- 2
Nesnet turns logging on
Firewall rules don't log by default, so Nesnet turns logging on for your organization's gateway. The change is previewed first, and rule content stays the same.
- 3
Logs appear in your portal
Records start flowing into the logs tab of the extension in your cloud portal. You search with plain text, filter by action and watch new lines in follow mode.
- 4
Set up pattern alerts
Write pattern alerts for the phrases you want to watch in the audit trail, and connect them to your team's Slack channel or webhook. The log stops being an archive and becomes a source that warns you.
What you get
Every connection's verdict in one line
Each line shows time, action, direction, source and source port, destination and destination port, country, protocol and rule name. Why a connection was allowed or blocked is read straight from the line itself.
Actions told apart by color
Dropped, rejected, allowed and address-translated connections are shown in different colors. Instead of hunting for the rejected connection among hundreds of lines, your eye goes straight to the red.
Search without a query language
Type an address, port or rule name to search the logs in plain text, and filter by action type. There's no query language to learn and no saved query templates to memorize.
Near-live watching in follow mode
Follow mode fetches new lines every five seconds, so you see the effect of a rule change right after you make it. Watching the log while you test a connection narrows the problem down in minutes.
See each connection's country
Every line also shows the country the connection came from or went to. Filter to see which countries are trying your remote desktop port, or whether a server is connecting to an unexpected country.
Who changed what, and when
Every action in your organization lands in the audit trail with who did it, when and on which object. The owner of a server shut down last night or a rule changed this morning is one search away.
Look back ninety days
The audit trail is kept for ninety days. You can confirm a permission change from last quarter or a server deletion from the record, without asking anyone.
Pattern alerts on the audit trail
An alert fires when a case-insensitive phrase appears a set number of times within the window you choose. Servers deleted one after another within an hour, or repeated permission changes, don't go unnoticed.
Alerts in your team's channel
Pattern alerts use the same alerting system as Monitoring and Alerts and are sent to your Slack channel or webhook. Your team hears about important events without keeping the log screen open.
Failed sign-in warnings
Failed sign-in attempts from the last seven days stand out as a warning on the audit screen. Repeated attempts against an account are spotted before a password guess succeeds.
Logging never changes your rules
Turning logging on only flips the logging flag; it never touches a rule's source, destination, port or action. Every change is previewed before it's applied, so your security posture never loosens because of logging.
Logging that switches itself back on
For organizations with logging on, the logging state is checked every ten minutes, and if a rule edit turns it off it's switched back on. The log flow returns without waiting for someone to notice and raise a ticket.
Organization isolation, line by line
Records are filtered by your organization's gateway tag, and that tag is re-checked on every line. Even though gateway infrastructure is shared, another organization's records never land on your screen.
Infrastructure logs stay out of your view
Logs from virtualization hosts, network management and portal components are open only to Nesnet operations and are never shared with tenants. Your screen holds only your own gateway's and your own organization's records.
Firewall logs and network flows together
The firewall log answers whether a connection was allowed and by which rule; the network flows screen in Monitoring and Alerts answers whether traffic happened, with whom and how much. In an investigation the two screens are read together and the picture is complete.
Send your server logs too
Send system logs from your Linux and Windows servers in standard syslog format, with a key specific to your organization. A setup card shows the destination and your organization's tag, and server logs are searched next to firewall logs.
Five hundred lines at a time
Each search fetches the most recent five hundred lines, and filtering happens within them. The screen never freezes on heavy queries; you narrow the search and reach the line you need in a few steps.
An empty screen and a disconnected source are different
If logging is on and nothing matches your search, the screen honestly stays empty; if the source isn't connected at all, it says not configured. While investigating, you never mistake an empty list for a clean result.
No log server, no separate panel
The log screen lives inside the cloud portal where you create your servers. There's no log server to install, no disks to plan, no software to update and no separate account to give your team.
Why Nesnet
Nesnet's screen, inside the portal
The cloud portal doesn't give tenants a log screen on its own, so Nesnet added one inside the portal with its own extension. You reach the logs from where you manage your servers, not from a separate panel with a separate password.
Every line re-checked
Because gateway infrastructure is shared between organizations, filtering by server could have shown another organization's records. Nesnet separates records by the gateway tag inside each line and re-checks that tag on every line.
Turning logging on doesn't touch your rules
Nesnet's logging component only flips the logging flag; it never touches rule content or your security posture. Every change is previewed first and applied after.
An empty result is shown honestly
If the log source isn't connected, the screen says not configured, so it is never confused with an empty list meaning no traffic. Sample or stale data is never presented as current records.
Your data stays in Türkiye
Firewall logs and the audit trail stay in Türkiye, on Nesnet's infrastructure in the Equinix Istanbul (Dudullu) and Türk Telekom Ankara facilities. Logs are never sent to a service abroad.
Run by Nesnet, supported locally
The same Nesnet team builds and runs the gateway, the log store and the portal extension. When you want to know why a record looks the way it does, ask Nesnet’s support team, in Turkish or English.
Example scenarios
An application server that can't connect
Situation
At an insurance company, a new application server can't reach the database. The app team blames the network, the network team blames the app, and the work has been stuck for half a day.
Outcome
The network team filtered the log by the database port and saw, by rule name, that the connection was hitting an old reject rule. The rule was fixed, and in follow mode the connection was seen going through within five seconds.
A server shut down over the weekend
Situation
At a distribution company, someone noticed on Monday morning that a reporting server was off. Nobody remembers shutting it down, and an attack is suspected.
Outcome
The audit trail showed the server had been shut down on Saturday evening from a contractor's account. The contractor's permissions were narrowed, and a pattern alert was set up for server shutdowns.
A remote desktop port under pressure
Situation
An accounting practice keeps its remote desktop port open to the internet and notices the server slowing down.
Outcome
Filtering the logs by that port showed thousands of connection attempts from many countries over the weekend, all rejected. The practice changed its rule so remote desktop is reachable only through the VPN.
Evidence of admin actions for an audit
Situation
A software company was asked, during an enterprise customer's audit, to show that the last three months of admin actions were on record.
Outcome
Ninety days of actions in the audit trail were filtered by person and date and shown to the auditor. Failed sign-in warnings and pattern alerts were added to the file as screenshots.
Who does what
| Nesnet | You |
|---|---|
| Develops, runs and updates the logging extension and the log store. | Write your firewall rules and fix them based on the logs. |
| Turns firewall logging on for your organization's gateway and keeps it on. | Decide who looks at the logs and who has portal permissions. |
| Separates records by organization tag and re-checks the tag on every line. | Define your pattern alerts and notification channels. |
| Keeps the audit trail for ninety days. | Set up your own archive for records that must be kept longer. |
| Keeps infrastructure logs within its own operations and never shares them with tenants. | Investigate incoming alerts and suspicious actions on your side. |
Who it is for
Network and security teams
Teams looking for the rule behind why a connection doesn't go through. Every line says which rule allowed or blocked the connection, so you read the record instead of guessing.
Security leads
People who want to watch rejected inbound connections along with their country. Which countries are hammering which port shows up on the same screen with a filter.
IT managers
Managers who need a quick answer to who shut down this server last night or who changed this rule. Every action in the organization is recorded with who, when and on which object, ninety days back.
Organizations preparing for audits
Organizations that need to show admin actions and network access are on record. The audit trail and firewall logs are ready in the portal without installing another tool.
May not be the right fit
If you need to forward your logs to your own SIEM or download them as files, this product won't cover it today. In that case, running your own log server on a server is the better fit.
If you want to set the retention period yourself or keep logs for years, this product isn't the right fit; the audit trail is kept for ninety days and customers can't change that.
Under the hood
Firewall logs travel from your organisation's edge gateway to the platform's central log store. Nesnet's portal add-on reads them without writing anything and presents them in the portal's Logs tab, filtered by gateway tag. The audit trail is taken from the portal, separated per organisation and kept for 90 days in the add-on's database. The gateway, the log store, the portal and the database are all parts of the same Nesnet cloud, run by the same team. The component that switches logging on and keeps it on is also Nesnet's own code: it touches only the logging flag, previews every change and re-checks enabled organisations every 10 minutes. Pattern alarms run on the same engine as Monitoring and Alerts and use the same webhook and Slack channels. Firewall logs answer "was it allowed, and by which rule", while the network flow view answers "did traffic happen, and how much"; the two complement each other.
Building blocks
- Edge gateway
- where firewall rules run and log lines are produced
- Central log store
- where firewall logs are collected
- Cloud portal
- source of the audit trail and the tenant portal that hosts the log screens
- Nesnet log add-on
- Logs tab, per-line isolation, logging enablement and the 10-minute check
- Event database
- database holding the audit trail per organisation for 90 days
How it compares
| Option | When it is the right choice |
|---|---|
| Run your own log server on a VM | The right choice if you want operating system and application logs, your own query language or your own retention period. In return, installing the log server, planning its disks and keeping it updated fall to your team. |
| Use the network flow view | If your question is "did traffic happen, with whom and how much" rather than "which rule allowed it", the flow view in Monitoring and Alerts is the better tool. Most investigations end with both screens read side by side. |
Technical specifications
| Source | gateway firewall rules, via the platform's central log store |
|---|---|
| Line fields | time, action, direction, source, source port, destination, destination port, country, protocol, rule |
| Actions | DROP, REJECT, PASS, NAT |
| Isolation | filtered by gateway tag, re-checked on every line |
| Per request | up to 500 lines |
| Follow mode | snapshot every 5 seconds |
| Search | free text plus action filter; no query language |
| Enabling logging | logging flag only; applied after a dry run |
| Logging check | every 10 minutes; re-enabled if off |
| Content | who did what, when, on which object; filtered per organisation |
|---|---|
| Retention | 90 days; not customer-adjustable |
| Pattern alarm | case-insensitive phrase, N times within a window |
| Pattern alarm source | the portal's audit trail |
| Failed sign-ins | last 7 days, shown as a warning |
| Infrastructure logs | Nesnet operations only, never shared with tenants |
If something breaks
The log source is not connected
The screen says "not configured". An empty list is never confused with a "no traffic" result.
No matching traffic
If logging is on but nothing matches your search, the screen stays honestly empty; no sample or stale data is shown.
Logging gets switched off
If a rule edit disables logging on the gateway, it is turned back on within 10 minutes for enabled organisations. Logs resume without anyone stepping in.
Frequently asked questions
Pricing and first steps
Pricing
Log Management is billed monthly. The price is set by the resources you use, the retention period and the items you choose, and Nesnet’s team prepares your quote.
What the price depends on
- Virtual servers: the number of VMs in your environment whose logs are collected.
- Storage: the space your disks occupy is measured in GB.
- Outbound traffic: data leaving your environment for the internet is measured in GB.
How to get started
- 1.Fill in the form or call 0800 606 1071.
- 2.We agree on which gateways should log in one call.
- 3.Nesnet turns logging on, and you start searching from the portal.
Solve the next connection problem by reading the log, not arguing
Tell the Nesnet team which gateways should log, and you'll hear back within the same business day. Once logging is on, your first search runs inside the portal, with no query language to learn.