KVM NAT VPS - Singapore & Poland | IPv6 + NAT IPv4 + HAProxy
All new KVM NAT VPS
All plans include:
NVMe/SSD disk space
High-performing CPUs
KVM Virtualization
Custom ISO possible
Dedicated IPv6
NAT IPv4 - 50 static public ports + HAProxy on port 80 & 443 (use own domain)
Standard Helpdesk Support Included
1 Gbps Port Speeds
High Bandwidth Allocation - Unlimited@reduced speed after reaching the quota.
Locations available:
EU - Warsaw, Poland 🇵🇱 Network Looking glass
APAC - Singapore 🇸🇬 Network Looking Glass (((NEW NETWORK)))
KVM-NAT-256MB
- 1 CPU Core(s) (fair share)
- 256MB RAM + 128MB swap
- 5GB NVMe/SSD disk space
- /80 IPv6 + NAT IPv4
- KVM Virtualization
- 750GB / 250GB bandwidth@1Gbps
- Order Poland / Order Singapore - USD $10/y
KVM-NAT-0.5GB
- 1 CPU Core(s) (fair share)
- 512MB RAM
- 5GB NVMe/SSD disk space
- /80 IPv6 + NAT IPv4
- KVM Virtualization
- 1TB / 375GB bandwidth@1Gbps
- Order Poland / Order Singapore - USD $18/y
KVM-NAT-2GB
- 2 CPU Core(s) (fair share)
- 2GB RAM
- 25GB NVMe/SSD disk space
- /80 IPv6 + NAT IPv4
- KVM Virtualization
- Windows Supported
- 4TB / 1TB bandwidth@1Gbps
- Order Poland / Order Singapore - USD $5.4/m
===Please turn off your proxy/VPN while placing order===
Feel free to ask any questions you might have
Thanked by (1)Brueggus
Comments
What's the reduced speeds?
Cloudron.io - Lovely self hosted management suite [aff]
HetrixTools - Highly recommended uptime monitor [aff]
10Mbps for Poland,
5Mbps for Singapore
https://webhorizon.net
Prices increased significantly since the launch offer (even without the upgrade).
What happened to the /64 prefix?
The /64 prefix in my box is behaving erratically.
It seems that neighbor advertisement packets transmitted from a link-local address are not accepted.
I'm still investigating whether I messed up something in Netplan / NDP responder, or it's a router / ebtables problem.
Accepting submissions for IPv6 less than /64 Hall of Incompetence.
Adjusted the plans a bit for new orders only, existing users should have what they signed up for.
This exists, thanks for the pointer.
All services in Poland are provisioned with a /64 by default.
We keep ebtables enabled by default.
...virtualizor seems to have this behaviour.
I will disable ebtables for your VM in sometime (once I solve another ipv6 affair of some vm's losing ip6 randomly)
https://webhorizon.net
I know, Evolution Host has ebtables too, and they too reject neighbor advertisement packets transmitted from a link-local address.
I made my own NDP responder that transmits neighbor advertisement packets from my global address, and it works.
I have a blog post up, but haven't posted a Technical/Tutorial thread on this forum because I'm still investigating whether it's causing me to lose IPv6 connectivity randomly.
I'm also losing IPv6 connectivity randomly, even for IPv6 addresses directly assigned to the KVM server (not Docker container).
However, don't disable ebtables yet.
I'd like to find the root cause before making random changes.
Today I'm going to make a backup then reinstall from template, and see whether it makes any difference.
The backup feature is nice that I'm less reluctant to wipe a machine for investigating problems, since I wouldn't need to spend an hour redoing setup afterwards.
Accepting submissions for IPv6 less than /64 Hall of Incompetence.
The ebtables problem is pretty known since a while and virtualizor is not doing anything to solve it.
Free NAT KVM | Free NAT LXC | Bobr
ITS WEDNESDAY MY DUDES
Can you explain exactly what's the problem?
What I'm seeing is, even if I force neighbor solicitation and neighbor advertisement to be transmitted from a global address (e.g. by disabling link-local address on the network interface), my KVM server can still lose IPv6 connectivity from time to time, with
ip -6 neigh
showing "failed".(I reinstalled from template and there's no ndppd or custom NDP responder involved)
I kept an incoming ping running, and ran
tcpdumo -i eth0 icmp6
on the KVM server.I can see the incoming echo requests and outgoing echo responses continuously, but occasionally I'm getting ICMPv6 address unreachable messages.
Is this caused by ebtables, or is it a router problem?
Accepting submissions for IPv6 less than /64 Hall of Incompetence.
To me, it sounds more like a router problem... checking.
did you do a traceroute when this happens?
https://webhorizon.net
No idea, its to long ago, we solved it by asking ebtables to be disabled on the specific VM.
I can't even reproduce it yet, since I have no other virtualizor vps where ebtables is still enabled.
Free NAT KVM | Free NAT LXC | Bobr
ITS WEDNESDAY MY DUDES
I have tcpdump, ping, and traceroute all running in a loop.
I'm waiting for the next outage alert from UptimeRobot.
It's the second time this week that someone told me they have no clue what Virtualizor is doing.
Link to previous cluelessness.
Accepting submissions for IPv6 less than /64 Hall of Incompetence.
You can add one. Quote from a recent ticket reply:
dnscry.pt - Public DNSCrypt resolvers hosted by LowEnd providers • Need a free NAT LXC? -> https://microlxc.net/
I don't have any virtualizor hosts system and I will likely never have one + I don't have root access to the providers node for obviously reasons so I can't know how its configured.
I entered that pandora box once with SolusVM and now Virtualizor, it seems to be all fucked up, but you can't leave it anymore.
IPv6 looks still to be experimental.
Free NAT KVM | Free NAT LXC | Bobr
ITS WEDNESDAY MY DUDES
I have a dedicated server with Virtualizor and a couple of VMs on it that is ready to troubleshoot this exact problem.
It is confirmed that enabled ebtables messes with a split /64 ipv6 on Virtuozzo containers.
“Technology is best when it brings people together.” – Matt Mullenweg
In the cases I asked for ebtables to be disabled, the VM's had its own /64.
I don't buy anything less than a /64 anymore.
Free NAT KVM | Free NAT LXC | Bobr
ITS WEDNESDAY MY DUDES
It doesn't really matters, the traffic stops at the node, independent of the size of the ipv6 subnet
“Technology is best when it brings people together.” – Matt Mullenweg
I did read enabled as disabled, my fault.
Free NAT KVM | Free NAT LXC | Bobr
ITS WEDNESDAY MY DUDES
I finished my investigation and I blame the router.
Wireshark packet trace and traceroute are provided in Ticket #4562666.
Don't blame ebtables.
They are innocent.
I stand with ebtables.
We can continue to blame Virtualizor for misconfiguring things.
... until Virtualizor is GPL'ed.
You can start a less than /64 hall of shame.
However, a subset of microLXC locations would be listed.
Accepting submissions for IPv6 less than /64 Hall of Incompetence.
True likely just a symptom and not the issue.
I want to supply a /64 per Container/Virtual Machine, it makes the IPv6 configuration and delivery easier.
However, either the DC or the Provider does not supply anything bigger than a /64, which makes me sad.
Most of the locations only giving out a /70 are running on Virtualizor, kek.
Free NAT KVM | Free NAT LXC | Bobr
ITS WEDNESDAY MY DUDES
Today I spent more than an hour designing the experiment, reading the logs, and writing the analysis.
In the meanwhile, people on OGF are spending more than an hour writing drama threads accusing the provider without sufficient evidence and technical analysis.
You should do the same and get to the root cause, instead of curing the symptom.
Accepting submissions for IPv6 less than /64 Hall of Incompetence.
just updating here, the 'root cause' has been fixed, thanks for the trace logs.
@yoursunny does the NDP Responder works now?
lmk if need ebtables disabled.
https://webhorizon.net
Care to share for others benefit?
Separately, I remember from a while back, that there was a similar issue I faced with a provider when my IPv6 connectivity would mysteriously drop for some time and then magically reappear as if nothing happened. After a fair bit of back and forth and some involvement from the provider, it was identified as too small of a (neighbor) cache size and after some tuning things got better. I'm really not sure if it was abuse or something else because I've not run into a comparable issue so far on other hosts.
there was one uplink malfunction affecting traffic partially, got that uplink replaced & issue solved.
Monitoring the assigned IP in case something might turn up, everything good uptill now.
https://webhorizon.net
Thanks.
It wasn't a config issue at all then - nice to know.
Exact same issue for with me from last 5/6 days with @ApeWeb
They use the same DC as ours. So even your issue should be fixed now I guess.
https://webhorizon.net
Exactly correct , no downtime today
Yes, NDP responder is working.
Moreover, I made the original ndppd working too.
Technical/Tutorial thread will be posted in next few days.
It's the third time I'm affected by intermittent connectivity problem caused by a faulty link.
The issue is indeed resolved, with no alert from UptimeRobot today.
I'm the one designing network protocols, so that whenever there's an issue, my go-to method is to collect packet traces and read RFC specifications.
I rarely suspect the physical layer, but it's having problems more often than I imagined.
Previous physical layer incidents:
I wanted to send an email to my uncle asking him to come over and fix my keyboard, only to found that I cannot enter dial-up password without the keyboard.
Later I called my uncle, and he asked me to check the PS/2 connector behind the computer - and it's loose.
Accepting submissions for IPv6 less than /64 Hall of Incompetence.
Ask @mikho and just get it posted on les blog. better than thread
https://webhorizon.net