Local servers

What it does: the Local servers tool stands up test servers on THIS machine (Syslog, SNMP-trap, TFTP, HTTP, FTP, DNS, DHCP, RADIUS, TACACS+, plus SFTP/SCP receive through your OS's OpenSSH server) so your gear can point at your computer instead of a real appliance.

Which IP: use THIS computer's IP address on the network the device can reach — normally your Ethernet or Wi-Fi adapter's LAN address (for example 192.168.1.50 or 10.0.0.5). The screen lists them under "POINT YOUR DEVICES AT THIS MACHINE". You do NOT choose an IP in the app: a running server listens on ALL of this machine's addresses at once, so you just tell the DEVICE which of them to use.

Do I need a management loopback or VLAN? No — not on this host. A loopback / management VLAN is a DEVICE-side idea: a router can use its Loopback0 as the stable SOURCE address for the syslog/SNMP it SENDS. That's configured on the device, not here. The machine running these servers just needs an IP on a network the device can route to.

The recipe: the device and this machine must reach each other (same subnet, or routed). On the device, set the destination (logging host, trap host, tftp server, dhcp helper …) to this machine's IP and the PORT on the server's card. Then make sure the firewall lets it in (see Firewall).

Firewall: on Windows the installer adds inbound rules for the standard ports and their high-port fallbacks (Private profile, for this app) — no prompt when you Start a server. The "Add firewall rules" button re-adds those same rules if they're missing (in a 'SubnetSlinger' group that uninstalling doesn't remove); for any other port, add an inbound rule in Windows Defender Firewall yourself. On Linux nothing is added: if firewalld or ufw is on, allow the port yourself (e.g. sudo ufw allow 5140/udp). FTP is passive-only and each listing or transfer opens a random high data port that no rule covers — from another machine, allow SubnetSlinger in Windows Defender Firewall (or the port range in ufw/firewalld), or use TFTP or HTTP instead.

Public networks: the Windows rules cover Private networks only — if Windows calls this network Public, nothing gets in. Set the network to Private (Settings ▸ Network & internet ▸ your connection) or add an inbound rule yourself.

Ports: the defaults ARE the real service ports — syslog udp/514, SNMP-trap udp/162, TFTP udp/69, DNS udp/53, DHCP udp/67, RADIUS udp/1812, TACACS+ tcp/49, FTP tcp/21, HTTP tcp/80 — because that is what network gear sends to. DNS and DHCP are fixed: real clients only use udp/53 and udp/67, and IOS 'ip name-server' has no port option at all. Syslog, SNMP-trap, TFTP, FTP, HTTP and TACACS+ can be pointed at another port on most gear — each panel names its high-port fallback (5140, 1620, 6900, 2121, 8080, 4949). RADIUS udp/1812 is already above 1024.

You can still edit any port here — do that when your shop runs a collector on a non-standard port, so SubnetSlinger matches your environment. What you should NOT plan on is repointing production gear at a high port to suit this app: changing a live device's logging or trap destination is a change against production config. Moving to a high port is only realistic for equipment you control — a lab, a bench, a staging rack, a site you're still building.

Admin rights: on Windows none are needed. Ports below 1024 are 'privileged' on some systems, but Windows has no such restriction: SubnetSlinger binds udp/514, tcp/49, udp/53 and the rest as a standard user. What Windows does require is a firewall rule to let the traffic IN — binding and receiving are two different permissions, and confusing them is a classic source of 'the server is running but nothing arrives'.

On Linux: a normal user can't bind a port below 1024, so use the fallback ports (Syslog 5140, SNMP-trap 1620, TFTP 6900, TACACS+ 4949, FTP 2121, HTTP 8080) — DNS (53) and DHCP (67) have none and can't run from the unprivileged app. Nothing switches port for you: if a low port is refused, the panel says so — type the fallback, press Start again, and point the device at that port.

Multiple adapters: if this machine has Wi-Fi + Ethernet + a VPN, the device must use whichever of the machine's IPs is on ITS path. Since the servers bind every interface, any of them works — just give the device the right one.

Security: DHCP answers ANY client that asks, so on a production LAN it becomes a rogue DHCP server — run it only on an isolated lab segment. Every server here has minimal or no authentication, so run them only on a trusted network and Stop them when you're done. While a server is running, anyone on that network can reach it.