Send SMS via SMPP When Port 2775 Is Blocked by Your ISP
SMPP (Short Message Peer-to-Peer) runs on port 2775. Countless ISPs, cloud providers, and corporate firewalls block that port outright no warning, no error, just a silent connection timeout. If your SMS gateway is sitting behind one of those networks, your application can't reach it no matter how perfect your configuration is. This guide walks you through tunneling SMPP traffic over a Localtonet TCP tunnel so your application connects reliably regardless of what your ISP blocks.
Why SMPP Connections Fail Behind Firewalls
Port 2775 is a non-standard port that most ISPs have no reason to keep open. It's not HTTP, not HTTPS, not SMTP so it gets dropped at the network level without a RST packet or any useful feedback. Your SMPP client sits there waiting for a response that will never come, and eventually times out. The same happens on many cloud VMs, corporate office networks, and shared hosting environments where egress filtering is aggressive.
The obvious fix opening the port on the firewall only works when you control every hop between your app and the gateway. If your client is behind a carrier-grade NAT or a managed corporate network, you don't have that option. Switching to a VPN sometimes helps, but introduces routing complexity and often gets blocked too.
A TCP tunnel punches through the restriction by wrapping your SMPP traffic inside an outbound connection on a port that is already allowed, then delivering it to your gateway on the other side.
How a Localtonet TCP Tunnel Solves This
Localtonet creates an outbound persistent connection from the machine running your SMS gateway to Localtonet's relay servers. That connection uses standard HTTPS ports, which almost nothing blocks. When your SMPP client connects to the public Localtonet address, the relay forwards the TCP stream to your gateway as if it were a direct connection on port 2775.
Your gateway software never changes. Your SMPP client never changes its protocol. The only
thing that changes is the host and port your client connects to: instead of
gateway.example.com:2775, it connects to something like
tunnelxyz.localto.net:12345. From that point, the tunnel handles everything.
No inbound ports need to be open on the gateway machine. No router NAT rules. No static IP on the gateway side. The tunnel client on the gateway machine makes an outbound call and holds the line.
How to Tunnel SMPP Port 2775: Step-by-Step (2026)
Create a free Localtonet account
Go to localtonet.com/register and sign up. No credit card required for the free plan.
Copy your user token
Go to localtonet.com/usertoken and copy your token. You'll use this to log into the Localtonet Client in the next step.
Download and install the Localtonet Client
Download the Client for your platform from localtonet.com/download. Install it on the same machine (or same LAN) as your SMPP gateway process. Works on Windows, Linux, macOS, and Docker.
Log into the Client with your token
Open the Localtonet Client and enter the token you copied from localtonet.com/usertoken. The Client connects to Localtonet's infrastructure and stays running in the background. No further CLI interaction is needed.
Create a TCP tunnel from the dashboard
Go to localtonet.com/tunnel/tcpudp
in the dashboard. Choose a server region closest to your SMPP clients, set
Local IP to 127.0.0.1 and Local Port
to 2775, then click Save.
Localtonet assigns a public relay port (e.g. 38412) immediately.
Note the full address shown, something like tunnelxyz.localto.net:38412.
Type : TCP
Server : (pick the region closest to your SMPP clients)
Local IP : 127.0.0.1
Local Port : 2775Start the tunnel from the dashboard
Back in the dashboard, click the Start button next to the tunnel you created. The tunnel goes live and your public relay address starts accepting SMPP connections. All further management stop, restart, region change is done from this same dashboard view.
Point your SMPP client at the tunnel address
Open your SMPP client configuration and replace the gateway host and port with the Localtonet relay address. The system_id, password, and all other bind parameters stay exactly the same.
host=gateway.example.com
port=2775
system_id=myapp
password=secrethost=tunnelxyz.localto.net
port=38412
system_id=myapp
password=secretVerify the bind and send a test message
Connect your SMPP client. You should receive a bind_transceiver_resp (or
bind_transmitter_resp) with command_status=0 within 1–2 seconds.
Send a submit_sm and confirm delivery on the gateway side.
SMPP sessions use enquire_link PDUs to detect dead connections. The default
interval in most clients is 30–60 seconds. If your tunnel relay has an idle-connection
timeout shorter than this interval, the TCP connection is silently closed and your bind
drops without any SMPP-level error. Set your SMPP client's enquire_link_interval
to 20 seconds or lower and confirm the gateway responds with enquire_link_resp.
This is the single most common cause of "works for a few minutes then stops" on tunneled
SMPP connections.
Some SMS gateway software lets you move SMPP to a non-standard port (e.g. 3775, 5775) to
avoid the ISP block on your server's outbound connections. If your gateway already listens
on a different port, change Local Port in the Localtonet tunnel config to match
that port. The public-facing tunnel port assigned by Localtonet is independent of the local
port you can map any local port to any public relay port.
Tips for Running SMPP Tunnels in Production
Frequently Asked Questions
Does the tunnel work for both SMPP transmitter and transceiver binds?
Yes. Localtonet forwards raw TCP bytes without inspecting the SMPP session type. Bind as transmitter, receiver, or transceiver all three work identically through the tunnel. The bind type is negotiated directly between your client and the gateway; the relay is transparent to it.
Can I tunnel SMPP over port 2776 (the TLS variant) as well?
Yes. Create a second TCP tunnel with Local Port: 2776 and Localtonet will assign a separate public port for it. The tunnel treats TLS-wrapped SMPP exactly the same as plain SMPP it's still raw TCP bytes from the relay's perspective. Your client handles the TLS handshake end-to-end.
What happens to active SMPP sessions if the tunnel client restarts?
Active TCP connections through the tunnel are dropped when the client restarts. Your SMPP client will receive a connection reset and must rebind. Most SMPP libraries have a reconnect-on-error option make sure it's enabled. The tunnel itself comes back up in under 5 seconds on a normal restart, so the outage window is short.
My SMPP bind succeeds but submit_sm gets no response. What's wrong?
This is almost always an enquire_link timeout issue described in the warning above, or a gateway-side IP restriction. Check that your gateway's IP allowlist includes the Localtonet relay server's IP. You can find the relay IP with nslookup us1.localtonet.com (replace with your relay host). Add that IP to the gateway's allowed SMPP sources.
How many concurrent SMPP connections can pass through one tunnel?
Localtonet TCP tunnels support multiple concurrent connections on a single tunnel. For high-throughput SMS platforms that maintain 5–10 simultaneous SMPP binds, a single tunnel handles all of them. If you hit throughput limits, splitting across two tunnels (each bound to a different gateway listener) is the standard approach.
Is it safe to send SMS message content through a Localtonet tunnel?
The connection between the Localtonet client and the relay server is TLS-encrypted. For additional end-to-end security, use SMPP over TLS (port 2776) so message content is encrypted before it enters the tunnel. Plain SMPP (port 2775) through the tunnel means content is encrypted between your gateway machine and the relay, but decrypted at the relay endpoint the same trust model as any reverse proxy.
Does this work if the gateway is on a different machine on the same LAN?
Yes. Change Local IP in the tunnel config from 127.0.0.1 to the LAN IP of the gateway machine (e.g. 192.168.1.50). Run the Localtonet client on any machine on that same LAN and it will forward incoming SMPP connections to 192.168.1.50:2775.
Can I use this on a Docker container running an SMPP gateway?
Yes. Add the Localtonet client as a sidecar container or run it inside the same container. Set Local IP: 127.0.0.1 and Local Port: 2775 if the gateway is in the same container, or use the Docker bridge network IP if it's a separate container. The Docker-specific download is available on the download page.
Ready to get your SMPP gateway online?
Create a free Localtonet account, set up a TCP tunnel in under 5 minutes, and send your first message through the tunnel today. No credit card required to start.
Get Started Free →
