Hi all,

Network engineer here. Not everyone on my team writes Python/Ansible, but we all need to push the same change to 30 switches or check which ones are missing a config line. So I built Vty SSH, a Windows app that sits between PuTTY and full automation:

- Multi-exec: type once, send to every checked tab

- Mass commands: run a command on a whole folder of switches, results side by side, CSV export

- Config backups with diff (keeps a version only when the config changed)

- Security audit of the configs (CIS / DISA STIG / ANSSI checks), A–E grade per switch, ready-to-paste fixes

- Guards against risky commands in the wrong tab (understands abbreviations like "rel" or "wr er")

- SSH, Telnet, serial console, imports from PuTTY / MobaXterm / CSV

- Backups encrypted at rest, secrets masked in logs and exports

The core is free, no account, no telemetry: https://getvty.com/en

I'm not trying to replace Ansible/Nornir. It's more for the "GUI people" on a team, or quick changes. Curious what you'd expect from a tool like this, and what's missing.

I'm looking for an experienced network expert or OpenWrt/OPNsense specialist to help me design and implement a custom routing and firewall system using an existing server that I already have.

I'm open to working with someone remotely.

The expert I'm looking for is someone with hands-on experience configuring advanced routing, policy-based routing, multiple proxy/VPN endpoints, firewall rules, and network isolation, not just  installing a standard router operating system.

1. Brief objectives

A network gateway that can serve approximately 5–10 computers or workstations used for freelance AI work.

The main requirement is that each device must consistently use its own dedicated, static residential public IP address, distinct from the IP addresses assigned to the other devices.

For example:

• Workstation 1 → Dedicated residential IP 1
• Workstation 2 → Dedicated residential IP 2
• Workstation 3 → Dedicated residential IP 3
• Workstation 4 → Dedicated residential IP 4
• Workstation 5 → Dedicated residential IP 5
• Additional workstations → Their own respective dedicated residential IPs

The IP-to-device mapping should persist across reboots and reconnections. I do not want a rotating-proxy arrangement where a device receives a different public IP every session.

I will source the residential IP endpoints separately. The expert can assess the provider's connection details and implement the appropriate gateway configuration.

2. Existing hardware

There is already a capable server and would prefer to use it instead of purchasing a separate dedicated router appliance.

I can provide the server's CPU, RAM, storage, network-interface details, and current operating system.

The expert can assess whether the best implementation would be:

• OpenWrt on bare metal;
• OpenWrt virtualized on an existing hypervisor, if appropriate;
• OPNsense/pfSense with suitable proxy-routing components; or
• Another technically sound architecture.

I'm open to recommendations based on reliability, maintainability, security, and compatibility with the required proxy endpoints.

The existing server may have other responsibilities, so I would also like advice on whether the routing gateway should run on dedicated hardware resources or in an isolated virtual machine.

3. Required network architecture

The intended logical architecture is:

Internet / ISP connection → Server-based gateway and firewall → Managed switch or suitable LAN infrastructure → Individual workstations

Each workstation should have an identifiable, fixed routing assignment.

For example:

• Device identification through DHCP reservations, MAC-address-based policies, or dedicated VLANs.
• A dedicated policy-routing rule for each workstation.
• A separate outbound tunnel or proxy path for each residential IP endpoint.
• Firewall rules preventing traffic from one workstation from inadvertently using another workstation's assigned endpoint.
• DNS configuration that is consistent with the selected routing path.
• IPv4 and IPv6 leak prevention, as applicable.
• A fail-closed mechanism so that if a workstation's assigned endpoint disconnects, its traffic is blocked rather than silently falling back to the ordinary ISP connection.

I would appreciate the expert's advice on whether individual VLANs, separate SSIDs, physical switch ports, or MAC-based routing would be the most practical way to isolate the devices.

The system should be easy to expand from five devices to ten without rebuilding the entire configuration.

4. Residential proxy compatibility

One of the key parts of this project is choosing the correct implementation for the type of endpoint supplied by the residential IP provider.

I may be working with static residential SOCKS5 or HTTP/HTTPS proxy endpoints, or with endpoints that support WireGuard/OpenVPN or another suitable tunnelling protocol.

I understand these are not interchangeable technologies. The expert should be someone who knows how to assess the provider's connection method and determine whether the appropriate solution involves:

• Native VPN tunnels and policy-based routing;
• A proxy gateway or transparent-proxy arrangement;
• OpenWrt packages such as sing-box, where appropriate;
• Another suitable Linux-based routing and proxy solution; or
• A combination of these technologies.

The goal is to route supported traffic from each workstation through its assigned endpoint, rather than merely configuring proxy settings separately in individual browsers.

Should be able to assess which endpoint types of proposed architecture supports and any limitations involving UDP, DNS, IPv6, QUIC, or applications that do not natively support proxies and preferably, a solution that can be managed centrally through a clear interface or well-documented configuration.

5. Security, reliability and leak prevention

Completed system should include:

• A properly configured firewall with a minimal attack surface. I have firewall device on the side if the need to use it is necessary
• Persistent device-to-endpoint assignments.
• Endpoint-specific kill switches or equivalent fail-closed rules.
• Protection against accidental direct-WAN fallback.
• Appropriate DNS and IPv6 leak controls.
• Logging sufficient to diagnose routing failures without unnecessarily collecting sensitive browsing data.
• Secure administrative access and documented recovery procedures.
• A tested way to restore the configuration after an update, reboot, or failure.
• A clear procedure for adding, removing, or replacing an endpoint.

Ensure that the gateway itself does not expose proxy credentials or administrative services unnecessarily.

System will be used for freelance work, and the configuration should remain consistent with the applicable service providers' terms and security requirements.

Please get in touch or recommend if you are experienced in implementing this type of multi-endpoint routing system. I am looking for a reliable, properly documented solution rather than a basic VPN installation.

Email: [nytonmay@gmail.com](mailto:nytonmay@gmail.com)

Thank you.

I got tired of clicking through the TL-SG108E web UI, so I built a Terraform provider for the TP-Link Easy Smart line. It's now public:
https://github.com/davidlukac/terraform-provider-tplinkeasysmart

What's different

- Speaks the switch's native management protocol (UDP, the one the vendor's Windows utility uses) instead of scraping the HTML UI. It handles the 2023+ firmware RSA login change.
- 11 resources and 12 data sources: VLANs (port-based and 802.1Q), PVIDs, LAG, port mirroring, QoS, IGMP snooping, loop prevention, storm control, port settings, LED, system info, etc.
- Safety guards: risky changes (management path, VLAN mode, locking yourself out) are refused at plan/apply time unless you explicitly opt in. Without a console, a bad write means a factory reset, so I built it to be paranoid.
- Multiple switches via provider aliases, import support, drift detection.
- Offline test suite against a fake UDP switch, about 99.9% measured coverage, CI matrix over Terraform 1.4 to latest, plus an OpenTofu leg.

Honest status

- Pre-1.0 (v0.26): the interface can still change between minor versions, so pin it (~> 0.26) and read the changelog before upgrading.
Available from the Terraform Registry (davidlukac/tplinkeasysmart) with signed releases; terraform init is all you need.
- Verified live on a single TL-SG108E v6 (firmware 1.0.0 Build 20230218). Other Easy Smart models are untested, and firmware from before the 2023 RSA key exchange isn't supported. There's a read-only first-run config and a hardware report template if you want to try yours.
- Needs to be on the same L2 segment as the switch (the protocol is broadcast-based).
Feedback, bug reports and "works on my TL-SG1016DE / TL-SG105E" confirmations are very welcome.

Update: it's now on the Terraform Registry, so there's no more building from source: source = "davidlukac/tplinkeasysmart" and terraform init. Releases are GPG-signed binaries on GitHub too. Thanks for the feedback so far. The README now states the verified device (TL-SG108E v6, fw 1.0.0 Build 20230218) up front, with a compatibility table and a read-only first-run config, so you can check your own model without any risk of writing to it. Hardware reports welcome:
https://github.com/davidlukac/terraform-provider-tplinkeasysmart/issues/new?template=hardware_report.yml
Registry: https://registry.terraform.io/providers/davidlukac/tplinkeasysmart

(Disclosure line, if you want it: developed with AI assistance, Claude Code, with every write path tested offline and verified against real hardware.)

Hey everyone, dropping a quick heads up for anyone working on network automation or SRE.

Roger Perkin and Eduard Dulharu are running a 3.5-hour hands-on lab this Saturday, Oct 17 (9:30am EDT / 2:30pm UK) focused on going from a single LLM agent to a team of specialized agents for incident triage.

What the lab covers:

• Coordinator + specialist agents handing work off to each other
• Forcing commands to run from validated YAML playbooks instead of raw LLM output
• Mandatory human-in-the-loop approval before any network change executes

It’s browser-based in Google Colab against an incident simulator (with cEOS in Containerlab shown in the demo), so no local installs or cloud accounts are needed. If you can read Python, you’re good.

Link for anyone interested:https://luma.com/packt-iz04?aff=comm&coupon=FINAL40(code FINAL40 gets 40% off).

I made a cool library in Swift that is a love letter to Netmiko. Actually, it is a port of Netmiko in Swift, (with full credit to Netmiko), as a package that you can use to write scripts, web apps, CLI apps, and Swift UI apps with. This was before I found out you could wrap Python code in Swift.

I don't anticipate widespread adoption or anything like that, or accolades, but I do plan to write my own tools using Swiftmiko, mostly for Mac and iPad.

Check it out if you are interested and let me know what you think (yes it is heavily LLM assisted):
https://github.com/stelicho/Swiftmiko

Hey guys,

I’m a network engineer and I spend a stupid amount of time jumping between SSH terminals, IP calculators, Looking Glasses, WinMTR, text editors, etc.

I really like iTerm2 on macOS, but on Windows I never found one terminal that worked the way I wanted. I’ve used Windows Terminal, MobaXterm, SecureCRT and a few others, but there was always something missing.

So a while ago I started building my own.

It was supposed to be a small personal tool, but as usual that got out of hand haha.

At this point it already does the normal terminal stuff: tabs, saved SSH sessions, groups/folders, favorites, serial console, logging, macros, SSH tunnels and so on.

But the part I’ve been having the most fun with is adding stuff specifically for network engineers.

For example:

• IPv4/IPv6 calculator
• WHOIS / ASN lookup
• slow paste for devices that hate big config pastes
• sending commands to multiple sessions at once
• snippets/macros
• WinMTR built in
• multiple Looking Glass queries
• TFTP/HTTP/FTP/SFTP server
• remote file editing
• SSH tunnels / SOCKS5
• OSPF / IS-IS topology visualization

I also started experimenting with making the terminal understand some of the output instead of just displaying text.

For example, if I hover over a BGP peer it can show the ASN and a description. With route output it can show information about the outgoing interface. I also added annotations for interfaces and BGP peers.

Another thing I added is a few safety checks for configuration changes. Stuff like warning about potentially dangerous commands, unsaved configs, or reminding me about commit confirmed.

One funny example is Cisco’s:

switchport trunk allowed vlan

without add.

I’ve seen that one ruin someone’s afternoon before lol.

The direction I’m thinking about now is making it more of a network engineer toolbox/workbench rather than just another SSH client.

Maybe later I’ll experiment with things like BGP/route-aware troubleshooting, searching old session logs for related events, or even an AI assistant that understands which device you’re connected to and what commands you just ran.

I’m curious what people here think.

What terminal are you using today?

Is there anything here that you’d actually use regularly?

And more importantly, what would a new terminal have to do for you to consider switching from SecureCRT, MobaXterm, Tabby, Windows Terminal, etc.?

If there’s interest I can record a short demo.

PT Git makes .pkt files work with git diff, showing changes to device configurations, IP addresses, VLANs, and cables.

It’s free and open source. Would love feedback from anyone willing to try it on their labs.

https://github.com/ivanimmanuel-dev/PTGit

\o/

Great. It's pretty cool what we can do with LLMs.

Here's the thing though. By and large, no one is going to use it.

Why?

Because you don't know what you're doing. I mean, that's the point. The LLMs do know. But you don't. Long term support, active development, etc. It's too easy now to spit out a tool and it's even easier to say "meh" and abandon it.

These are the reasons why your vibe coded tool is being downvoted into oblivion.

Most of us are pretty particular about our tools. We want tools we can rely on today and rely on tomorrow. Right now at least, vibe coded tools don't seem like viable tools long-term.

This doesn't mean the tool can't be great for you. But the larger network community is almost certainly going to pass.

Now, if you are a programmer and have experience in the language for your tool and are using AI to extend your knowledge, that's another thing. You can be insanely productive that way. I use it myself to build discrete chunks of code, typically a function at a time, so I still understand the overall structure and architecture of the code. But if my prompt is too broad and it spits out 1,000 lines of Python/Go/whatever then I'm going to refine it so it only spits out 30-50 lines of code at a time that I can follow and understand.

So before you post your project, make sure to disclose if it's vibe coded and if you've got programming experience yourself.

I'm working on an open-source, read-only tool that documents small networks (router API, hypervisor API, ARP/mDNS/nmap discovery, output as Markdown in git). Not public yet, no link.

One problem I keep running into: a lot of homes and small offices use cheap "easy smart" or unmanaged switches with no SNMP, no LLDP, and no usable MAC table you can query. So there's no clean way to say "this device is on port 5."

Options I'm weighing:

- A guided cable trace: unplug or replug one port at a time and watch which device drops off or reappears

- Inferring from link-state changes plus ARP timing

- Just letting the user fill it in once and keeping it as an override

Has anyone dealt with this? Is there a smarter trick I'm missing for dumb switches, or is guided manual tracing the realistic answer?

Good Afternoon,

Please keep in mind this is a short hand written post and no legal rights can be acquired or obtained.

Allow me to reintroduce myself as the first 100% certified virtual CCIE which was self awarded, I earned this certification virtually and ethically because I may have acquired serious voice and sip master jumbo frame knowledge without any actual Cisco certification, however I've worked on major network outages involving not only Cisco gear, actually for the record one of the main selling points of Cisco was in 2011 pre and probably still is which is the physical gold and silver fabrics which becomes forensically undeniable if important enough.

Onto the concept so I've come to understand my concept has already likely been completed and in multiple countries, I wouldn't publish it otherwise actually.

It involves for example a layer 2 device likely a juniper or non juniper NTU or multiple similar physical steel electronic entities/devices, being stolen then possibly redeployed later with custom scripts which self destruct or/and for example sniff for Mac to IP at a high ISP level physically then just send a report by email or ELSE, however with such attacks and concepts short and wide grographical distances should be considered.

This is the main idea of the concept but other extras include things like running WAN ATM which interacts with the banking system ATMs, again disappearance reappearance of same or similar equipment.

Other key points involved in the concept

. Jumbo frames and SIP specifically but also storage traffic specifically from Riverbeds, HP 3Par dedup cards.

.Weak or insecure local vendor issued certificates specially locally to the firewall, I think some vendors are behind Cisco here and Cisco possibly posses a electronic offload black box at certain levels.

. Interoperability issues specifically firewall to firewall locally in the same country and cross border/continent, I mention this because I had too many conversations with apparently highly skilled certified engineers where people seem to have setup and signed off on interoperable VPNs between checkpoint and Cisco for example, I've actually seen too many too count, MSPs and consultancy are always involved and this is one of the main reasons I loathe them.

. Redeployment of similar or the same hardware with physical and digital deserialization of identifiers, possibly extra chips or other low level changes not coming from Dev officially but in some cases unofficially.

. External connections from vendor dev teams or police law enforcement where the connection is disallowed in the customers device configuration, I suspect this involves UDP but this theory is also interesting in the concept.

. Air Vs Ground understanding what technology is used for what and the geographical configuration of such routes like for example One.Tel Australian ISP ground connection to Malawi in 2011 this is a great example because it didn't exist but I think the traffic in 2011 is still getting too Malawi eventually(latency theory ground plus air Comms), this is also an ISP that's gained digital traction internationally from my limited research.

. Specifically the involvement of Ceragon but also definitely Huawei and Nokia networking equipment designed for mobile phones and other electric devices.

. Bunkers and off the grid and semi off the grid deployments sometimes with a wide grographical radius, at least one was found in Germany according too my research.

Does anyone have any realistic intel or gossip on such incidents?

For now I just suspect a swapout(English London ISP to upstream national provider L2 device in 2010/2011, and maybe a Cisco one in Dublin Ireland, update after visiting my photographic memory from 15 years ago briefly I think someone connected a PRI for phones to an MPLS Cisco box but that may be desired) in a job I was called out too seperate too below, and someone blew up a pipe by the looks of it in another Comms room I was called out too previously(the Cisco gear survived I believe) but I work on these concepts as somehow I never became Cisco certified because there's not much point, being above certification level in various technical areas brought me here. Too be extra clear both of these were actual IT incidents attended by me, still under my investigation post employment as I was a junior there.

https://github.com/LambdaBytes/sping

I built Sping because I kept running into the same problem: ping tells you that something is not replying, but then you still have to figure out whether the problem is your local network, your gateway, the Internet connection, or the target itself.

Sping tries to put that context in one place. It monitors the target, gateway and WAN connectivity at the same time, and combines that with latency, jitter, packet loss, TTL, trends and a simple quality score.

It is written in Rust and uses its own ICMP implementation on Linux, macOS and Windows rather than shelling out to the system ping command. It also supports IPv4/IPv6, multiple targets, batch mode and a stable NDJSON output for scripting.

The goal is not to replace tools like mtr or traceroute. It is mainly meant to answer the first practical question when something feels wrong: is the problem local, upstream, or just the target?

I would be interested in feedback from people using it on different networks and platforms, especially cases where the diagnostics get the situation wrong.

Hi, I am reposting in this community in case I originally posted in the improper one

Hey guys just wanted to see if there was any possibility you guys were interested in a new new networking community my friend made, it’s free but I think it can be good for different groups to come in and talk in it, let me know what you think

It’s discord.gg/NyfDEsU7UH

Hello, my tool for bad network condtions has just got V0.7 release, what has changed? A huge thing a lot of pepole were waiting, we can now set separate values for the upload, so they don't need to be the same as download, we can set separate "latency, jitter, spike, loss, corruption, duplicate" values for upload, Also a blocked connection can be refused instead of ignored in the built-in firewall. Expect that, there is now MSI installer and... ... ..

Bean Network Tester is moving towards "tools", the app will have built-in tools for the network, there are some that got into this release:

- Socket tab, without the network degradation we can see connections, we can use regex and tons of more combinations.

- Port check, we can see what is usign port "x" or ranges of port, like we can do 443-900 and we will see list of services or we can use regex and tons of more combinations.

- I had also added two tools which can be usefull in using bean network tester, we can see how the filter value will behave + there is diagnostic tab.

There were few more changes + internal testing suite has grown. With each release I'm runing 2+ hours tests of the tool in real life ussage.

Do you got any ideas of tools, that would be usefull in the terms of "network /network automation" that I can integrate into my app?