This is Part 2 of the network foundation. The Packet Walk Comes First built the mechanics in Part 1: addressing, switching, routing, access-layer controls, routed boundaries, and your first ACL.

You can start here, but Part 1 makes the ending more useful. This post returns to the packet-walk diagram and finishes the picture.

By the end of Part 1, you had caused two log events on purpose. One recorded a port-security violation. The other recorded an ACL denial. You saved both to a text file.

That file looked like homework. It was the left edge of a monitoring pipeline.

This post proves it.

We begin with the services every packet depends on: DHCP, DNS, NTP, and TLS. You cannot protect or investigate a protocol you cannot recognize in a capture.

Then the work moves into management and visibility: authentication, authorization, the management plane, syslog, flow records, packet capture, wireless, and remote access. The final sections connect those mechanics to segmentation, network design, cloud networking, and zero trust.

The conventions from Part 1 still apply. Concepts are vendor-neutral. Commands identify their platform. Attacks appear beside the mechanisms they abuse and the controls that interrupt them.

The book behind the blog: These two posts establish the floor of the network-security domain. The Cybersecurity Architect's Handbook, Second Edition carries the architecture above it. The posts explain how the network works. The book addresses how the architect decides.

Services and their security

DHCP: four messages, one lease, no server authentication

The rogue-DHCP control from Part 1 makes more sense after you read the exchange it protects.

DHCP for a new IPv4 client follows four messages, commonly remembered as DORA:

1. Discover
2. Offer
3. Request
4. Acknowledgment

The client begins without a usable address and broadcasts a Discover. A DHCP server responds with an Offer containing a proposed address and options such as the subnet mask, default gateway, DNS servers, and lease duration.

The client broadcasts a Request selecting one offer. Broadcasting the selection also tells other responding servers that their offers were not chosen. The selected server returns an Acknowledgment, and the client can use the lease.

Client                         DHCP server
  |                                 |
  | DHCPDISCOVER, broadcast         |
  |-------------------------------->|
  |                                 |
  | DHCPOFFER                       |
  |<--------------------------------|
  |                                 |
  | DHCPREQUEST, usually broadcast  |
  |-------------------------------->|
  |                                 |
  | DHCPACK                         |
  |<--------------------------------|

Initial DHCP broadcasts do not cross a router. Multi-subnet networks use a relay on the client subnet's gateway. On Cisco IOS, ip helper-address forwards the request to a central DHCP server and identifies the originating subnet so the server can select the correct scope.

[Cisco IOS shown]

Router(config)# interface Vlan10
Router(config-if)# ip helper-address 10.0.20.50

That relay path explains the trusted-port decision in DHCP snooping. Only ports leading toward the legitimate server or relay path should accept server messages. User-facing ports remain untrusted.

The security problem is plain: the Offer tells a host what to believe about its local network, and the base protocol does not authenticate the server. A rogue server can supply a hostile default gateway or resolver.

Even passive observation has value to an attacker. DHCP options can reveal hostnames, vendor classes, address ranges, lease patterns, and other implementation details.

Capture the exchange instead of memorizing the acronym. The protocol becomes much easier after you read the options yourself.

DHCP lease timing, failover, scope design, DHCPv6, and IPv6 router advertisements belong in the names, addresses, and time material. For now, keep one IPv6 parallel: self-configuration through router advertisements creates a rogue-RA problem, and RA Guard is an access-layer defense for it.

DNS: whoever answers decides what the name means

A normal endpoint runs a stub resolver. It asks a configured recursive resolver for an answer and usually trusts the result.

When the recursive resolver has no cached answer, it performs the larger walk:

1. A root server identifies the authoritative servers for the top-level domain.
2. The top-level-domain server identifies the authoritative servers for the requested domain.
3. The domain's authoritative server returns the requested record.
4. The recursive resolver caches the answer for its Time to Live and returns it to the client.

The cache makes DNS fast. It also makes a poisoned answer valuable because many downstream clients can inherit the same false result.

The trust decision is easy to miss: the resolver determines what names mean to the client. A rogue DHCP server that supplies a hostile DNS server is stealing that decision.

Keep the troubleshooting split clear:

• DNS translates a name into an address.
• Routing carries packets toward that address.

Both failures look like "the site is down" to a user. Testing the address directly helps separate them.

Name fails, address works: investigate DNS.
Name resolves, connection fails: investigate route, policy, port, and service.

Record types, recursive behavior, authoritative zones, caching, split-horizon DNS, and DNSSEC validation receive full treatment in the names, addresses, and time material.

A domain-joined Windows machine depends on internal DNS

Windows domain members locate domain controllers through DNS SRV records published in the internal namespace.

If the network interface points to the wrong resolver, the computer may lose the ability to locate its domain even while public websites continue to resolve. The resulting symptoms include slow sign-in, Group Policy failures, share failures, and domain-controller-locator errors.

Domain-joined clients should use approved internal DNS servers. Those internal resolvers can forward public queries according to the organization's design.

Do not add a public resolver to a domain member as a casual "secondary." Windows DNS-client selection includes retry and reachability behavior that does not guarantee the simple primary-then-secondary order people imagine. Under failure conditions, the public resolver may receive queries for internal names and return results that cannot satisfy domain discovery. Intermittent failure is harder to diagnose than a consistent outage.

When domain behavior becomes unreliable, inspect the client's DNS server list early.

The security consequence is larger than availability. Control of the resolver influences where the client believes infrastructure services live. That is why hostile DNS delivered through rogue DHCP is so useful to an attacker.

The Windows and network firewall layers also need separate names. Group Policy can configure Windows Defender Firewall on domain members. It does not configure a network firewall at a routed zone boundary. A ticket that says "the firewall blocked it" is incomplete until it identifies the enforcement point.

DNS attack and defense pairings

Several attacks use DNS differently, so the defenses must answer different questions.

Cache poisoning and false authority

Cache poisoning attempts to place a forged answer into a recursive resolver's cache. Clients that trust the resolver then receive the false result.

Compromising a DNS server itself is a different behavior. MITRE ATT&CK maps the compromise of DNS infrastructure to T1584.002, Compromise Infrastructure: DNS Server. That mapping does not make every cache-poisoning event T1584.002. Use the identifier only when the adversary actually compromised DNS infrastructure as a resource.

DNSSEC signs DNS data so a validating resolver can verify its origin and integrity. It protects the answer chain when deployment and validation are correct.

DNS tunneling

DNS tunneling carries command-and-control messages or stolen data inside query names and responses. DNS is attractive because outbound resolution is permitted from many networks.

MITRE ATT&CK maps DNS used for command and control to T1071.004, Application Layer Protocol: DNS. Exfiltration over a nonstandard or alternative protocol may map to T1048, Exfiltration Over Alternative Protocol, depending on how the data leaves.

A query such as the following deserves investigation when it repeats at machine speed:

ZXhmaWx0cmF0ZWQ.attacker.example

High query volume, long encoded labels, unusual record types, high entropy, and repeated traffic to newly observed domains can support tunneling detection. None is conclusive alone.

Protective resolution and encrypted transport

Protective DNS blocks or redirects names that policy or threat intelligence identifies as malicious. It places enforcement in the resolver and can stop a connection before the client reaches the destination.

DNS logs provide a useful record of intent. They show which names clients tried to resolve, including attempts that never became successful network connections.

DNS over TLS and DNS over HTTPS protect the transport between the client and resolver when TLS validation succeeds. They can authenticate that resolver connection and hide the query from observers on that path. They do not, by themselves, prove the origin integrity of every authoritative DNS answer. DNSSEC addresses that separate problem.

Do not confuse encrypted DNS transport, DNSSEC validation, and protective DNS. They solve different parts of the trust chain.

NTP: bad clocks corrupt good evidence

NTP stratum describes distance from a reference clock.

Stratum 0 is the reference source, such as a disciplined hardware clock. Stratum 1 servers connect directly to that source. Each additional synchronization hop increases the stratum.

The exact number matters less than agreement and stability. Network devices, servers, endpoints, and security tools need a common time source.

Security depends on time for two reasons.

First, incident correlation fails when clocks disagree. If the switch is five minutes ahead and the identity provider is three minutes behind, one incident can look like several unrelated events. Investigators may place actions in the wrong order, and evidence may not survive serious scrutiny.

Second, authentication systems rely on time. Certificates have validity periods. Kerberos checks clock skew. Time-based one-time passwords use shared time windows. A dead or drifting NTP path often appears as an authentication problem first.

Windows domains commonly use a five-minute Kerberos clock-skew tolerance by default, though domain policy can change it. Do not wait for authentication failures to discover that time synchronization stopped.

Use at least two approved sources and authenticate NTP where the platform and design support it. Let the management network provide or reach the trusted sources used by the systems it monitors.

[Cisco IOS shown]

Router(config)# ntp server 10.0.20.200

Router# show ntp status
Clock is synchronized, stratum 3

Linux hosts may use chrony or systemd-timesyncd. Windows has its own time-service hierarchy in a domain. The implementation can differ. The clocks still need to agree.

TLS: agree, authenticate, then encrypt

TLS provides an encrypted and integrity-protected channel after the peers negotiate protocol parameters and authenticate as required.

A simplified TLS 1.3 server-authentication flow is:

1. The client sends a ClientHello containing supported parameters and key shares.
2. The server selects parameters and sends its key share.
3. The server presents a certificate chain and proves possession of the corresponding private key.
4. The client validates the chain, name, validity period, and signature.
5. Both sides derive symmetric session keys from the negotiated key exchange.
6. Application data travels encrypted and integrity protected.

TLS 1.3 reduced the handshake and removed older protocol choices. The core lesson remains stable: encrypting bytes is not enough. The client must know which server received them.

That is the certificate's job.

A certificate binds a public key to an identity, commonly a DNS name, through a signature from a certificate authority the client trusts. Validation checks the chain, identity, dates, and usage constraints.

A certificate warning is the trust model reporting a failure. Clicking through it removes the protection the warning exists to provide.

The root of that decision is the client trust store. Anyone who can add a trusted CA can influence which certificates the client accepts. The CA store is security configuration and must be protected accordingly.

TLS protects content, not every observable fact

TLS hides application content from a passive observer when the protocol and validation work correctly. It does not hide all metadata.

An observer can still see source and destination addresses, timing, packet sizes, connection duration, and traffic volume. The requested hostname may also be exposed through the TLS handshake when Encrypted ClientHello is not in use.

That is why encrypted networks remain monitorable through flow metadata, endpoint telemetry, certificate details, and other observable behavior.

TLS inspection changes the trust path

A TLS-inspecting proxy terminates the client connection, inspects the plaintext, and creates a separate encrypted connection toward the destination.

The client accepts this only when it trusts a CA capable of signing the proxy's replacement certificate. The organization has authorized an on-path intermediary through endpoint trust configuration.

The costs are real:

• Decryption and re-encryption consume capacity and add latency.
• The inspection system and CA key become high-value assets.
• Certificate pinning and mutual TLS can break.
• Privacy, legal, and employee-monitoring requirements may limit inspection.
• Regulated or sensitive categories may need documented exceptions.
• Fail-open and fail-closed behavior must be decided rather than discovered during an outage.

Inspection is a policy decision, not a checkbox. Use it where the detection value and legal authority justify the cost. Where inspection is not appropriate, rely on endpoint visibility and network metadata, then document the remaining blind spots.

HTTP, HTTPS, and the application edge

An HTTP request contains a method, path, headers, and sometimes a body. The response contains a status code, headers, and usually a body.

On TCP 80, those fields may be readable directly. On HTTPS, TLS protects the HTTP content from passive network observers.

Port numbers are defaults rather than laws. An HTTP service can listen on another port, and another protocol can listen on 80 or 443. This is why a port-only firewall rule is not the same as application identification.

Several HTTP status codes appear constantly in support and incident work:

A 500 generally points toward the application. A 502 or 504 often points toward the load balancer, reverse proxy, upstream path, or backend health.

L4 and L7 load balancing

A layer-4 load balancer makes decisions from addresses and ports. It is fast and does not need to understand HTTP content.

A layer-7 load balancer terminates the client connection and can route using the hostname, URL path, headers, cookies, or other application details. That visibility costs processing and makes the load balancer part of application behavior.

Its timeouts, buffering, header changes, TLS configuration, and health checks now affect the user experience.

A useful health check tests the application function rather than only the listening port. A wedged process may continue answering TCP handshakes long after it stopped serving valid requests.

First-hop redundancy solves a related availability problem for the default gateway. Protocols such as HSRP and VRRP let multiple routers present a virtual gateway address. A failover should allow hosts to keep the same configured gateway, though a brief traffic interruption can still occur during convergence.

Mail protocols: the transport tells you who can read the credentials

Legacy mail protocols have protected deployment patterns:

A port number alone does not prove plaintext. STARTTLS can upgrade a connection on ports such as 143 or 587.

The finding is a capture showing credentials or message content exposed without effective transport protection, or a configuration that permits downgrade when policy requires encryption.

Part 1 already explained why an on-path observer matters. Mail captures show the operational consequence.

First exercises: services

Exercise 1: capture DHCP

Release and renew a lab client's address while Wireshark or tcpdump is running.

Find the Discover, Offer, Request, and Acknowledgment. Read these fields from the Offer or Ack:

• Assigned address
• Subnet mask
• Default gateway
• DNS server
• Lease duration
• Server identifier

Exercise 2: capture DNS

Clear the client cache, query a name, and capture the request and answer.

Identify:

• Query name
• Record type
• Resolver address
• Returned answer
• Time to Live
• Whether UDP or TCP carried the exchange

Repeat the query while the cache is warm. Explain what changed and which cache may have answered.

Exercise 3: record the unknowns

List every field in both captures that you cannot explain. Do not hide the list.

Knowing what you can read and what you need to look up is part of packet analysis. The list should be long at first.

Watching and reaching the network

Authentication and authorization solve different problems

Authentication answers who or what is requesting access. Authorization answers what that identity may do.

Authentication factors fall into three broad categories:

• Something you know, such as a password or PIN
• Something you have, such as a hardware key or managed device
• Something you are, such as a biometric characteristic

MFA requires different factors. Two passwords are still one factor category.

A password alone is the weakest normal enterprise pattern. A password plus push approval is stronger, but push fatigue remains a real attack: repeated prompts pressure the user into approving one to stop the interruption.

Phishing-resistant methods such as FIDO2 security keys, passkeys used with proper origin binding, and certificate-based authentication remove the shared code that a fake page can steal and replay.

Authorization then applies a model:

• Discretionary access control lets an owner grant access. It is flexible and can spread quickly.
• Role-based access control maps permissions to job roles and people to those roles.
• Mandatory access control uses centrally enforced labels and clearances.
• Attribute-based access control evaluates policy using identity, resource, location, time, device, and other attributes.

Least privilege grants enough access for the task and no more. Separation of duties keeps one person from controlling both an action and its independent approval or review.

Network devices commonly consume these decisions through AAA:

• Authentication: Who are you?
• Authorization: Which commands or functions may you use?
• Accounting: What did you do?

TACACS+ and RADIUS can provide centralized services behind the device login. Command accounting answers who entered a configuration command and when.

Identity stands in front of segmentation, ACLs, and logging. It does not replace them.

SSH only, and only from the management path

Telnet transmits the session without modern cryptographic protection. An on-path observer can read credentials and commands.

Do not merely prefer SSH. Remove Telnet from the available management transports.

[Cisco IOS shown]

Switch(config)# hostname SW1
SW1(config)# ip domain name lab.local
SW1(config)# crypto key generate rsa modulus 2048
SW1(config)# ip ssh version 2
SW1(config)# line vty 0 4
SW1(config-line)# transport input ssh
SW1(config-line)# access-class 10 in
SW1(config-line)# login local

SW1# show ip ssh
SSH Enabled - version 2.0

The RSA command provides a lab-compatible host key on IOS images that support it. Production key types and sizes should follow current platform capabilities and organizational cryptographic policy.

transport input ssh removes Telnet from the VTY path. access-class 10 in applies the management-subnet ACL from Part 1. login local uses the local account database as the lab authentication source.

Production devices should normally use centralized AAA with a protected and tested local fallback account.

Apply the same discipline to web management. Use HTTPS when the interface is required. Disable the service when it is not.

A service that does not listen cannot be scanned, exploited, or forgotten during patch planning.

Junos leaves Telnet disabled unless it is enabled, which is the better default. Arista EOS uses an IOS-like management model, but current hardening syntax should be checked for the installed release.

The management zone becomes real configuration

Part 1 drew the management zone. Now give it a subnet, interfaces, and policy.

Use the management /27 from the addressing plan. Place switch, router, firewall, hypervisor, console, monitoring, and other administrative interfaces there. Permit access only from approved administration systems and paths.

"Reachable from almost nowhere" becomes an ACL and firewall policy rather than a sentence on the diagram.

Out-of-band management has one test:

Assume the core is down and every production trunk is dark. Can you still reach the console of the devices needed to recover it?

If the out-of-band path depends on the production network it is supposed to repair, it is not independent.

In a small lab, a console cable and laptop are enough to teach the distinction. In production, the answer may include dedicated management switches, console servers, separate circuits, cellular backup, and controlled power distribution.

Build the recovery path before the incident. You cannot construct it through the network that is already down.

SNMP: version 3 with authentication and privacy

SNMP provides interface counters, device health, state, inventory, and alerting data.

SNMPv2c community strings are shared credentials transmitted without the authentication and privacy protections expected from SNMPv3. An on-path observer may read and reuse them.

For systems you care about, use SNMPv3 with authentication and privacy. Keep monitoring read-heavy. Make configuration changes through SSH, an API, or the approved change process rather than broad SNMP write access.

[Cisco IOS command shape shown]

Switch(config)# snmp-server group NMS v3 priv
Switch(config)# snmp-server user nms NMS v3 auth sha <auth-secret> priv aes 128 <privacy-secret>

Exact algorithms and syntax depend on the platform and release. Do not copy placeholder secrets into production.

The configuration lifecycle matters as much as the protocol. Back up device configurations automatically to a system that records differences. Know how the platform rolls back before entering the maintenance window.

A configuration that exists only on the device is one storage failure away from reconstruction by memory.

Syslog: eight severities and one operating habit

Syslog severity runs from 0 through 7:

An informational threshold is a reasonable lab starting point. Debug logging can overwhelm the collector and the device. Warning-only collection may omit events needed for investigation.

[Cisco IOS shown]

Switch(config)# service timestamps log datetime msec show-timezone
Switch(config)# logging host 10.0.20.200
Switch(config)# logging trap informational

Ship the events off the device to a protected collector in the management zone. A device that stores its only audit trail locally gives an intruder the record and the means to erase it in the same place.

Now decode the event from Part 1:

%PORT_SECURITY-2-PSECURE_VIOLATION: Security violation occurred,
caused by MAC address 000c.29a4.7b31 on port GigabitEthernet1/0/5.

The structure is:

PORT_SECURITY     facility
2                 severity
PSECURE_VIOLATION mnemonic
MAC and port      event facts

Cisco's format is one dialect. Junos, Linux, Windows, and security platforms dress events differently. The reading habit transfers: identify the source, severity, event type, time, actor or object, and result.

You were reading monitoring-pipeline input in Part 1. Now the pipeline has a name.

Flow records show who talked; packet captures show what crossed the wire

Network visibility has several cost tiers.

Syslog records events generated by devices and services.

Flow data, such as NetFlow or IPFIX, records conversation metadata. Typical fields include source and destination addresses, ports, protocol, timestamps, byte counts, packet counts, interfaces, and flow direction. It normally does not contain payload content.

Flow records are cheap enough to retain much longer than full packet captures. They answer incident-scoping questions such as:

Which internal hosts talked to this address?
Which systems sent unusual volumes of data?
Which ports did the compromised host contact?
When did the conversation begin and end?

Flow data remains useful when application content is encrypted because it never depended on the plaintext.

Packet capture preserves the frames or packets selected by the capture point and filter. It is more expensive to collect and retain, but it exposes protocol detail that flow summaries cannot.

Use two capture habits.

First, scope before reading. A focused display filter such as the following teaches more than a capture containing every conversation on the interface:

tcp.port == 443 && ip.addr == 10.0.20.10

Second, find one specific fact. Read the DHCP Offer options. Confirm a DNS answer. Identify a plaintext authentication exchange in the lab. Follow one TCP stream.

Visibility across logs, flows, endpoint telemetry, and selected packet capture is a budget decision. Make it deliberately. Sending everything to expensive searchable storage can bury useful signal and exhaust the budget before the retention period is met.

The log event was SIEM input all along

The path from your switch to an investigation is:

Control triggers
    -> device writes an event
    -> syslog ships the event
    -> collector receives and timestamps it
    -> parser extracts fields
    -> SIEM correlates it with other activity
    -> detection creates an alert
    -> analyst decides what it means
    -> response follows the runbook

Each arrow can fail.

• Without trustworthy time, events cannot be ordered confidently.
• Without shipping, the evidence remains on the device that may be compromised.
• Without parsing, the data remains difficult to search and correlate.
• Without tested detections, the event may never become an alert.
• Without an owner and runbook, the alert enters a queue and dies there.

The SIEM cannot recover facts the network never recorded.

Port security, ACL logging, DHCP snooping, authentication logs, DNS logs, and flow telemetry are the left side of detection engineering. Part 1's 2:00 a.m. conference-room exercise was manual alert triage: read the event, check the cheap context first, then escalate based on evidence.

The full progression from log to event, alert, case, and incident belongs in the From Log to Incident material. The Handbook treats monitoring as an architecture problem: what to collect, where to place sensors, how long to retain data, who responds, and which failure modes the pipeline must survive. [chapter ref]

Wireless in the present tense

WPA2 remains common; WPA3 is the target state

The Wi-Fi Alliance identifies WPA3 as mandatory for Wi-Fi CERTIFIED devices and requires Protected Management Frames in WPA3 networks.

WPA3-Personal replaces the WPA2 pre-shared-key handshake behavior with Simultaneous Authentication of Equals. An attacker cannot take one captured exchange away and test an unlimited password list offline in the same manner as a weak WPA2 PSK. Password quality still matters, and online attempts remain possible.

Personal and Enterprise deployments solve different identity problems.

A shared PSK creates shared exposure. Departed staff, contractors, unmanaged devices, and copied notes all retain the same credential until it changes. Logs identify devices more readily than people.

Enterprise wireless uses 802.1X with a RADIUS service so each user or device authenticates separately. Access can follow identity, certificates, role, and device state. The cost is certificate, RADIUS, endpoint, and policy administration.

Use PSK for homes, small labs, and situations where the operational cost of 802.1X is not justified. Use Enterprise authentication for workforce networks where individual accountability and revocation matter.

Transition modes can support older clients during migration. Treat them as a bridge with an owner and end date rather than the permanent answer.

Evil twins copy the name, not the identity

An SSID is an advertised name. Anyone can transmit the same name from another access point.

An evil twin uses that copy to attract clients to an attacker-controlled network. The attacker may combine the false SSID with signal strength, captive-portal impersonation, deauthentication attempts, or a client's automatic connection behavior.

MITRE ATT&CK identifies this as Evil Twin, T1557.004.

The defenses authenticate what the SSID alone cannot:

• WPA3-Enterprise or WPA2-Enterprise with correctly configured 802.1X
• Client validation of the RADIUS server certificate and expected server identity
• Protected Management Frames for supported management-frame protection
• Wireless intrusion detection and rogue-AP monitoring
• Managed client profiles that disable unsafe automatic joins
• Removal of remembered open networks that no longer have a business purpose

Protected Management Frames protect specified management traffic after the security association exists. They make spoofed deauthentication and disassociation against associated clients harder. They do not make every pre-association frame trustworthy or eliminate all evil-twin paths.

The critical Enterprise control is certificate validation. An attacker can copy the SSID. The attacker should not be able to present a certificate chain and server identity the managed client accepts.

A phone that automatically joins any network named CoffeeShop has pre-approved an identity-free trust decision. Review and remove those saved networks.

Remote access and the edge

IPsec: IKE negotiates; ESP carries protected traffic

Modern IKEv2 terminology uses an IKE security association and one or more Child SAs. Older training material often calls these phase 1 and phase 2.

The useful model is:

1. The peers authenticate and create an IKE SA that protects negotiation traffic.
2. Inside that protected exchange, they agree which traffic to protect and derive keys for a Child SA.
3. ESP carries the selected traffic with encryption and integrity protection according to the negotiated policy.

Two deployment shapes dominate.

Site-to-site VPNs connect networks through gateways and normally remain available continuously.

Remote-access VPNs connect a client to a gateway when needed. Authentication, device policy, address assignment, DNS, routing, and session logging all become part of that service.

Split tunneling is a policy decision. With a full tunnel, internet traffic crosses the enterprise inspection path but consumes more capacity and depends on that path. With split tunneling, selected traffic goes directly to the internet, reducing load but removing it from some enterprise controls.

Write down which traffic enters the tunnel and why.

Cryptographic choices age. Current deployments normally prefer IKEv2, authenticated modern encryption such as AES-GCM, appropriate SHA-2-based functions where required, forward secrecy, and current Diffie-Hellman or elliptic-curve groups supported by both peers. Verify the accepted suite against current organizational and platform guidance before deployment.

A VPN moves the network trust boundary. It protects the path from interception and tampering. It does not make the remote endpoint safe.

A compromised home computer with broad VPN access is still a compromised endpoint with an internal route. Strong authentication, device posture, least-privilege routes, segmentation, and monitoring remain necessary.

SSH and RDP belong behind controlled access paths

SSH administration should use keys or another phishing-resistant method where the platform supports it. Disable direct root login on systems that provide that option. Reach management services from the management zone, a VPN, bastion, or another controlled administrative path.

RDP is the Windows graphical administration protocol. Network Level Authentication requires authentication before Windows creates the full graphical session. It reduces unauthenticated session exposure and resource consumption. It does not eliminate every pre-authentication or implementation risk.

Use current TLS, patched clients and servers, controlled administrator identities, and a managed administration workstation. Put RDP behind a VPN, Remote Desktop Gateway, bastion, or policy proxy with MFA.

Do not expose SSH or RDP directly to the internet as the normal operating model.

Public administrative listeners attract scanning and credential attacks quickly. Strong passwords do not protect against stolen credentials, implementation flaws, or weak recovery paths. Internet-facing RDP has also had wormable vulnerability classes in its history.

The controlled path should produce a better record than the raw service alone: identity, source, target, session time, approval where required, and administrative actions where the platform supports them.

Denial of service begins with where capacity runs out

Denial-of-service attacks generally exhaust one of three resources.

Volumetric attacks consume link capacity. Reflection and amplification attacks, including DNS amplification, use many systems to send more traffic toward the victim than the victim can receive.

State-exhaustion attacks consume connection tables or protocol state. A SYN flood abuses the half-open TCP handshake state introduced in Part 1.

Application-layer attacks send requests that are inexpensive to transmit but expensive for the application to process.

MITRE ATT&CK separates Network Denial of Service, T1498, from Endpoint Denial of Service, T1499.

The hard limit must be stated plainly: a firewall at the end of a 1 Gbps circuit cannot restore capacity after several gigabits have already filled that circuit.

Volumetric defense must begin upstream through provider filtering, scrubbing services, content-distribution capacity, or anycast absorption. Arrange that service and document the provider contact before an attack.

The local edge still has work:

• SYN cookies and connection controls can protect state tables.
• Rate limits can reduce selected abuse.
• Antispoofing filters can reject impossible source addresses.
• Server and application limits can reduce expensive request paths.
• Flow telemetry can reveal attack shape and top contributors.
• A runbook can define who calls the provider and who decides on emergency filtering.

Ask one operational question now: does anyone know the ISP's security incident contact and required customer information? If not, that is the first finding.

Scenario: the vendor wants public RDP by Friday

The HVAC vendor asks for RDP access to the building-management server from the internet. The deadline is Friday.

A useful refusal needs mechanics and a working replacement.

The refusal is:

We do not expose RDP directly to the internet. A public 3389 listener receives continuous scanning and credential attacks, and the HVAC server is unlikely to match the patch and monitoring standard of a dedicated remote-access gateway.

Then offer two paths that can meet the deadline.

Option 1: scoped vendor VPN access

Create a named vendor identity with MFA. Restrict the assigned VPN policy to the HVAC server and required port. Add an expiration date or approved access window. Send authentication, VPN, firewall, and target-host events to the monitoring system.

This is usually the fastest acceptable option where a VPN platform already exists.

Option 2: gateway or bastion access

Provide access through Remote Desktop Gateway, a managed bastion, or a privileged session broker. Require MFA. Limit the destination. Record session metadata and, where policy permits, the session itself.

A third option may be an outbound-only vendor support agent. That removes the inbound listener but replaces it with vendor software, outbound trust, update dependence, and an egress-policy decision. Evaluate that trade rather than calling it automatically safer.

Security that only says no will be routed around when the deadline arrives. The work is refusing the unsafe path and providing one the business can use.

First exercises: watching and reaching

Exercise 1: lock the management plane

Configure SSH version 2 on the lab switch. Permit it only from the management subnet through the standard ACL built in Part 1.

Prove the allowed path works.

Exercise 2: prove the denied path

Attempt SSH from the user VLAN. Confirm the connection is refused, then locate the ACL or authentication event that records the attempt.

Exercise 3: reopen the evidence file

Your file should now contain:

• A port-security violation
• An ACL denial
• A refused management-plane connection

For each event, identify the timestamp, source device, facility or channel, severity, event type, object or actor, and result.

Three controls now produce three pieces of one investigation story.

Where the mechanics lead

Flat networks turn one compromise into every team's incident

A truly flat network is one broad layer-2 and policy domain. A network with several VLANs and unrestricted routing is not literally the same broadcast domain, but it can be almost as permissive from a lateral-movement perspective.

One compromised workstation may reach file servers, cameras, HVAC systems, identity infrastructure, and payroll. Every incident begins with a large unknown blast radius.

A segmented network applies the mechanics from both posts as design:

• VLANs define layer-2 domains.
• Subnets make those domains routable and documentable.
• Zones assign trust and function.
• ACLs, firewalls, and host controls govern crossings.
• Logs and flow telemetry record attempted and permitted paths.

A compromised user endpoint should reach only what user-zone policy permits. An unauthorized conference-room device should be constrained by its access port and assigned zone.

Run the 2:00 a.m. scenario against both designs.

In the permissive network, the device may reach anything, so the incident starts with urgent uncertainty. In the segmented network, policy and telemetry provide a bounded list of reachable systems and attempted crossings.

Segmentation makes the incident answerable.

The design spectrum is:

1. Coarse zone segmentation, which is the affordable default
2. Per-application segmentation between application tiers
3. Microsegmentation through workload-level policy

Microsegmentation requires a dependency map. Policy written before application flows are known produces outages or broad exceptions that recreate the original problem.

A segment that has never been tested is still a diagram. Attempt prohibited and permitted flows in both directions. Preserve the evidence. Where segmentation is used to reduce regulated scope, confirm the required validation method and cadence with the applicable standard and assessor.

CAH2 develops segmentation through data classification, trust boundaries, enforcement placement, validation, and residual risk.

Segment devices you cannot fully trust or maintain

Cameras, sensors, badge readers, HVAC systems, displays, and other connected devices often have limited update paths, long replacement cycles, vendor-managed software, or no endpoint security agent.

Assume they may become compromised and design the network accordingly.

Place them in dedicated VLANs and zones. Start with default deny. Permit only the controller, DNS, NTP, update, and other services each device class requires. Do not give them broad access to user, server, management, or restricted networks.

OT and IT separation applies the same principle with safety and process-availability consequences added.

Network monitoring matters more when the endpoint cannot report for itself. DNS and flow records can still reveal unexpected destinations, scanning, data volume, and connection timing.

Ask the test question:

If the parking-lot camera is compromised, what can it reach?

In a segmented design, the answer is a policy list you can read. In a permissive design, the answer begins with discovery during the incident.

Physical access can bypass the network path

A console port does not ask the VLAN ACL for permission. On many network platforms, physical console access plus a reboot can reach documented recovery procedures with substantial administrative consequence.

Protect closets, racks, consoles, and power. Disable and park unused access ports. Remove live public-area jacks that have no business purpose. Monitor access to spaces containing critical network equipment.

Physical-security design, surveillance, environmental controls, and recovery custody require deeper treatment elsewhere. The network rule is short: someone alone with your switch may not need to attack the packet path you designed.

Campus and datacenter networks grow into different shapes

Campus networks commonly use three tiers, access, distribution, and core, or collapse distribution and core into one redundant pair when scale permits it.

Campus traffic is often north-south. Users reach shared services, internet edges, and datacenter applications. Access design emphasizes endpoint density, PoE, wireless, user policy, and manageable broadcast domains.

Datacenter networks commonly use spine-leaf fabrics. Every leaf connects to every spine, producing equal-cost paths between leaves. The underlay is routed, and overlays such as VXLAN and EVPN can provide workload network services where required.

Datacenter traffic is often east-west. Workloads talk to other workloads, storage, and service tiers. The design emphasizes predictable hop count, horizontal capacity, automation, and interior visibility.

The selection question is traffic direction and scale, not fashion.

The security connection remains the same. Routed boundaries carry policy. East-west traffic requires east-west telemetry. Automation increases consistency and also increases the effect of a bad template or compromised controller.

Cloud networking uses familiar mechanics under provider names

The route table should be the least surprising row. It still contains prefixes, next hops, and a default.

Do not flatten all cloud controls into one "cloud firewall" concept. AWS security groups are stateful while network ACLs are stateless. Azure NSGs are stateful. Provider behavior and evaluation order differ, so check the current provider documentation before implementation.

The transferable skills are reading the route, identifying the enforcement point, understanding state, and testing the effective path.

Programmable networks concentrate both control and risk

Software-defined networking separates more of the control decision from packet forwarding. A controller calculates policy and paths, while devices or virtual switches enforce them.

That enables repeatable automation. It also concentrates authority. A controller compromise, bad policy push, or flawed template can affect a large part of the network quickly.

SD-WAN applies centralized policy and encrypted overlays to branch connectivity across several transport types. The policy can choose paths by application and service requirement rather than relying only on static routes.

The benefit is consistent centralized intent. The cost is dependence on controller security, software supply chain, identity, telemetry, and rollback.

Zero trust removes network location as the identity claim

NIST SP 800-207 describes zero trust architecture without granting implicit trust based only on network location. Access is evaluated through policy decision and enforcement components using identity, device, resource, and contextual information.

The network is still necessary. It is no longer sufficient evidence that a request should be trusted.

ZTNA applies this model to remote access by brokering access to named applications or resources instead of granting a broad route to an internal network. It can reduce VPN-level exposure, but it does not replace every legacy protocol, administrative path, or site-to-site use case automatically.

The practical design work includes:

• Inventorying the applications and protocols
• Defining user and device conditions
• Placing enforcement points
• Handling unmanaged devices
• Preserving access for legacy systems without giving them broad trust
• Logging every policy decision
• Protecting recovery and break-glass paths

Zero trust is an architecture pattern. It is not a product name.

SASE and SSE product definitions change across vendors and analysts. The durable idea is that WAN connectivity and cloud-delivered security policy can be combined. Verify a product's actual enforcement, identity, inspection, and failure behavior instead of accepting the category label.

These subjects are where the mechanics lead. They are not replacements for the mechanics.

The promise, kept

The Part 1 packet-walk diagram now includes control boxes at each decision point. Port security protects the access port, DHCP snooping and Dynamic ARP Inspection protect local configuration and ARP, trunk controls protect VLAN tags, ACLs and firewall policy protect routed crossings, and a syslog path sends events to a collector in the management zone.

Walk the picture one last time.

1. The host joins through an access port. Port security constrains unexpected MAC addresses.
2. DHCP snooping permits server messages only from trusted infrastructure paths.
3. The host resolves the gateway. Dynamic ARP Inspection checks the claim against the binding table.
4. The switch forwards within the VLAN. VLAN assignment limits the broadcast and trust domain.
5. The frame crosses the trunk. Explicit mode, VLAN pruning, and native-VLAN discipline protect the boundary.
6. The router performs longest-prefix matching. Route authentication and filtering protect how the table is learned.
7. The flow crosses a trust boundary. ACL and firewall policy decide whether it continues.
8. Each control writes an event when configured to do so.
9. Syslog ships the event to the management zone.
10. NTP keeps events from several systems in a usable order.

Now place the scenarios on the picture.

The 2:00 a.m. conference-room device first meets port security and access-layer policy.

The rogue home router meets DHCP snooping because an untrusted port should not send server messages.

The vendor's request for public RDP is stopped by remote-access policy and replaced with a controlled VPN, gateway, or bastion path.

Several stories, one packet path.

The operating rule is:

You cannot secure a network you cannot subnet, switch, route, and observe.

Learn the mechanics first. Place the controls second. Trigger them deliberately. Read what they wrote.

Everything in this pair can run in a lab with two switches, one router or layer-3 switch, and a syslog host in a management VLAN. Packet Tracer, GNS3, EVE-NG Community, and containerlab can support different versions of that build. Check current licensing and image rights before downloading or distributing vendor images.

The habit is more important than the tool:

Configure one control.
Trigger it on purpose.
Read the event.
Prove the permitted path still works.
Save the evidence.

A controlled broadcast storm teaches more than a diagram of one. A rejected SSH attempt teaches more than a slide about management ACLs. A DHCP capture teaches more than memorizing DORA.

Where to go from here

• The Packet Walk Comes First: Part 1 of this network foundation
• The Map and the Floor: the entrance to the Essentials series and its security domains
• The Terminal Is a Conversation: the Linux foundation and its authentication evidence
• Windows Fundamentals for Cybersecurity, Part 1: the Windows machine, ACLs, PowerShell, and event logs
• Windows Fundamentals for Cybersecurity, Part 2: Windows networking, remoting, SMB, firewalls, and domain orientation
• Names, Addresses, and Time: DHCP, DNS, NTP, and the identity dependencies behind them
• From Log to Incident: the monitoring pipeline from event to alert and response
• The Firewalls Series: rulebase design and the hands-on OPNsense build