Firewall
Let in only the traffic you allow; turn the rest away at the door
The firewall at the edge of your cloud network comes with every environment and starts by denying everything. You decide in the portal which door opens for whom, and see who changed what in the same place.
Why now
- At 2 a.m. your remote desktop port takes thousands of password guesses from abroad, and the server's logs fill up. That door should only ever have been open to the office address and the tunnel.
- An admin panel was opened to the internet 'temporarily' and has stayed that way for months. Nobody remembers who opened it, and the rule has no description.
- All your users are in Türkiye, yet most sign-in attempts on your login page come from other countries. Collecting and refreshing country IP lists by hand eats half a day of someone's week.
- The internal auditor wants a reason and a change history for every internet-facing port. Your rules live in one place, NAT in another and tunnel settings in a third console.
- The accounting server is moving to the cloud and must be reachable only from the office. You need a path between office and cloud with rules separate from the internet.
What changes
| Today | With Nesnet |
|---|---|
| Scanners find a server's open port before you do. | The gateway starts by denying everything; only the port you open answers, and only to the source you allow. |
| Country IP lists are gathered by hand and go stale within months. | Nesnet refreshes country groups every week, and your rule keeps working with the current list. |
| Nobody knows why a port was opened, or by whom. | Every change shows in the audit trail with a user name, and every rule keeps its description in the table. |
| Firewall, NAT and tunnels live on separate devices with separate consoles. | Rules, NAT, encrypted tunnels and load-balancer addresses sit on one gateway, in one table. |
| Patching, spares and hardware failures of the edge device are your team's problem. | The gateway runs active-standby and Nesnet operates the platform; you look after your rules. |
From today to live: how it works
- 1
Discovery call
Walk Nesnet's team through which servers will face the internet, how the office will connect and which countries you expect traffic from. You leave with the outline of a rule plan and a clear view of what drives the price.
- 2
Your gateway arrives ready
When your environment opens, its gateway firewall is ready with a deny-all rule. No appliance order, no installation wait.
- 3
Groups and service profiles
Define office addresses, server groups and application ports by name. Your rules then read in those names.
- 4
Rules, publications and tunnel
Write and order the rules, switching logging on where you need it. Servers go public through the port-publishing flow, and the office connects through a tunnel on the same gateway.
- 5
Watching it live
Once live, follow blocked and allowed traffic in the logs. Leftover permissions are removed, and country groups refresh on their own every week.
What you get
An edge that starts closed
The gateway firewall is handed over with a deny-all rule, so no connection from the internet reaches your servers until you open a door. A new server isn't visible to the world the moment it boots; it goes public only through a rule you write.
Allow, drop silently or reject
Each rule allows, silently drops or rejects traffic. Dropping gives a scanning address nothing at all; rejecting tells your own users straight away that the connection was refused, so applications don't hang waiting for a reply.
Control inbound and outbound separately
Rules apply to inbound, outbound or both directions and cover IPv4, IPv6 or both. Let a server reach only its update servers and cut every other outbound connection, making it much harder for a compromised machine to talk to the outside world.
Write it once, let the group grow
Sources and destinations can be a single IP, a CIDR block, an IP range or a firewall group. Put office addresses or web servers in a group, and new members are covered without rewriting the rule.
Write rules without looking up port numbers
There are 415 ready-made application port profiles, so common services such as remote desktop, databases or mail are picked by name. When they aren't enough, define your own profile with up to 15 lines of protocols and port ranges per rule.
Rules that match the application
The gateway firewall inspects traffic from layer 3 up to layer 7. With a context profile, a rule matches the application generating the traffic rather than just the port number, so a service on a non-standard port can't slip past by changing ports.
Publish a server on a single port
The port-publishing flow opens the destination NAT (DNAT) rule between public address and internal server together with its allow rule. Remove the publication and both rules go together, so no forgotten permission is left behind.
Reach the internet from one known address
With source NAT (SNAT), your servers go out to the internet from your organisation's public IP, so a partner needs just one address for its allow list. Rules that skip NAT for tunnel traffic (NO_SNAT, NO_DNAT) are available, with priority and logging set per rule.
Close the door to specific countries
Country groups that Nesnet refreshes every week become the source of your rule. Closing an admin screen to everything outside Türkiye, or allowing only the countries you do business with, takes a single rule, and you never carry the IP lists yourself.
Bad data never loosens a rule
If the weekly country-data update brings a missing or broken file, the update stops and the existing groups stay as they are. Block rules that rely on those groups don't quietly open up one morning because a group came back empty.
The office tunnel on the same gateway
The IPsec tunnel between your office and the cloud is built on the same gateway, with strong, current encryption defaults and a custom profile if the far end needs different settings. No separate virtual appliance to run, no extra console to learn.
Tunnel rules kept apart from internet rules
The office network arriving through the tunnel is defined as its own source in your rules. Accounting server for the office only, web server for everyone: both live in one table without bleeding into each other.
See blocked traffic in the portal
Logging is switched on per rule, and each rule gets its own log ID. Firewall, SNAT and DNAT logs are listed and refreshed in the portal and exported as CSV, so you never have to guess whether a rule is doing its job.
Know who changed what
Every rule change appears in the audit trail under the name of the user who made it. Months later you can still find when a port was opened and by whom, and an audit question about justification is answered with a record.
Keep the rule table readable
Place a new rule above or below an existing one to set the order, and give every rule a description. A table that grows over the years explains what each rule is for, so a new network engineer doesn't have to reverse-engineer it.
Put a ceiling on bandwidth
A rate-limit profile can be applied to traffic entering and leaving the gateway. A big backup transfer or a test environment won't choke the live service sharing the same connection.
A gateway whose standby takes over
The gateway runs on two nodes, active and standby; if the active node fails, the standby takes over with the same rules. Your rules are identical on both sides and never need rewriting after a failure.
The small network services, in the same place
Static routes, DHCP and a DNS forwarder that can also forward conditional zones run on the same gateway as the firewall. A small environment doesn't need a separate network server to build and patch for them.
Stay with the brand you know
If your corporate policy requires a particular firewall vendor, that vendor's virtual appliance runs at the edge of your environment instead of the gateway. Your security team keeps working in the interface and policy language it knows.
Why Nesnet
Country groups kept current by Nesnet's own tool
Nesnet refreshes IP groups for 250 countries every week with a tool it wrote itself, fed from a widely used geolocation database. Collecting, counting and renewing country lists drops off your team's to-do list.
Bad data never opens the door
If an update brings missing or corrupt data, the tool stops and leaves the existing groups alone, and every group it writes is read back to verify it. An admin screen that relies on a country rule isn't exposed to the world by a broken file.
Everything at the edge in one table
Firewall rules, NAT, encrypted tunnels, load-balancer addresses and static routes sit on the same gateway and are run by the same team. You don't open three consoles to find out why a port is open.
The gateway comes with every environment
Every environment on the Nesnet cloud has a firewall and NAT ready on its gateway. You write your first rule without waiting for an appliance order or an installation project.
Its own network and IPv6, in Türkiye
Nesnet reaches the internet under its own AS number (AS216146) through two separate carriers, and your traffic and logs stay in the Equinix Istanbul (Dudullu) and Türk Telekom Ankara data centres. Rules cover IPv4, IPv6 or both.
Example scenarios
A company closing remote desktop to the internet
Situation
A company's Windows server has its remote desktop port open to the internet. Every night its logs show thousands of password attempts from abroad.
Outcome
An IPsec tunnel is built between office and cloud, and the remote desktop rule is rewritten to allow only the office network arriving through the tunnel. Attempts from the internet are dropped at the edge and never even reach the server's logs.
A service closing its admin panel to the rest of the world
Situation
A software company's customer admin panel is reachable from the internet. All its users are in Türkiye, but most sign-in attempts come from other countries.
Outcome
A block rule is added to the panel's port with country groups outside Türkiye as its source. Because the groups refresh weekly, the rule needs no hand maintenance, and blocked attempts show up in the rule's logs.
A team publishing a new web server on one port
Situation
A team wants to put a new web server on the internet without exposing its management or database ports.
Outcome
The port-publishing flow opens DNAT and the allow rule for HTTPS only; everything else stays under the default deny. When the server is retired, both rules are removed together.
An IT team walking into an audit with evidence
Situation
An organisation's internal audit asks for a justification and six months of change history for every internet-facing port.
Outcome
Rule descriptions give the reasons, and the audit trail shows who changed what and when. Firewall and NAT logs are attached to the audit file as CSV, and nobody spends weeks digging through email archives.
An organisation moving to the cloud with its own vendor policy
Situation
An organisation's security policy requires every edge device to come from the same vendor, and its cloud move has stalled on that requirement.
Outcome
Its chosen vendor's virtual appliance runs at the edge of the environment instead of the gateway. The security team keeps its familiar interface, and the move goes ahead without changing the policy.
Who does what
| Nesnet | You |
|---|---|
| Builds, updates and keeps the gateways and firewall platform running active-standby. | Decide which door opens for whom, and write and order the rules in the portal. |
| Hands over every gateway with a deny-all rule. | Choose which rules log traffic, and review logs and the audit trail regularly. |
| Refreshes country groups every week and halts the update when bad data arrives. | Remove rules and publications you no longer use. |
| Operates internet connectivity, public IP addresses and the IPv6 address block. | Give your team portal roles and grant rule-change rights only to those who need them. |
Who it is for
Teams with internet-facing servers
Teams that publish a website, application or API and want every open port to be a deliberate choice. The firewall is already on every environment's gateway, so there's no appliance to buy, install or patch.
Companies using remote desktop and admin screens
Companies that want remote desktop (RDP), SSH or an admin panel reachable only from the office and a few known addresses. Those doors never open to the internet; they answer only the tunnel or an allowed address.
Services whose users are in Türkiye
Organisations whose customers and staff are in Türkiye and who want to cut off waves of sign-in attempts from abroad at the edge. Country groups become the rule's source, and Nesnet refreshes them every week.
Companies connecting offices and branches
Companies linking office or branch networks to the cloud over an encrypted tunnel. Tunnel traffic sits in the same table as internet traffic, under its own rules.
IT teams facing an audit
Teams that must answer 'why is this port open, and who opened it?' with evidence. Every change is in the audit trail under a user name, and every rule carries its own description.
May not be the right fit
If you need to restrict traffic between your own servers, an edge firewall isn't enough on its own. Micro-segmentation, which enforces rules at each virtual machine's network card, is the right fit.
If you want to search traffic content for attack signatures, look at Intrusion Detection and Prevention, which runs alongside the firewall.
Under the hood
The firewall is a layer 3–7 gateway firewall running on the edge gateway of your virtual data centre. The edge is a gateway dedicated to you and runs active/standby, and the internet exit layer behind it is redundant as well. You create, change and delete rules in the portal; each change is processed as a task and is live once that task completes. Service definitions start from 415 built-in application port profiles. With a log provider connected, rule logs appear in the portal. Nesnet adds its own tooling on top: a sync tool that refreshes country groups weekly from a geolocation database, and a port publishing flow that opens a DNAT rule and its matching allow rule together and removes them together.
Building blocks
- Dedicated edge gateway
- gateway firewall, NAT and IPsec
- Cloud portal and API
- where rules are written, plus log view and audit trail
- Nesnet country group tool
- writes IP blocks for 250 countries from a geolocation database into country groups
- Virtual firewall appliances
- virtual editions of widely used firewall brands, replacing the edge when a specific brand is required
How it compares
| Option | When it is the right choice |
|---|---|
| A virtual firewall appliance (virtual editions of widely used firewall brands) | Choose this when policy names a vendor or your team already works in that vendor's tooling. The appliance replaces the edge at your environment's boundary and is managed through its own interface. |
| Micro-segmentation | If what you really need is to limit traffic between servers, edge rules will not get you there. Micro-segmentation enforces rules at each virtual machine's network card and complements the perimeter firewall. |
| Intrusion Detection and Prevention | If you want to look for attack signatures inside the traffic, beyond ports, addresses and applications, see the Intrusion Detection and Prevention page. It works alongside the firewall rather than replacing it. |
Technical specifications
| Where it runs | Your edge gateway |
|---|---|
| Action | Allow, drop, reject |
| Direction | Inbound, outbound, both (default both) |
| IP version | IPv4, IPv6 or both |
| Source / destination | Single IP, CIDR, range, IP set, security group |
| Service profiles | 415 built-in + custom TCP/UDP/ICMPv4 |
| Logging and order | Per-rule logging; place above/below |
| Change processing | As a task; live on completion |
| Audit trail | Changes recorded with user name |
| Application context | Context profile; up to 15 port-protocol rows per rule |
| Inspection layers | Layer 3–7 |
| Portal log view | Firewall logs, CSV export |
| NAT logs | In the portal |
| NAT types | SNAT, DNAT, NO_SNAT, NO_DNAT; port mapping |
|---|---|
| IPsec defaults | IKEv2, DH 14, SHA2-256, AES-128; AES-GCM-128 in tunnel, PFS on, DPD 60 s |
| Other edge services | Static routes, DHCP, DNS forwarder |
| Data source | Geolocation database, via Nesnet's tool |
|---|---|
| Coverage | 250 countries |
| Refresh | Weekly; halts on bad data, groups kept |
| Edge | Active/standby edge gateway |
|---|---|
| Internet exit layer | Redundant |
| Rate limit | Profile on ingress and egress |
| Internet connectivity | AS216146, two upstream carriers |
| Data centres | Equinix Istanbul (Dudullu) and Türk Telekom Ankara |
If something breaks
The active side of the edge fails
The edge gateway runs active/standby; if the active side fails, the standby takes over and the edge keeps running.
Country data arrives corrupt
If the weekly update brings incomplete or bad data, the update stops and existing country groups stay as they are. Rules that depend on those groups do not loosen because a group was emptied.
A wrong rule goes in
The audit trail shows which rule changed, who changed it and when, and the rule logs show which traffic it affected. The cause is found quickly and the rule is corrected in the portal.
Frequently asked questions
Pricing and first steps
Pricing
The gateway and its firewall are billed monthly; if you choose a particular vendor's virtual appliance, it appears as its own line. The price is set by the resources you use and the items you choose, and Nesnet’s team prepares your quote.
What the price depends on
- Whether a virtual firewall appliance replaces the edge, and which one
- Outbound internet traffic (GB)
- Number and size of the protected virtual servers
How to get started
- 1.Tell us which servers will face the internet using the form, or call 0800 606 1071.
- 2.The outline of your rule plan and the price are worked out in one call.
- 3.Your environment opens with a gateway that denies everything, and you write your first rule in the portal.
Open your edge on purpose
Tell Nesnet's team which servers will face the internet, how your office connects and who needs access; you'll hear back within the same business day. Your gateway starts closed, and only your rules open the door.