Ports, Firewalls, and Why a Device Can Ping but Still Not Work

Why successful ping does not prove an application works and how biomeds can think through blocked ports, server services, and network communication in plain English

One of the most common network troubleshooting traps in biomed is:

Published September 1, 2026 · Revised September 5, 2026

Back to Biomed Basics

What This Page Explains

This page covers:

The Simple Version

A successful ping shows that the target answered an ICMP echo request across at least one usable IP path. That is helpful, but the clinical application probably uses a different protocol and a specific TCP or UDP port. The application can still fail because a firewall blocks that port, the server service is stopped, the device is pointed at the wrong destination, authentication fails, or the application rejects the message.

Think of the IP address as the building address and the port as a particular door. Ping can confirm that someone at the building answered without proving that the required door is open or that the correct department is working behind it. Troubleshooting must therefore test the actual application path, not stop at basic reachability.

Worked Example: The Server Pings but DICOM Fails

Suppose an imaging device can ping the PACS server but cannot send a study. Confirm the destination IP or hostname, configured DICOM port, called and calling AE titles, local time, and the exact error or association status. Ask whether another device can send to the same destination and whether this device ever worked with its current configuration. Those facts separate a device-specific setting from a shared server or network failure.

Give IT or the application owner a precise request: source address, destination address, protocol and port, timestamp, and observed error. “Please open the firewall” is premature because the service may be stopped or the application may be rejecting the association. Do not disable security controls as a test; verify the approved rule and listening service with the responsible team.

What Is Ping?

Ping is a basic network diagnostic tool.

It generally uses:

ICMP

which stands for:

Internet Control Message Protocol.

What Ping Asks

Conceptually, ping says:

Are you reachable at this IP address, and will you answer an ICMP echo request?

If the other host replies:

You have evidence of basic IP reachability.

Successful Ping Is Useful

If Device A can ping Server B, you have evidence that several things are probably working:

That is valuable.

But Ping Is Not the Application

A PACS server does not receive CT images using ping.

A central monitoring server does not normally receive patient waveforms using ping.

MUSE does not exchange ECG data using ping.

Those applications use other protocols.

Think of an IP Address Like a Building Address

The IP address gets you to the:

Building.

The port tells you which:

Door.

Network Ports

TCP and UDP use numbered ports to identify different services.

Examples might include:

One Server Can Run Many Services

A single server IP may support:

Each may use a different port.

Example

Server IP:

10.20.30.40

A device might ping:

10.20.30.40

successfully.

But its clinical application may need:

10.20.30.40:104

or another configured port.

If that port is blocked or the service is not listening:

The application still fails.

TCP

TCP stands for:

Transmission Control Protocol.

It is connection-oriented.

Before sending application data, two systems generally establish a connection.

TCP Reliability

TCP includes mechanisms for:

This makes it useful for many healthcare applications.

UDP

UDP stands for:

User Datagram Protocol.

It is simpler and does not establish the same type of reliable connection.

Some real-time or specialized systems use UDP.

Port Number

A TCP or UDP port is a number associated with a service.

Ports range from:

0 through 65535.

Well-Known Ports

Some services commonly use standardized ports.

But medical-device manufacturers may also use:

Never assume the correct port without documentation.

What Is a Firewall?

A firewall controls network traffic based on rules.

It may decide:

Allow

or:

Block

based on things such as:

Firewall Example

Rule:

Allow ICMP.

Result:

Ping works.

Another rule:

Block TCP port used by medical application.

Result:

Application fails.

This is a classic:

Ping works but device does not work

scenario.

Firewall Can Exist in Several Places

Possible firewall locations include:

Server Firewall

Even if the hospital network allows the traffic, the server itself may reject it.

Windows Firewall Example

Server responds to ping.

Application port blocked by local Windows firewall.

The network path is mostly fine.

The application still cannot connect.

What Is an Open Port?

An open port generally means a service is:

at that IP/port combination.

Closed Port

A closed port usually means:

The host is reachable, but no service is accepting connections on that port.

Filtered Port

A firewall may silently block traffic.

The sender may see:

rather than an immediate rejection.

Timeout vs Refused

These can provide clues.

Connection Refused

May suggest:

Timeout

May suggest:

But exact behavior varies.

Application Service

The server needs software actively listening for the connection.

Server Is On Does Not Mean Service Is Running

A server can:

while the medical-device service itself is stopped.

Example

Integration server:

Online.

Ping:

Pass.

Required interface service:

Stopped.

Medical devices cannot connect.

Restarting the Entire Server Is Not Always Necessary

Sometimes IT only needs to restart:

Troubleshoot at the correct layer.

DICOM Example

An imaging device may need to send images to PACS.

Configuration may include:

Ping to PACS Works

That proves:

Basic reachability.

DICOM Echo Fails

Now possible causes include:

Ping and DICOM Echo Are Different Tests

Ping:

Network reachability.

DICOM Echo:

DICOM application communication.

A successful DICOM Echo proves significantly more for an imaging workflow.

DICOM Storage Can Still Fail

Even if DICOM Echo works:

Image storage could still fail because of:

Again:

Each test has a boundary.

Central Monitoring Example

Bedside monitor:

But:

Central does not display monitor.

Possible causes include:

EMR Integration Example

Bedside monitor works.

Central station works.

Patient data does not reach EMR.

Ping to integration server works.

The problem might be:

The bedside network may be completely healthy.

MUSE Example

ECG cart:

Obtains IP.

Pings server.

Cannot transmit ECG.

Now investigate:

Do not stop at ping.

Remote Service Example

Manufacturer remote support cannot connect.

Device itself communicates normally with hospital systems.

This may indicate:

rather than device failure.

Direction Matters

Firewall rules can depend on direction.

A rule might allow:

Device → Server

but block:

Server → Device.

Initiator Matters

Ask:

Which side starts the connection?

This matters when working with IT.

Example

You may assume server connects to monitor.

Actual architecture:

Monitor initiates connection to server.

Firewall rule needs to permit that direction.

Source and Destination

When requesting firewall help, provide:

That is much more useful than:

Can you open the firewall for this monitor?

Port Range

Some applications use:

Check manufacturer documentation.

Do Not Ask IT to “Open Everything”

That is poor security practice.

Specify only what is required.

Cybersecurity Matters

Medical devices still exist inside a secured network.

Randomly disabling firewalls can create risk.

Coordinate with authorized IT/security teams.

VLANs and Ports Are Different

A VLAN determines logical network placement.

A TCP/UDP port identifies an application service.

They are unrelated concepts despite both using the word:

Port.

Physical Switch Port

Another use of the word “port” is:

Ethernet switch port.

So there are at least three common meanings:

Do not confuse them.

Physical Link Can Work While Application Port Is Blocked

That is exactly why:

can both look perfect while the clinical application fails.

DNS

Some devices connect to a server using:

Hostname

instead of raw IP address.

Ping by IP Works

But hostname fails.

Possible issue:

DNS.

Application Uses Hostname

If the medical application is configured with:

serverhospital.local

and DNS cannot resolve it:

Application fails.

Even though ping to the server's IP works.

Test the Same Destination the Application Uses

If application uses:

Hostname,

test hostname resolution.

If application uses:

IP,

DNS may be irrelevant.

Server Address Changed

A backend server may be replaced or migrated.

Device still points to:

Old IP.

Link and general network access remain fine.

Application fails.

Load Balancer

Larger systems may use a:

Load balancer

between device and server.

The IP the device connects to may not be the physical server itself.

That can complicate troubleshooting.

Network Address Translation

Some networks use:

NAT, or Network Address Translation.

This can make the address seen by one side different from the address used internally.

Biomeds do not usually need to configure NAT, but understanding that network paths can translate addresses helps when working with IT.

Multiple Servers

A medical system may depend on several servers.

Examples:

One can fail while others remain reachable.

“Server Is Up”

Ask:

Which server?

and:

Which service?

One Device vs Many Devices

This is one of the fastest ways to classify a problem.

One Device Fails

Other identical devices work.

Think:

Entire Unit Fails

Many devices simultaneously lose same service.

Think:

One Room Fails

Think:

All Devices Ping, None Connect

That strongly suggests something above basic IP reachability.

Possible areas:

Service Listening Test

IT may use tools to verify whether a server is listening on the expected port.

Biomeds may also have approved tools depending on environment.

The important concept is:

Can a TCP connection actually be established to the required service?

Telnet

Historically, technicians sometimes used Telnet as a quick test to a specific TCP port.

Example:

telnet server 104

If connection opens:

Port is reachable.

Modern systems may not have Telnet installed, and other tools may be preferred.

PowerShell

On Windows, IT may use commands such as:

Test-NetConnection

to check a specific destination and port.

You do not need to memorize every command to understand the concept.

Packet Capture

For deeper troubleshooting, IT may use:

to see packets.

Packet Capture Can Answer

This can clearly locate the failure.

You Do Not Need to Become a Packet Expert Immediately

A biomed should understand enough networking to ask useful questions and collect useful evidence.

IT can help with deeper network analysis.

Logs

Medical devices may log:

These messages can point toward different layers.

“Unable to Connect”

This is too broad by itself.

Look for:

Exact Time Matters

IT may need to correlate:

with the clinical failure.

Give them:

Failure occurred around 14:32.

not:

It happened earlier today.

Configuration Documentation

Before changing network settings, record:

This helps prevent creating a second problem.

Do Not Randomly Change IP Addresses

If ping fails:

Do not start assigning random static IPs.

You can create:

Firewall Change After Maintenance

A common scenario:

System worked yesterday.

Network/security maintenance occurs.

Today:

Devices ping server but application fails.

A firewall or ACL change becomes plausible.

But Timing Is Not Proof

It gives you a lead.

You still need evidence.

Software Update

Application software updates can also change:

A network path that worked before may no longer match the new configuration.

TLS and Certificates

Some modern medical applications use encrypted connections.

The TCP port may be reachable, but communication can still fail because of:

Ping Does Not Test Encryption

Again:

Ping is only a basic network test.

Authentication

A server may be reachable, but the device can fail authentication.

Examples:

Port Open Does Not Prove Full Application Function

Even successful TCP connection only proves:

You reached the service.

The application can still reject:

Think in Increasing Levels of Proof

Link Light

Proves:

Physical Ethernet link.

Valid IP

Proves:

Device has network configuration.

Ping Gateway

Proves:

Some local IP reachability.

Ping Server

Proves:

Some IP reachability to server.

Port Test

Proves:

Specific TCP service is reachable.

Application Handshake

Proves:

Application-level communication.

Successful Clinical Data Transfer

Provides the strongest practical end-to-end proof.

Real-World Example: Ping Works, Central Does Not

Monitor:

Link good.

Ping server:

Pass.

Port test:

Fails.

Firewall rule missing after network change.

Real-World Example: Port Open but Application Fails

CT:

DICOM port reachable.

DICOM Echo fails.

PACS application service misconfigured.

Network firewall was fine.

Real-World Example: One Device Fails

Ten monitors communicate normally.

One does not.

All use same server.

Problem monitor has wrong server port configured.

Real-World Example: Entire Unit Fails

Twenty monitors suddenly disappear from central.

All can ping server.

Central monitoring application service has stopped.

Real-World Example: IP Works, Hostname Does Not

Device configured with server hostname.

Ping server IP:

Pass.

Hostname resolution:

Fail.

DNS setting incorrect.

Common Mistakes

“It Pings, So the Network Is Fine”

Ping only tests limited network reachability.

Blaming the Firewall for Everything

A stopped service can look similar.

Asking IT to Open Every Port

Use documented requirements.

Confusing VLAN With TCP Port

They are different concepts.

Ignoring Server Services

The server can be alive while the required application is dead.

Testing the Wrong Destination

Test the server and service the device actually uses.

Changing Network Settings Before Recording Them

Document first.

A Useful Troubleshooting Framework

For a networked medical device that has link but does not communicate:

Does it have the correct IP configuration?

↓

Can it reach the gateway?

↓

Can it reach the required server?

↓

Can it reach the required application port?

↓

Is the server service actually running?

↓

Does the application handshake succeed?

↓

Does real clinical data transfer?

That takes you from:

Network

to:

Application

without guessing.

Another Useful Question

Ask IT:

Can you see traffic from this device IP to this destination IP and port at the time of failure?

That is much more actionable than:

The network isn't working.

What Did You Actually Prove?

If the device successfully pings the server:

You proved:

The device can exchange ICMP traffic with that server over the current network path.

You did not prove:

If a test confirms the required port is reachable:

You proved more.

If the actual medical application completes a successful transaction:

Now you have meaningful end-to-end evidence.

Final Thoughts for Biomeds

The phrase:

It pings.

should be the beginning of the next question, not the end of troubleshooting.

Think:

IP gets you to the building.

Port gets you to the door.

Application service is what has to answer.

A medical device can have:

and still fail completely at the function users care about.

So move through the layers:

Physical → IP → Port → Service → Application.

And every time one test passes, ask:

What did I actually prove?

— Jake

Important Note

Required network ports, protocols, firewall rules, authentication methods, server architectures, and cybersecurity requirements vary by medical-device manufacturer and healthcare organization. Use current manufacturer network documentation and coordinate firewall, VLAN, server, and security changes with authorized IT or cybersecurity personnel.

Related Biomed Basics

Back to Biomed Basics