How do you troubleshoot DNS resolution failures on Linux?
Separate IP connectivity from name resolution. Check the configured resolver, query it and a known public resolver directly, and capture DNS packets to see the response. Comparing a direct query with the local resolver shows where the failure occurs.
Steps
Confirm IP connectivity first by pinging a public IP address.
Check which resolver the system is using.
Query the local resolver and a known public resolver for the same name.
Capture port 53 traffic to see the query and the response code.
If the direct query works but the local one fails, suspect the resolver. If both fail, suspect the network path or the upstream.
Example commands
Adapt to your environment and test in an authorized lab before production.
shell
cat /etc/resolv.conf
resolvectl status
dig example.com
dig @8.8.8.8 example.com
sudo tcpdump -ni any port 53
NXDOMAIN means the DNS server reports that the requested name does not exist. Check the name that was actually queried, which server answered, and whether other valid domains resolve. Working IP connectivity alone does not prove DNS is working.
Steps
Read the status: field in the dig output. NXDOMAIN, SERVFAIL and NOERROR point to different problems.
Check the queried name for typos or an unexpected search domain.
Ask a second resolver for the same name.
Confirm that other known-good domains resolve.
Example commands
Adapt to your environment and test in an authorized lab before production.
How can you check network interface speed and duplex?
Use ethtool to read the negotiated speed, duplex and link state, then compare with the interface counters and what the hardware supports. A 10 Gbps NIC may be negotiating a lower speed because of the cable, the transceiver or the device at the other end.
Example commands
Adapt to your environment and test in an authorized lab before production.
shell
ip -br link
ethtool eth0
ethtool -i eth0
ip -s link show eth0
How do you check whether a Linux server is listening on a port?
List the listening sockets and filter for the port. Check which address it is bound to and which process owns it. A listening socket alone does not prove that remote traffic can reach the service.
Steps
A bind address of 127.0.0.1 means local only. 0.0.0.0 or :: means all interfaces.
Then check the host firewall and the network path between client and server.
Example commands
Adapt to your environment and test in an authorized lab before production.
Linux IP forwarding lets a system route packets between interfaces. Many Linux router and VPN gateway designs need it, but it does not by itself set up NAT, firewall permissions, routes or DNS.
Example commands
Adapt to your environment and test in an authorized lab before production.
shell
sysctl net.ipv4.ip_forward
# enable until the next reboot (lab use)
sudo sysctl -w net.ipv4.ip_forward=1
Capture at the relevant interface and compare packets at different points, then follow the flow and check whether replies come back. The example watches UDP port 51820, which WireGuard commonly uses. Your configured port may differ.
Steps
Capture on the WAN interface to see the encrypted packets arrive.
Capture on the tunnel interface to see the decrypted traffic.
If packets enter the tunnel but no replies return, check routes and return paths on the far side.
Example commands
Adapt to your environment and test in an authorized lab before production.
TCP provides a reliable, ordered byte stream with connection management and retransmission. UDP sends datagrams with no built-in delivery or ordering guarantees. Applications choose the transport that fits their needs, and VPNs can use either one depending on the protocol.
How do you troubleshoot a captive portal that does not open?
Walk the client journey step by step: wireless association, client IP, gateway, DNS, portal reachability, HTTP redirect and authentication state. Test with a plain HTTP request where permitted, because HTTPS may not redirect cleanly (encryption and certificate validation).
Steps
Confirm the client associated and received a valid IP address, gateway and DNS server.
Check that DNS resolves a test name.
Request a plain HTTP page and look for the redirect to the portal.
Check that the portal is reachable from the client network.
Check the client's authentication state and any firewall rule that blocks pre-login traffic.
Example commands
Adapt to your environment and test in an authorized lab before production.
How do you troubleshoot a captive portal login failure?
Check client IP allocation, DNS, portal reachability, redirects, authentication service health, RADIUS responses, session state and firewall policy. Compare a successful and a failed login to find the stage that breaks.
Steps
Confirm the client has an address and can load the portal page.
Check the authentication service is healthy and reachable from the gateway.
Match the failed login timestamp with the RADIUS response.
Check the session state on the gateway.
Review firewall policy for the traffic allowed before login.
How do you investigate a Wi-Fi client that connects but has no internet?
Check whether the client received a valid IP address, gateway and DNS configuration. Then test gateway reachability, DNS, authentication status, routing and upstream connectivity. Compare with a working client on the same SSID.
Steps
Read the client's address, mask, gateway and DNS.
Ping the gateway, then a public IP, then a public name.
If a captive portal is in use, check the client's authentication state.
Check routing and the upstream link from the gateway's side.
Example commands
Adapt to your environment and test in an authorized lab before production.
How do you troubleshoot a RADIUS authentication issue?
Match the time of the failed login with the RADIUS logs and the access device's session state. Check client identity, shared-secret consistency, server reachability, request and response codes and access policies. Never publish credentials or subscriber details.
Steps
Get the exact timestamp and the username (or device) that failed.
Find the matching request in the RADIUS log and read the reply code.
Check the shared secret matches on the client (access device) and the server.
Check the network path between the access device and the RADIUS server.
Check the access policy that the request matched.
Example commands
Adapt to your environment and test in an authorized lab before production.
shell
# Use your platform's supported RADIUS logs and test tools
# Test account only, never real credentials:
radtest <test-user> <test-password> <radius-server> 0 <shared-secret>
RADIUS provides centralized authentication, authorization and accounting (AAA). An access point or wireless controller can use it to authenticate users or devices, often through 802.1X. Troubleshooting covers credentials, certificates, shared secrets, reachability and authentication logs.
How can you tell an access point fault from a cable or PoE fault?
Inspect the AP status, the switch port state, PoE delivery and the link counters. Where authorized, test the same port with a known-good device and the AP with a verified cable and PoE source. Change one variable at a time.
Example commands
Adapt to your environment and test in an authorized lab before production.
What is the difference between a VLAN and a subnet?
A VLAN creates a Layer 2 broadcast domain. A subnet is a Layer 3 IP address range. They are usually mapped one-to-one in enterprise designs, but they are different concepts, and traffic between VLANs needs routing and a security policy that permits it.
Example commands
Adapt to your environment and test in an authorized lab before production.
Spanning Tree Protocol prevents Layer 2 loops by building a loop-free logical topology. It elects a root bridge and puts redundant paths into blocking or forwarding states. Without loop prevention, a switching loop causes broadcast storms and MAC address instability.
What is the difference between EtherChannel and switch stacking?
EtherChannel combines several physical links into one logical link for bandwidth and redundancy. Switch stacking makes several compatible switches act as one logical switch. They solve different problems and can be used together.
Hot Standby Router Protocol gives hosts a virtual default gateway shared by several routers or Layer 3 switches. One device is active and forwards traffic, and a standby device takes over if the active one fails, according to the configured priorities and timers.
How do you troubleshoot a VLAN connectivity issue?
Trace the path hop by hop instead of changing several settings at once. Verify the physical link, the VLAN membership and tagging, STP state, MAC learning, then the host's IP settings, routing and any ACL or firewall policy.
Steps
Verify the physical link and port state.
Check the access VLAN on the edge port, and the allowed VLAN list and tagging on trunks.
Check STP state and MAC address learning.
Check the host's IP address, mask and gateway.
Check inter-VLAN routing, ACLs and firewall policy.
Example commands
Adapt to your environment and test in an authorized lab before production.
shell
show vlan brief
show interfaces trunk
show mac address-table vlan 10
How do you troubleshoot a WAN interface that is up but passes no traffic?
A physical link-up state does not confirm end-to-end connectivity. Check interface counters, IP addressing, link negotiation, ARP or neighbor entries, gateway reachability, routing, firewall policy, NAT and the upstream status.
Steps
Read the interface counters: are packets leaving, arriving, or both?
Check the address, mask and negotiated speed and duplex.
Check the ARP or neighbor entry for the upstream gateway.
Ping the gateway, then something beyond it.
Check the default route, NAT and firewall policy. Ask the ISP if everything on your side is clean.
Example commands
Adapt to your environment and test in an authorized lab before production.
Software-defined WAN uses centralized policy and application-aware path selection to steer traffic across the available WAN links. Depending on the platform and design, it can use link health, latency, jitter, packet loss, application requirements and configured priorities.
What is the difference between SD-WAN and traditional dual-WAN failover?
Traditional failover moves traffic to a backup link when the primary fails. SD-WAN can add health-based path selection, application-specific policy, load distribution and finer steering. The exact capabilities depend on the product and its configuration.
The general sequence is: configure the WAN interfaces, create SD-WAN members, define health checks, create performance or steering rules, set up routing, and apply firewall policies for the traffic you need. Validate which path is actually selected and test link failures before production use.
Concept-level answer. Always follow the vendor documentation for the exact firmware version.
How do you troubleshoot intermittent internet access on a dual-ISP network?
Compare WAN health, default routes, policy-based routing or SD-WAN decisions, NAT, DNS, packet loss and return paths. Test each ISP independently and compare the source IPs and packet captures. Do not assume two devices on different ISPs should have identical connectivity.
Steps
Test each ISP on its own, from the router and from a client.
Check which link the failing flows actually use.
Compare the public source IP seen by the destination.
Check health-check results and failover events around the time of the fault.
A properly configured failover or SD-WAN policy detects the failure and moves eligible traffic to another available link. Existing sessions may reset if the public source IP changes, and VPNs may have to re-establish. Test both failover and recovery behavior.
You can watch this happen in the failover simulator on the Labs page.
A site-to-site IPsec VPN securely connects two networks across an untrusted network such as the internet. The gateways negotiate security parameters, authenticate each other, establish IPsec security associations and encrypt the traffic between the configured networks.
Steps
Confirm WAN reachability and the peer IP addresses.
Check IKE Phase 1 authentication, proposals and negotiation logs.
Check Phase 2 proposals, encryption domains and selectors.
Verify routes, firewall policies, NAT exemptions where needed, and return paths.
Check MTU and MSS if the tunnel comes up but some traffic fails.
What is the difference between IKE Phase 1 and Phase 2?
Phase 1 builds the authenticated IKE security association that protects the negotiation. Phase 2, in IKEv1 terms, negotiates the IPsec security associations that protect the data traffic. IKEv2 uses different exchange terminology, so avoid applying the IKEv1 phase labels too literally to it.
The VPN tunnel is up but users cannot reach the remote LAN. What do you check?
Check the source and destination subnets, the routes at both ends, firewall policies, IPsec selectors, NAT, return routing and host firewalls. Capture packets at both tunnel endpoints to see whether traffic enters the tunnel and whether replies return.
Steps
Do the selectors match the real source and destination subnets?
Is there a route at each end that points the remote subnet into the tunnel?
Does a firewall policy permit the traffic in both directions?
Does the destination host know how to send replies back (gateway, host firewall)?
Start with the VPN status and event logs. Check peer reachability, IKE negotiation, proposals, authentication, Phase 2 selectors, routing, firewall policies and NAT. Use packet captures and the built-in diagnostics to find the failing stage, and record the actual error before changing any configuration.
Example commands
Adapt to your environment and test in an authorized lab before production.
shell
get vpn ipsec tunnel summary
diagnose vpn tunnel list
# IKE debug: approved maintenance only, and switch it off afterwards
diagnose debug application ike -1
diagnose debug enable
# reproduce the problem, read the output, then:
diagnose debug disable
diagnose debug reset
Exact commands vary by FortiOS version. Check the vendor documentation first.
What is the difference between a site-to-site VPN and a remote-access VPN?
A site-to-site VPN connects two networks through their gateways. A remote-access VPN connects one user's device to a private network, usually with a VPN client and user authentication. Access policies should limit users to the resources they need.
How do you troubleshoot traffic that a firewall is blocking?
Identify the source, destination, protocol and port. Confirm routing and NAT, inspect the matching policy and its order, check logs and counters, and capture packets where useful. Make the smallest authorized change and validate the result.
Steps
Write down the exact source, destination, protocol and port.
Confirm routing and NAT are not the real problem.
Find which policy the traffic matches, and the order of the rules.
Read the firewall log and hit counters for that flow.
Change the smallest thing, test again and keep a rollback.
Source NAT rewrites the source address of a packet, typically for outbound internet access. Destination NAT rewrites the destination address, typically to publish an internal service. NAT alone does not replace the need for proper firewall rules.
What should you check during a firewall policy review?
Review source and destination scope, services, rule order, NAT, logging, business justification, and unused or overly broad permissions. Apply least privilege, and validate the intended traffic before and after any change.
Example commands
Adapt to your environment and test in an authorized lab before production.
shell
# For each rule, record: policy ID, scope, risk, tests, rollback
How do you investigate a suspicious network connection in Wireshark?
Use an authorized capture, filter by endpoint or protocol, inspect DNS and TCP behavior, review connection timing and repeated failures, and correlate what you see with logs. A single unusual packet is not proof of malicious activity.
Example commands
Adapt to your environment and test in an authorized lab before production.
Inspect /proc/mdstat and the mdadm detail output. Look for degraded arrays, missing members, resynchronization and disk errors in the system logs. Preserve the evidence, then follow the approved replacement and rebuild procedure.
Example commands
Adapt to your environment and test in an authorized lab before production.
How do you investigate high system load or blocked processes?
Check the load averages, CPU and memory use, process states, disk I/O, kernel logs and storage latency. A high load average can come from processes waiting for I/O, not only from CPU saturation.
Example commands
Adapt to your environment and test in an authorized lab before production.
Ansible can apply repeatable configuration to supported network devices, which reduces manual work and configuration drift. Use inventory files, variables, the appropriate network collections, secure credential handling, validation and a tested rollback plan.
Define the VLANs in version-controlled variables, validate the inventory and target devices, review the planned change, apply it to a lab or a limited test group first, and verify the resulting configuration. Keep a recovery path so you cannot lose management access.
Steps
Keep VLAN definitions in Git, in variables.
Validate the inventory and make sure the target device is the right one.
How should network switches be rebooted through SSH automation?
Inventory and verify device identities, test credentials, check current device health, and run a dry run first. Require explicit approval before any reboot, process one switch at a time, log every result and verify recovery before moving on.
Example commands
Adapt to your environment and test in an authorized lab before production.
shell
# Start with inventory and read-only checks.
# Add a separate, explicitly approved reboot step.
# Test in a lab before touching production equipment.
Reboot automation should be tested in a lab before use on production equipment.
What is the difference between a security group and a network ACL in AWS?
A security group is a stateful virtual firewall attached to supported resources or network interfaces. A network ACL is a stateless rule set attached to a subnet. Return traffic is handled differently, so for network ACLs you must consider both inbound and outbound rules.
How do you secure a Linux server hosted in the cloud?
Restrict inbound access and expose only the services you need, use SSH keys and least-privilege accounts, keep the OS and applications updated, configure a host firewall, monitor the logs, protect secrets and keep backups. Check the cloud network rules as well as the host-level controls.
How would you troubleshoot a service that works locally but not from the internet?
Check the service's listening address, the host firewall, cloud security rules, public IP and routing, NAT or port forwarding, DNS and any upstream filtering. Test from an external network, and confirm the service is meant to be exposed and is secured.
Steps
Confirm the service listens on an external address, not only 127.0.0.1.
Check the host firewall and the cloud security rules or security lists.
Check the public IP, DNS record and any NAT or port forwarding.
Test from an external network, not from the same LAN.
Example commands
Adapt to your environment and test in an authorized lab before production.
shell
sudo ss -lntp
sudo ufw status verbose
curl -I https://example.com
How do you investigate packet loss or slow internet?
Compare latency and loss to the local gateway, the upstream hops and the destination. Review interface errors, congestion, WAN health and application behavior. ICMP loss at an intermediate hop can be rate limiting, so correlate the results instead of assuming it proves a fault.
Example commands
Adapt to your environment and test in an authorized lab before production.
Use a monitoring tool such as SolarWinds to review availability, interface utilization, latency, errors and historical trends. Use Wireshark to inspect packet exchanges, retransmissions, DNS behavior, TCP handshakes and protocol-specific failures. Each tool answers a different part of the question: monitoring tells you when and how much, packets tell you why.
Walk me through how you troubleshoot a user with no internet access.
I start by identifying the scope of the issue and checking the client's connection, IP address, gateway and DNS configuration. I then test local gateway reachability, name resolution, authentication status if a captive portal is involved, and upstream connectivity. I use logs and packet captures when needed to isolate the failure before applying a corrective action.
How do you approach a DNS issue when the server is reachable by IP?
I separate IP connectivity from name resolution. I query the DNS server directly, inspect the response code, compare the configured resolver with a known test resolver where authorized, and capture DNS traffic if the result is unclear. Then I decide whether the problem is the record, the resolver or the network path.
What is the difference between a firewall and a router?
A router forwards traffic between networks based on routing information. A firewall enforces security policy by deciding which traffic is allowed or denied, often with stateful inspection, logging and NAT. Enterprise appliances frequently do both.
I would separate guest devices from internal systems using dedicated VLANs or equivalent segmentation, enforce firewall restrictions, allow only the services that are needed, isolate clients where required, and monitor authentication and network activity. I would validate both the permitted and the prohibited traffic.
How do you handle an incident you cannot resolve immediately?
I document the symptoms, impact, scope, timeline and the tests already done. I preserve the relevant logs, identify the most likely failure domain, and escalate with evidence and clear next steps. I communicate the current status without claiming a root cause that has not been verified.