TierHive General thread | Discuss, Updates, questions | LATEST: 8GB Ram available in some locations

skorous

@AnthonySmith said: Singapore needs more resources. Generally, it's WAY more popular than expected. I will get on that asap.

Inexpensive VPS in APAC region ... and it's wildly popular you say? Truly, who could have seen that coming? ;-)

AnthonySmith

@skorous said:

@AnthonySmith said: Singapore needs more resources. Generally, it's WAY more popular than expected. I will get on that asap.

Inexpensive VPS in APAC region ... and it's wildly popular you say? Truly, who could have seen that coming? ;-)

Meanwhile, no one is using Australia.. ?

sshbox

@AnthonySmith said:

@skorous said:

@AnthonySmith said: Singapore needs more resources. Generally, it's WAY more popular than expected. I will get on that asap.

Inexpensive VPS in APAC region ... and it's wildly popular you say? Truly, who could have seen that coming? ;-)

Meanwhile, no one is using Australia.. ?

Nothing but dropbears there.

terrorgen

one of the few IPv6 users reporting in... the system no longer auto-assigns IPv6 addresses to the VM after configuring it in the control panel.

We have to manually assign the address and gateway after every reboot

lgsin

@AnthonySmith said:

skorous said:

AnthonySmith said: Singapore needs more resources. Generally, it's WAY more popular than expected. I will get on that asap.

Inexpensive VPS in APAC region ... and it's wildly popular you say? Truly, who could have seen that coming? ;-)

Meanwhile, no one is using Australia.. ?

Australian nodes are mostly useful for users within Australia, but Singapore is the go-to choice for lower ping times and better routing throughout East Asia.

AnthonySmith

@terrorgen said: he system no longer auto-assigns IPv6 addresses to the VM after configuring it in the control panel.

it never auto-assigned or auto-configured.

WSS

@terrorgen said:
one of the few IPv6 users reporting in... the system no longer auto-assigns IPv6 addresses to the VM after configuring it in the control panel.

Are you sure you're talking about the right provider? You have to assign each IP to your VPS.

terrorgen

erm... okay

But surely you can automate this by injecting a netplan yaml config? Since you have already done that?

Or are we in the wrong again...

(We are using the debian template from TierHive, which uses netplan, uncommon for debian)

AnthonySmith

@terrorgen said:
erm... okay

But surely you can automate this by injecting a netplan yaml config? Since you have already done that?

Or are we in the wrong again...

(We are using the debian template from TierHive, which uses netplan, uncommon for debian)

Yep, if people actually use IPv6 by the time we get to beta automated provisioning of addresses directly into the VPS will be done, IPv6 was never even on the road map for Alpha, but so much noise was made, we added it, assuming people knew how to add an IPv6 address to their own network config.

Currently, 1.7% of users have even issued a /64, which goes to show how popular and wanted IPv6 when its not just being passively consumed; it was the same at IH and the same on the old LES NAT service; the IPv6 traffic was always less than 5% overall.

We use the official Debian-produced cloud templates so I would say whatever is in use, is the default now in Debian. Other panels roll their own templates and use things like packer so they probably modify the defaults to work with their own automation. Everything in TierHive is native as much as possible.

We use: https://cloud.debian.org/images/cloud/trixie/latest/debian-13-genericcloud-amd64.qcow2

I do appreciate what you are saying, really, I do, but I wanted to get a sense of real-world IPv6 use (not passive consumption) before ploughing xxx hours of dev and engineering time into something that 95% of users don't care about when, at this stage, the time could be better spent.

terrorgen

@AnthonySmith said:

@terrorgen said:
erm... okay

But surely you can automate this by injecting a netplan yaml config? Since you have already done that?

Or are we in the wrong again...

(We are using the debian template from TierHive, which uses netplan, uncommon for debian)

Yep, if people actually use IPv6 by the time we get to beta automated provisioning of addresses directly into the VPS will be done, IPv6 was never even on the road map for Alpha, but so much noise was made, we added it, assuming people knew how to add an IPv6 address to their own network config.

Currently, 1.7% of users have even issued a /64, which goes to show how popular and wanted IPv6 when its not just being passively consumed; it was the same at IH and the same on the old LES NAT service; the IPv6 traffic was always less than 5% overall.

We use the official Debian-produced cloud templates so I would say whatever is in use, is the default now in Debian. Other panels roll their own templates and use things like packer so they probably modify the defaults to work with their own automation. Everything in TierHive is native as much as possible.

We use: https://cloud.debian.org/images/cloud/trixie/latest/debian-13-genericcloud-amd64.qcow2

I do appreciate what you are saying, really, I do, but I wanted to get a sense of real-world IPv6 use (not passive consumption) before ploughing xxx hours of dev and engineering time into something that 95% of users don't care about when, at this stage, the time could be better spent.

Appreciate your response, Ant.

WSS

@AnthonySmith Here's a fe80 for that chip on your shoulder. If I lost my IPv6, it'd be more annoying for me to manage.

xms

@AnthonySmith what will happen if I use all of the 253 IPs? Is it possible to increase it?

Not gonna use that much, just thinking.

AnthonySmith

@xms said:
@AnthonySmith what will happen if I use all of the 253 IPs? Is it possible to increase it?

Not gonna use that much, just thinking.

No one has yet, but what would happen would be you cant create another VPS.

I think the closest account is at around 120 ish VPS.

Longer term, there is a plan to do teams so you can link multiple accounts in various ways, someone suggested something about it early on, sorry I dont remember who but i think maybe it was @Nyr ?? about the ability to link 2 x /24's so customers can communicate between subnets that will come first where you can whitelist subnets then we will allow users to create teams and invite users and control token spend, migrate, create, delete etc.

So right now, if you hit 253, you hit the limit, start another account I guess, you can already transfer tokens between accounts, long term create a team and have multiple accounts, team members will see all subnets in the team (depending on access levels set)

AnthonySmith

and... we lost SG again... sigh

Edit: maybe a network blip at OVH, the server itself is fine.

Edit2: no, my bad the server is not fine, NIC is having issues, probably that stupid intel nic issue that needs a patch, got hit with it early in FR too. lord... let me have a normal day just once please!!!!

SG Rebooting

Nyr

@AnthonySmith said: i think maybe it was @Nyr

Not me

AnthonySmith

@Nyr said:

@AnthonySmith said: i think maybe it was @Nyr

Not me

Hmm, ok, well whoever said it was right

sshbox

Estimated Runtime from current usage seems to not include charges from stopped VPSes.

AnthonySmith

@sshbox said:
Estimated Runtime from current usage seems to not include charges from stopped VPSes.

Thanks, I will have that checked and updated

Edit: actually, that was literally a 3-second fix, so I did it myself.

AnthonySmith

Capacity added to Vint Hill USA.

I will also add the HDD options there on Monday (if not sooner) and also you will see backup destination options for your VPS backups soon also so you can pick the closest region.

AnthonySmith

You can now create a storage VPS in VintHill 0.0000035

Example plan:

1vCPU
256mb Ram
5GB NVMe
2 TB HDD

Starts at around $5.40 /month or $0.007491 per hour.

1 hour minimum.

https://tierhive.com/ have a play with the pricing calculator

WSS

Welp guess I'm going to make my backup a literal backup now.

somik

@AnthonySmith said:
Starts at around $5.40 /month or $0.007491 per hour.

1 hour minimum.

Who needs a backup server by hour? Like when you transfer from one computer to another but dont have a external drive or thumb drive?

AnthonySmith

@somik said:

@AnthonySmith said:
Starts at around $5.40 /month or $0.007491 per hour.

1 hour minimum.

Who needs a backup server by hour? Like when you transfer from one computer to another but dont have a external drive or thumb drive?

Probably very few people but I am not going to put a minimum beyond 1 hour on it, some people might need one for 48 hours and be happy they don't have to pay for a whole month

runbiscuit

Feature request (not sure if new):

• Matched port forwarding (e.g.: where port 4444 -> 4444)

Use case:

• Some applications (reasonably) do not take into account for the fact that users may be running it behind a NAT, like TierHive/any NAT VPS provider
• As such, it assumes that the port configured is also directly available externally
• There's no way for us to guess which available port TierHive assigns to the VPS

As such, for example, when deploying 3X-UI and trying to use the Subscription feature (allows you to bundle multiple VPN backends into 1 single easy to distribute URL), the Subscription portion reasonably expects itself to be reverse proxied, but the underlying protocols (e.g. VLESS) don't.

As such, trying to use the subscription feature for autoconfig leads to the following:

• VPN client pulls from the right port
• TierHive automatically forwards traffic to the right port
• VPN client pulls configuration, for port 21097
• VPN client tries to connect to port 21097 but it is not open (connection failed)

Desired user flow:

• "Forwarded Ports" > "Internal Port" -- this input can be made optional
• If none supplied and "+ Port" button is clicked, a matching open port is added
• Users can directly configure their application to listen on specified port

Thank you!

AnthonySmith

@runbiscuit said:
Feature request (not sure if new):

• Matched port forwarding (e.g.: where port 4444 -> 4444)

Use case:

• Some applications (reasonably) do not take into account for the fact that users may be running it behind a NAT, like TierHive/any NAT VPS provider
• As such, it assumes that the port configured is also directly available externally
• There's no way for us to guess which available port TierHive assigns to the VPS

As such, for example, when deploying 3X-UI and trying to use the Subscription feature (allows you to bundle multiple VPN backends into 1 single easy to distribute URL), the Subscription portion reasonably expects itself to be reverse proxied, but the underlying protocols (e.g. VLESS) don't.

As such, trying to use the subscription feature for autoconfig leads to the following:

• VPN client pulls from the right port
• TierHive automatically forwards traffic to the right port
• VPN client pulls configuration, for port 21097
• VPN client tries to connect to port 21097 but it is not open (connection failed)

Desired user flow:

• "Forwarded Ports" > "Internal Port" -- this input can be made optional
• If none supplied and "+ Port" button is clicked, a matching open port is added
• Users can directly configure their application to listen on specified port

Thank you!

Ok I think I understand what you are asking but why wouldn't you just forward some ports first and then do your config?

The issue with having 1:1 predictable matched ports with the end user selecting the port is that almost immediately users are going to reserve and hold the common ports used by VPN, proxy and pbx softwares etc.

But I guess we could just say 'if available, then match the port'

For your specific example it sounds like you could probably just use haproxy and forward, but I am not a 3cx expert by any means.

I will have a chat about the matched forwarding if available, my concern is that it genertes a lot of 'i need' tickets.

But it's not a no.

Ant.

david3

I don't think the actual port number matters, just that the internal port and forwarded port is the same.

Right now, I usually add a port, so I can see what it will be, then delete it, then add it again with the same internal port number.

AnthonySmith

@david3 said:
I don't think the actual port number matters, just that the internal port and forwarded port is the same.

Right now, I usually add a port, so I can see what it will be, then delete it, then add it again with the same internal port number.

Ooooh I get it now, in the sandpit that already works like that if you just click add without entering a port so yes that will be coming soon.

runbiscuit

@AnthonySmith said: For your specific example it sounds like you could probably just use haproxy and forward, but I am not a 3cx expert by any means.

Ah, not 3cx, 3X-UI is a VPN interface that's incredibly powerful for configuring VPNs to circumvent censorship firewalls.
It's one of the recipes available on the portal.

Example for VLESS VPN: It is listening on port 21097 on my server, but actual open port on public IP is 6767. As such, autoconfig fails, since it tries to hit port 21097 on the public IP. I can configure it to listen on any port on my node, but the node and public IP must both match.

Current flow would be to:

• create the port forward on portal
• look at what port is assigned (example 6767→21097)
• listen with haproxy/rinetd/forwarding rule on 21097 and redirect traffic to port 6767
• setup VLESS VPN on port 6767

Definitely more configuration work.

The issue with having 1:1 predictable matched ports with the end user selecting the port is that almost immediately users are going to reserve and hold the common ports used by VPN, proxy and pbx softwares etc.

Absolutely agree with you.
Regarding the matched ports, I think you can just block all known ports for those software from ever being assigned to anyone.

nameserver

Can HAProxy have multiple port option? I want to have 80 and 443 at the same time but it only supports one.

AnthonySmith

@nameserver said:
Can HAProxy have multiple port option? I want to have 80 and 443 at the same time but it only supports one.

We use strict SNI so if a certificate exists then it will attempt to use it and that auto redirects to 443 even if 80 exists.

I will have a think about that, maybe we could do both but you would need to manage your own SSL.on the VPS

nameserver

@AnthonySmith said:

@nameserver said:
Can HAProxy have multiple port option? I want to have 80 and 443 at the same time but it only supports one.

We use strict SNI so if a certificate exists then it will attempt to use it and that auto redirects to 443 even if 80 exists.

I will have a think about that, maybe we could do both but you would need to manage your own SSL.on the VPS

A quick letsencrypt by myself always works, so it would be a really good feature.

NanoG6

@AnthonySmith Quick question. I’ve been trying to run a backend over HTTPS on TierHive, but I keep hitting the error: “Client sent an HTTP request to an HTTPS server.”
Support told me HAProxy setup only redirects traffic to port 80/tcp (or another port) using plain HTTP, so HTTPS backends aren’t really supported.
Can anyone here confirm if that’s actually the case? Or is there some workaround to get HTTPS backends running on the platform?

skorous

@NanoG6 said:
@AnthonySmith Quick question. I’ve been trying to run a backend over HTTPS on TierHive, but I keep hitting the error: “Client sent an HTTP request to an HTTPS server.”
Support told me HAProxy setup only redirects traffic to port 80/tcp (or another port) using plain HTTP, so HTTPS backends aren’t really supported.
Can anyone here confirm if that’s actually the case? Or is there some workaround to get HTTPS backends running on the platform?

Just making sure, you're looking for haproxy to decrypt the https packet and then re-encrypt it to send to the backend on port 443?

NanoG6

@skorous said: Just making sure, you're looking for haproxy to decrypt the https packet and then re-encrypt it to send to the backend on port 443?

Yeah, I get what you mean — but just to clarify, I’m not asking HAProxy to terminate and then re‑encrypt TLS. What I was trying to do is simply forward (passthrough) traffic on port 443 straight through to the backend, kind of like how I’ve done before with microLXC. In that case HAProxy didn’t need to touch the TLS layer, it just passed the packets along and the backend handled the HTTPS.
So my question is more about whether TierHive’s HAProxy setup allows that kind of straight passthrough on 443, or if it’s strictly limited to HTTP backends only.

AnthonySmith

@NanoG6 said:

@skorous said: Just making sure, you're looking for haproxy to decrypt the https packet and then re-encrypt it to send to the backend on port 443?

Yeah, I get what you mean — but just to clarify, I’m not asking HAProxy to terminate and then re‑encrypt TLS. What I was trying to do is simply forward (passthrough) traffic on port 443 straight through to the backend, kind of like how I’ve done before with microLXC. In that case HAProxy didn’t need to touch the TLS layer, it just passed the packets along and the backend handled the HTTPS.
So my question is more about whether TierHive’s HAProxy setup allows that kind of straight passthrough on 443, or if it’s strictly limited to HTTP backends only.

I will chat with my colleague see what we can do, I think what you are asking for is TCP mode rather than http/s mode which has always been on the plans to add.

TemporiousOne

@david3 said:
I don't think the actual port number matters, just that the internal port and forwarded port is the same.

Right now, I usually add a port, so I can see what it will be, then delete it, then add it again with the same internal port number.

That's a nice tip. I was wondering how to get a mapping with both ports the same number. Thanks!

skorous

@AnthonySmith said:

I will chat with my colleague see what we can do, I think what you are asking for is TCP mode rather than http/s mode which has always been on the plans to add.

The problem with that will be TCP mode doesn't support SNI ( since it's not reading the packet at all ).

EDIT: I'm not sure if this information is still correct in newer ( compared to the ancient one I'm running ) versions of haproxy. It looks like it might for either certain protocols or all. Don't have time to finish reading the docs.

NanoG6

@AnthonySmith said: I will chat with my colleague see what we can do, I think what you are asking for is TCP mode rather than http/s mode which has always been on the plans to add.

Got it, thanks Anthony — TCP passthrough is exactly what I meant. Glad to hear it’s planned, I’ll wait for the rollout. Appreciate you checking on it

TemporiousOne

@skorous said:

The problem with that will be TCP mode doesn't support SNI ( since it's not reading the packet at all ).

EDIT: I'm not sure if this information is still correct in newer ( compared to the ancient one I'm running ) versions of haproxy. It looks like it might for either certain protocols or all. Don't have time to finish reading the docs.

Based on some of my tests, it looks possible to concurrently support TCP and HTTP mode on the same port. I'd imagine the challenge would be for @AnthonySmith and gang to put a nice and safe UI + Backend scripting logic around it.

AnthonySmith

@TemporiousOne said:

@skorous said:

The problem with that will be TCP mode doesn't support SNI ( since it's not reading the packet at all ).

EDIT: I'm not sure if this information is still correct in newer ( compared to the ancient one I'm running ) versions of haproxy. It looks like it might for either certain protocols or all. Don't have time to finish reading the docs.

Based on some of my tests, it looks possible to concurrently support TCP and HTTP mode on the same port. I'd imagine the challenge would be for @AnthonySmith and gang to put a nice and safe UI + Backend scripting logic around it.

Yeah, it's a bit of a nightmare, we did have websockets, which used tcp mode as an option in the pre-release version. We were going to offer them for free but during penetration testing, it got scary so we pulled it. It is possible; it was more of an engineering problem of assuming trust, but we learned what we needed to back then for when we got around to doing it again, but that was probably a year ago now, I dont remember the exact details.

AnthonySmith

Bit of an update, some repeats probably.

1. Poland is now live along with HAProxy, working on IPv6.
2. Storage VPS options now available in London AND Vint Hill USA, probably the cheapest option possible, if anyone knows cheaper, let me know!!
3. When issuing extra ports (Now up to 5) if you don't enter an internal port number, you just get a 1:1 matched port e.g. 3456 external and 3456 internal.
4. More general capacity added to Vint Hill.
5. More capacity planned for Singapore including storage VPS.
6. Backup infrastructure upgrades done, now they will hit a targeted lowest latency region so should complete faster and without as many failures for places like Australia.
7. IPv6 use is now more stable and self-repairing, no issues reported for a while, yet still under 2% use overall.
8. The static hosting failed penetration testing, re-engineering is underway but this has delayed things a lot, and I am 2% balder as a result, sorry for those waiting for that, nothing MAJOR, but needed a bit of rework to be sure, hopefully this releases by the end of the week.

For the result of the year, we are going to work through the backlog of bug reports and feature requests, work on communication channels with customers generally, get a public status board, tracker and network test suite up and really focus on adding as many locations as we can find.

I am interested in your opinion on something, there are some locations that are just expensive, no way is tierhive sustainable in those locations, do you think adding a multiplier, e.g. 1.5x token costs, obvious at the point of sale, is the right way to go or just don't bother with ultra exotic locations or something else?

Think Kenya, Lagos, iceland, Edinborough etc etc, not your standard locations.

sshbox

+1 for more locations, even at a premium.

Please also bring up the locations teased earlier.

WSS

Is that under 2% use by assignment or actual utilization?

sshbox

@AnthonySmith said: Poland is now live along with HAProxy, working on IPv6.

Very nice. No steal.

AnthonySmith

@WSS said:
Is that under 2% use by assignment or actual utilization?

assignment, so use will be even less.

In terms of overall actual use, 30 days: 10.52 Mbps 95% 132GB Total in+out

As of right now, like the last hour 95% is 2.52 Mbps

AnthonySmith

@sshbox said:

@AnthonySmith said: Poland is now live along with HAProxy, working on IPv6.

Very nice. No steal.

Give it a minute.... haha

sshbox

@AnthonySmith said:

@sshbox said:

@AnthonySmith said: Poland is now live along with HAProxy, working on IPv6.

Very nice. No steal.

Give it a minute.... haha

LOL

WSS

@AnthonySmith said:

@WSS said:
Is that under 2% use by assignment or actual utilization?

assignment, so use will be even less.

In terms of overall actual use, 30 days: 10.52 Mbps 95% 132GB Total in+out

As of right now, like the last hour 95% is 2.52 Mbps

{{Starts to pingflood fe80%12..}}

lgsin

AnthonySmith said:

I am interested in your opinion on something, there are some locations that are just expensive, no way is tierhive sustainable in those locations, do you think adding a multiplier, e.g. 1.5x token costs, obvious at the point of sale, is the right way to go or just don't bother with ultra exotic locations or something else?

Think Kenya, Lagos, iceland, Edinborough etc etc, not your standard locations.

+1 for adding a multiplier (or even multipliers) for exotic locations

terrorgen

@WSS said:

@AnthonySmith said:

@WSS said:
Is that under 2% use by assignment or actual utilization?

assignment, so use will be even less.

In terms of overall actual use, 30 days: 10.52 Mbps 95% 132GB Total in+out

As of right now, like the last hour 95% is 2.52 Mbps

{{Starts to pingflood fe80%12..}}

do it. make it look important.