NAT has crippled the Internet. We are permanently dependent on public facing servers to route packets from one device to the other.
This service is absolutely not needed in a non-NAT world. And I strongly believe we have lost a lot by being completely dependent on client-server model of Internet.
I'm probably missing something, but I think that, for home networks at least, NAT is wonderful because of how it requires some effort to make devices exposed on the external network. If we were given an unlimited supply of IP addresses from the ISP and all devices were accessible externally, it seems security issues in would be a much larger problem.
The original purpose of NAT was to get additional devices connected to Internet since we had shortage of Ipv4 addresses. For security, we have firewalls. If we had not been dependent on NAT for security, firewalls would have been actually configured. We will have to configure firewalls with ipv6 anyway.
NAT arose long before any address shortage concerns. Rather it was a response to ISPs attempting to charge "per user" by associating a fee with each additional address (note this is long before residential ISP service we know today: Internet service was for businesses with retail subs only having ppp access via dialup). NAT allowed customers to work around the ISPs pricing model at the time.
When my family first got broadband via Comcast@home back in the early 2000s they had a proviso saying if you wanted more then one computer required a separate subscription. My dad and my bother quickly figured out we could get around this by using Windows Internet Connection Sharing. We eventually got a Linksys Router that did the same job and was faster. IIRC even most dial up ISPs did the same thing, if you wanted more then one computer online you had to use separate creds.
> If we were given an unlimited supply of IP addresses from the ISP and all devices were accessible externally, it seems security issues in would be a much larger problem.
Nearly 40% of US traffic is already IPv6. 40% in Germany, 30% in Japan. I haven't heard of any massive increase in security issues caused by every device getting its own IP address.
> There is no need nor benefit to have a per-device unique address advertised to the world.
Yes, there is!
But possibly more importantly: There is no benefit to assigning devices ambiguous addresses. It's as sensible as having all rooms in your business have "1" as their room number because you somehow have convinced yourself that that prevents people from entering your building.
The benefit of not having addresses collide. I mean, that's the whole point of assigning globally unique addresses?
When you connect some previously unconnected networks (a merger, or simply access for some sort of cooperation, or for maintenance access, or whatever), it's a nightmare with RFC1918 when address ranges overlap, which they invariably do. If you use globally unique addresses, you can be sure that there will be no problem.
When you debug something, you don't have to figure out what maps to what where in the network. When two machines talk to each other, the packets are labeled with the IP addresses of those two machines and the ports they are using, no matter where in the network you investigate. No matter who writes a log file about some operation happening in the network, all of those log entries are labeled with the same, uniquely identifying addresses.
And on the other side, there is still exactly zero benefit to using ambiguous adresses.
There are plenty of benefits and/or use-cases for having each internet connected device have it's own unique address. If not just for nonrepudiation, the elimination of NAT hardware and complexities is a plus as well.
If you're not talking about security, maybe you should be?
How big of an security issue is the NAT hardware and complexity? And is it not absolutely dwarfed by ipv6 hardware+configure complexity? (not to mention maturity).
The benefit is to eliminate the disadvantages and complexity (however opaque) of running NAT.
I don't think anyone is suggesting that all devices be reachable by default. It's entirely reasonable and prudent to have a firewall between my home network and the world, but NAT is not strictly required for this.
For privacy, you can setup your OS to require a different random IP every time it reconnects to the network. You will always be in the same /64, but with a different IP.
Do you use incognito windows for each website you browse and close them before opening a new one? Do you disable cookies completely?
If not, using NAT doesn't add much privacy for "ongoing session".
Also, how many people share your internet connection? If it's a handful, like most household, your one in a handful, pretty small area. If that's a concern to you, you should use a VPN.
And there are other techniques than closing all incognito windows for each site ... Surely you recognize the difference between uniquely identifying a machine from that?
Again, at this point, use VPNs, ephemeral ssh hop VMs on AWS, Vultur, etc...
For day to day usage, I'm fine with a given IP on a /64. If the police came to find who ssh'ed through NAT from my ISP provided ipv4, it wouldn't take them very long to figure out my wife and kids can't even spell ssh!
Not really a solution to the systemic issue of giving facebook a unique id per device for everyone on the planet. I'm also not just talking about my personal setup. A VPN wouldn't be a satisfactory solution to either.
You know Facebook buys your purchase history from Credit Card companies, right? Disable ad blocking when you go to Facebook, you'll find out they know way more about you than explainable by ip address and email tracking (and now we now purchase history).
If you chose to use Facebook and credit cards, you have bigger privacy problems than non-NATed ipv6!
NAT is definitively not a security layer and was never intended as such. You can get better security with a simple stateful ingress firewall (block packets not associated with an established/related connection) which is what most people think of for security with NAT.
The only slight benefit it has imparted is the privacy benefit of hiding multiple devices behind a single address, but they can usually be individually profile anyway.
I've heard before that "NAT is not intended as security", but isn't the effect still the same, that an external device can't connect to a device behind NAT without explicit configuration allowing it?
That is generally true, but has weird edge cases. For example using not so specially crafted ICMP packets[1] two hosts each behind independent NATs can communicate with each other without any change to a firewall configuration.
Also honorable mentions: The UPnP protocol & STUN servers
Server sends constant icmp pings with fixed payload to unreachable dead Internet IP. Client sends icmp time exceeded message to server containing original fixed ping subpayload, which the server NAT lets through because the payloads match as related traffic. Server then learns client IP and usual chownat udp hole punching tricks apply.
I find this argument to be completely ridiculous, and it’s become remarkably common among those who wish to justify some of IPv6s shortcomings. Whether it was designed to be a security control or not, it is one, and it’s an incredibly important one. Anything that controls how hosts are allowed to communicate with each other is a security control. The argument is so absurd that I literally can’t believe people go around parroting it.
It allows you to connect a private network to any other network, including the internet, without allowing hosts on that network access to hosts on the private network. It’s a form of access control. What is your justification for saying that access control measures are not security controls? That is so incredibly contrived.
> It allows you to connect a private network to any other network, including the internet, without allowing hosts on that network access to hosts on the private network.
So, how does it do that?
> What is your justification for saying that access control measures are not security controls?
I am not saying that. It simply isn't an access control measure.
By rewriting the IP headers of packets as they traverse routing devices. If you’re trying to say that all NAT devices are stateless firewalls, then your point is even more contrived than I first thought.
> It simply isn't an access control measure.
Then why can’t other internet connected devices connect to my internet connected laptop? If I’d connected my laptop directly to my ISP then they would be able to. But I didn’t do that, I connected my home router to my ISP, and I connected my laptop to my home router, which is providing access control for me.
> Then why can’t other internet connected devices connect to my internet connected laptop?
Some of them can. For example a device in the ISP network that can deliver a packet directly to your router's WAN interface can connect to your LAN devices in the absence of a firewall that would drop them.
As an example consider this:
A packet from src 10.10.10.10 to dst 192.168.1.1 arrives on the WAN interface. There are no firewall rules that match and the NAT is stateless. The router looks at the route table and sees a route for 192.168.1.0/24 on the LAN interface. It puts the packet on the LAN interface and calls it a day. Since 10.10.10.10 was a device on the same ISP network segment/broadcast domain as your router's WAN interface, it just reached a device in your NATed LAN.
On the campus LAN we used as a best practice to drop all packets that arrived on the WAN interface with a destination to the private LAN IP range, that had no entries in the state table.
Why would the ISP's network deliver a packet to the customer despite that packet having an IP address that doesn't match the IP address the customer leased?
Does this require an adversary who is or who compromises the ISP, possibly by tapping into the coax/fiber/etc in the last mile or by pwning the related nodes?
> Why would the ISP's network deliver a packet to the customer despite that packet having an IP address that doesn't match the IP address the customer leased?
It wouldn't under normal circumstances, but could in the case of a misconfiguration or a malicious actor.
> Does this require an adversary who is or who compromises the ISP, possibly by tapping into the coax/fiber/etc in the last mile or by pwning the related nodes?
Most likely. I also don't consider the scenario likely, because most NATs/firewalls are stateful in this day and age and if the ISP is compromised the attacker could also use TR-069 to upgrade the firmware on the custormer's router and place a malicious implant⁰.
Well, it is unlikely in practice because home access routers usually come with a stateful firewall. The important point is that that doesn't change when you remove the NAT. And that is important because people come to all kinds of nonsensical ideas about how IPv6 is dangerous or what you should do to make it less dangerous because you typically don't have NAT with IPv6.
Like, that you should use ULA and NAT with IPv6 so you don't lose the great security benefits of NAT. That is a completely logical conclusion if you believe that NAT provides security benefits. But it's just wrong.
And, yes, TR-069 is also a potential attack vector that you probably also should prevent in any halfway serious business context. Giving your ISP('s infrastructure) access to your internal network probably is not a good idea, no matter what the mechanism is.
> By rewriting the IP headers of packets as they traverse routing devices.
How does that prevent hosts on that other network from accessing hosts on your "private network"? Like, a packet addressed to one of the hosts on your "private network" arrives at your NAT gateway from the "other network". How does the NAT rewrite the IP headers, and how does that provide access control?
> If you’re trying to say that all NAT devices are stateless firewalls, then your point is even more contrived than I first thought.
Even that would not be contrived. If removing the NAT function does not change the security functions of a router, then the NAT obviously does not provide security, at best it implies the presence of certain security functions. But even that just isn't the case.
> But I didn’t do that, I connected my home router to my ISP, and I connected my laptop to my home router, which is providing access control for me.
Then that presumably is because your home router provides access control? What does that have to do with NAT, though?
Because without NAT, none of the devices on my home network would be able to connect to any internet connected hosts. That is, unless I assigned internet routable addresses to their network interfaces. If I did that, I’d either have to install firewalls on my devices, or expose all services running on my devices to the internet. But I don’t have to do that, because my home router uses NAT to allow all devices on my home network to connect to the internet, without allowing other devices on the internet inbound access.
If you have a point to make, then explain what it is. If you’re just gonna keep asking more contrived questions then I’ll presume you’re simply trolling.
So you can replace the security controls provided by NAT with security controls provided by a firewall. How does this support the argument that NAT doesn’t provide any security controls?
The point is that IP doesn't work how you think it works, but I have no clue what exactly your misconception is, so I don't know what I need to explain to you to make you see the error in your reasoning.
And unfortunately, you don't even answer my questions, instead just hand-waving your way through the explanation, ignoring all the details that would show where your misunderstanding lies.
In any case, no, if you only remove NAT from your home router that also has a stateful firewall, nothing changes security-wise. It just doesn't. No need to install firewalls on all your devices or anything like that, having a firewall on your uplink router is still perfectly sufficient for that without NAT.
And if your home router really only does NAT, without a stateful firewall that prevents inbound connections, then no, your NAT-only router does not prevent inbound access to your home network.
I understand that you believe otherwise, but your belief simply is incorrect, but you won't be able to understand why if you don't dive into how a NAT gateway actually works instead of hand-waving your way through the explanation.
NAT - regardless of firewalls or anything else - requires explicit config to allow packets to a host behind NAT. That’s is a security feature. Carrier grade NAT makes that even clearer. Note - I’ve configured non Firewall NATs - still requires explicit config. Some load balancer are basically non firewall NATs
For one, that does not strictly follow, because you can use NAT with globally routable addresses on your home network.
But in any case, the implied assumption was that you also switch to globally routable addresses for all your devices/that we are possibly talking about IPv6, where that would be the norm anyway. The point is that actually usable internet connectivity without NAT and with a stateful firewall has exactly zero differences security-wise vs. a setup that uses NAT and a stateful firewall. That is, except for the fact that all those misconceptions that people have about NAT can make people think that their network is secure when it is not, simply because they have NAT--if you don't have NAT, you can not mistakenly believe that it protects you against inbound connections.
No, NAT does not prevent connections, it only rewrites addresses. If your NAT router also has a stateful firewall, that is what prevents inbound connections, and removing the NAT from that equation does not change that.
The point is NAT is actually a couple of rules in router's stateful firewall, it is done by firewall, and firewall can't do it without explicit configuration. There can't be 'default allow NAT' config.
... which doesn't change that that "default allow" firewall will still pass through all packets, and thus allow access to all your internal devices/machines? Absence of NAT rules does not prevent packets from passing through the firewall, it only prevents rewriting of addresses.
The point you were objecting to was "external device can't connect to a device behind NAT without explicit configuration". Without NAT rules access to internal devices is prevented because packets don't get routed to private IPs.
That just isn't the case, though. A router without NAT and without a firewall (or a combined NAT/firewall thingy with default allow and no further rules) will route packets addressed to "private addresses" just fine. An IP router does not distinguish between "private addresses" and "non-private addresses": As long as there is a route for a prefix in the routing table, the router will route packets addressed to that prefix, and your typical home router most definitely does have a route for your LAN prefix.
So your example depends on the incoming packet already being addressed to a device behind the home router, which in a home network is in a private range. Thus, your example depends on the ISP's network delivering a packet to the customer despite that packet having an IP address that doesn't match the IP address the customer leased. Do you agree, and if so, do you know that this has ever happened in a residential setting?
Or do you mean an adversary who is or who compromises the ISP, possibly by tapping into the coax/fiber/etc in the last mile or by pwning the related nodes?
> Do you agree, and if so, do you know that this has ever happened in a residential setting?
I agree, apart from the claim that the home network is necessarily in a private range. For one, it's not technically necessary, you can use NAT with globally unique and globally routable addresses on the "internal" side. Obviously, people rarely do that with IPv4, but those people who promote the idea that NAT is somehow a security mechanism also use that claim to promote the idea that either IPv6 is bad because it doesn't use NAT, or that you possibly should use NAT with IPv6 ... which is where these misconceptions lead to some pretty crazy results.
> Or do you mean an adversary who is or who compromises the ISP, possibly by tapping into the coax/fiber/etc in the last mile or by pwning the related nodes?
Well, those are obviously attack vectors, and certainly not ones you should ignore, given how often there are all kinds of vulnerabilities being found in network equipment, including but not limited to the regular hard-coded passwords in Cisco equipment.
But, yes, there absolutely have even been publicly known cases of where this kind of access would have been possible, from ISPs that forgot to disable RIP on the customer-facing side of their routers, thus propagating some customer's RFC1918 routes into their access network (obviously kindof a configuration fuckup on that customer's side as well) to other ISPs that put multiple customers into a common ethernet segment/VLAN, so you could talk to your neighbour's router's WAN interface if you were a customer of the same ISP.
In any case, if you are responsible for the security of your network, your security boundary most definitely should be in your router, not somewhere in the ISP's network, where nothing of that sort is even legally guaranteed.
If there is no entry in the state table, then NAT rules are consulted to see whether a new rewrite entry should be added (such as DNAT/port forwarding rules on your home router), and if there is no matching rule either, it simply is forwarded without address rewriting.
Why would it be forwarded? Do you mean that it forwards it to itself, the NAT device addressed by the actual public IP? Wikipedia seems to disagree [0] "if the destination port number of the incoming packet is not found in the translation table, the packet is dropped or rejected because the PAT device doesn't know where to send it."
I am sure a NAT could be configured any number of ways, though, and could probably do anything you want with such packets.
Because the device is a router, and that is what routers do.
> Do you mean that it forwards it to itself, the NAT device addressed by the actual public IP?
No, it forwards it to whatever destination address is in the destination address field of the IP headers, because that is what IP routers do.
If it is addressed to one of the NAT device's own addresses, of course, the routing decision would deliver it to the local protocol stack instead of forwarding it, and if there was any service listening on the respective protocol/port, that service would receive the packet (or the TCP stack would respond with a SYN+ACK, or whatever), and if nothing is listening there, the IP stack should respond with either some ICMP error message or possibly a TCP reset or something.
> Wikipedia seems to disagree [0] "if the destination port number of the incoming packet is not found in the translation table, the packet is dropped or rejected because the PAT device doesn't know where to send it."
Well, maybe that is good enough for explaining to a lay audience what a NAT gateway does, because that is what home routers typically will do, because they tend to also have a stateful firewall built in, but it's pretty misleading if you are trying to understand what is actually going on.
> I am sure a NAT could be configured any number of ways, though, and could probably do anything you want with such packets.
Not really, simply by definition: The function of a NAT is the translation of addresses. A router can have many more features, of course, such as a stateful firewall, but the point is that if you only had the address translation functionality, that would not prevent inbound connections, and if you remove the address translation functionality and keep the stateful firewall, inbound connections still aren't possible. Hence, NAT has nothing to do with whether inbound connections are possible, other than that devices that have NAT functionality commonly also have a stateful firewall.
Wouldn't the router only have a route for 192.168.0.x or whatever to go to the private interface? Why would a packet still addressed to the public IP get routed to the private network interface?
>NAT has nothing to do with whether inbound connections are possible
So how would you address a device on the private network from outside?
edit: I read your other response. Fair enough, if your ISP is sending you privately addressed packets they could get through.
I honestly think the fault here is not technical, it's ISPs.
Between the RIAA/MPAA breathing down their necks about piracy, and the realization they could make a mint charging inflated "business rates" than letting you do what you wanted with your own damn internet connection, shit got locked up tight so fast no one even noticed.
It's not NAT that's why my ISP is blocking half the protocols on the Internet. Why every ISP I've had for the last decade has blocked outgoing HTTP. Why I'd need to us a fucking VPN tunnel just to get SSH to my home computer. It's greed.
It's the forgotten front of the net neutrality fight, and it's gone almost entirely ignored. We don't have the right to our own outgoing traffic anymore, and this has been the case for far longer than IP allocation has been an issue.
> Why I'd need to us a fucking VPN tunnel just to get SSH to my home computer.
My most recent disappointment was trying to mount an Azure SMB 3.0 network drive over port 445. It would function just like a network drive at work or school right? No more poorly made userland daemons i.e. Dropbox. Or any additional software, VPN, proxy, or admin rights for that matter. Just click “add network drive” button in explorer and paste in the URI.
But nope port 445 is blocked by ISPs. So ironically the cheaper storage is only usuable by business internet plans. Which seems sorta atypical.
I ran into this with a client recently. Unfortunately, they were already on the business plan.
We ended up just hosting an OpenVPN server and having them connect automatically on startup.... This then broke Microsoft Office's ability to verify it still has a paid subscription.
SMB ports being blocked is unfortunate, but it was probably the only reasonable response to all the worms and stuff that were going around on those ports.
My first always-on home Internet was ADSL that came with 2 static IPv4 addrs and no filtering. I ran a server for my own needs, including hosting my own SMTP server, SSH, and SCM for my home directory&projects replication&backup.
At one point, I temporarily hosted a friend's server on my home second IP addr, while he was moving apartments and had a long lead time to move SDSL to the new place. Unbeknownst to me, it wasn't just an email server, but, I learned after the fact, was also hosting a political activism Web site, advocating freeing a person who was in trouble with a government. (I assume friend didn't tell me in an attempt to not to involve me in any possible government disfavor, though I really wished he'd found a different way to host that.)
This was before such activism was done by letting 'social media' companies own and intimately monitor the network and organizing/communications of people involved/interested in any movement. But earlier wasn't ideal either: if you wanted a decent Internet presence, including with your own domain name, you might've had to know how to set up a server, and be able to afford to operate it.
Germany (44%) and Belgium (53%) are killing it! The biggest surprise is India matching the US, must be that Indian mobile company that people mentioned here the other day?
Honestly I think the adoption of TLS has more to do with free certificates from LetsEncrypt and CloudFlare than the Snowden leaks.
As much as I'd like to think people were concerned about the privacy of their communications... I don't think most of the masses actually care about security or avoid conveniences based on threats to their privacy...
“The masses” don’t deploy http servers. They don’t need to implement tls. The fact is that something struck a nerve and motivated the people who handle this to implement TLS. Whether that’s tech-minded understanding or consumer-fomented demand channeled through CTOs, I don’t really care. Let’s Encrypt founders didn’t sit down one day with a master business plan of getting rich off free certs. I wouldn’t be the least bit surprised if a high-level view showed Snowden having a lot to do with it.
LetsEncrypt was likely accelerated by the Snowden leaks, but the discussions around free community run CAs were around long before that precipitous event. For CloudFlare it was likely just an effective way to drive additional business to them while pursuing their business model.
I don't think "the masses" fall into the equation at all and likely haven't even really noticed the change besides the "This site isn't safe" warnings that occasionally pop up.
If LetsEncrypt was accelerated by the Snowden leaks, that's a rather sad result. After all, it is absolutely trivial for a nation-state actor to generate SSL certificates for any domain they like, due to the broken state of global PKI. It is sufficient to gain access to any root certificate, or to know a person at a CA that can issue certificates, or to be able to manipulate the domain's nameserver, or to take over the server pointed to by the domain's A record, or to redirect traffic to that server to a middleman at the ISP level, in order to issue a perfectly valid, HSTS-accepted certificate.
SSL helps against the skript kiddie at your local Starbucks, not against the NSA.
(Of course, not being able to monitor and log all web traffic all the time must be a slight inconvenience, especially after the TLS 1.3 SAN changes. But we still shouldn't fool ourselves that just because we can't break it, the NSA can't either.)
>It is sufficient to gain access to any root certificate, or to know a person at a CA that can issue certificates, or to be able to manipulate the domain's nameserver, or to take over the server pointed to by the domain's A record, or to redirect traffic to that server to a middleman at the ISP level, in order to issue a perfectly valid, HSTS-accepted certificate.
But every connection you're intercepting, you're providing airtight evidence that a misissuance occured (the certificate). It's only a matter of time until you're caught. With certificate transparency, it's broadcast to everyone in the world.
So yes, nation states can bypass pki pretty easily, but it's only feasible for targeted attacks. That's better than the status quo of dragnet surveillance.
Regardless of why that’s still 40-50% less of the raw internet traffic intel agencies can get warrantlessly from ISP network tapping rooms and undersea cables splices.
Not to mention their lost access to private Google (and probably Yahoo, Microsoft, etc) networks and a myriad of other security improvements across countless software platforms.
> Besides the number of ips what are the advantages?
That is the primary advantage ... or rather all the consequences of having globally unique addresses for everything available with minimal administrative overhead.
> ipv6 vs ipv4 Which one is better for privacy?
Rarely makes a difference (web tracking happens via cookies anyway), and IPv6 has a huge potential of enabling less centralized protocols.
> Which one is better for security?
IPv6, because one flat address space without translators is easier to reason about and doesn't need so many workarounds to make connections work.
> Which one is better for speed?
According to what large content companies publish, IPv6 is usually quite a bit faster (lower latency), rarely slightly slower.
Hey cool, this is my side project! I've been trying to think of other interesting things to add to the project. For example, OpenSSH can do TUN/TAP tunneling, so you can use SSH as a proper VPN. (See https://wiki.archlinux.org/index.php/VPN_over_SSH)
How could that be useful in Serveo? How else could SSH be used creatively?
Agreed. In particular when testing any sort of web hooks/callbacks, I get pretty sick of constantly updating configurations as the ngrok tunnels change subdomain.
Seriously. ngrok is underpriced - I would pay double the ask without even flinching. I can't even count how many times it has actively aided in me getting paid.
I’ve used it to develop proper previews and unfurls for social media. Facebook etc need a real public URL to even show you a preview.
And the other day I used it as a quick way to debug a server-client communication issue. I’m developing a server, and the client developer is in a completely different location. For a while I kept deploying dev servers with little tweaks, but our progress was slow, Then I gave up and just exposed a local running server to the internet via Serveo. My counterpart pointed his client there, and we quickly iterated to a solution.
Yes we could have solved this in many other ways (remote debugging, VPNs, etc) but this was surprisingly easy.
Another shameless plug, but I wrote something that pretty much does the exact same thing: https://github.com/antoniomika/sish. Main difference was I didn't look forward to having to run a proprietary binary to achieve something I could write and I wanted to have SSH authentication built in so I can have it available publicly without having to worry about abuse.
I was trying to achieve the same with ssh tunnels a while back, but I wanted to have certbot running on the local machine, not on the DO server. So nginx on the server would have to forward everything as-is, encrypted. Is that possible?
It sounds like what you're looking for is to just forward the TCP port without having nginx do the SSL termination for you. You can achieve that with vanilla SSH though, just by forwarding port 443. If you want the virtual hosting, you could use an SNI proxy (haproxy with SNI tcp proxying should do for that)
I've written and am running something exactly like this for my work. (We used to use forward.wf but had to move away from it, a third party blocked it).
Very simple system, just a server+ nginx + letsencrypt. Tiny service to set new people up. We've been running out the last year or so, it took an hour or 2 to write, and hasn't needed more than that maintenance since.
I’ve been using self-hosted localtunnel but man is it unstable. It loses connections several times a day and never releases now “dead” urls, so you can’t count on a specific sub domain.
Hi! check out webhook relay https://webhookrelay.com/ :) it has multiple ways to forward webhooks and internal connection healthchecks. Disclaimer: I built it.
This is nice and i remember seeing this a while ago. However we couldn’t use it since during local development, the engineers are quite relaxed with secret keys, passwords, standard protocols …etc.
I have to do something similar when testing Apple Pay et al in development. I only get one connection at a time, and the latency is huge. Is ssh capable of multiple connections within a tunnel? Is Serveo relatively performant?
This service is absolutely not needed in a non-NAT world. And I strongly believe we have lost a lot by being completely dependent on client-server model of Internet.
I've written more about it here
https://www.ankshilp.in/post/the_broken_promise_of_internet/