KVM NAT VPS - Singapore & Poland | IPv6 + NAT IPv4 + HAProxy

Abdullah

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

caracal

What's the reduced speeds?

Abdullah

@caracal said:
What's the reduced speeds?

10Mbps for Poland,
5Mbps for Singapore

yoursunny

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.

Abdullah

@yoursunny said:
Prices increased significantly since the launch offer (even without the upgrade).

Adjusted the plans a bit for new orders only, existing users should have what they signed up for.

What happened to the /64 prefix?

This exists, thanks for the pointer.
All services in Poland are provisioned with a /64 by default.

---

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.

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)

yoursunny

@Abdullah said:

@yoursunny said:
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.

We keep ebtables enabled by default.
...virtualizor seems to have this behaviour.

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 will disable ebtables for your VM in sometime (once I solve another ipv6 affair of some vm's losing ip6 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.

Neoon

The ebtables problem is pretty known since a while and virtualizor is not doing anything to solve it.

yoursunny

@Neoon said:
The ebtables problem is pretty known since a while and virtualizor is not doing anything to solve it.

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?

Abdullah

@yoursunny said:
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?

To me, it sounds more like a router problem... checking.
did you do a traceroute when this happens?

Neoon

@yoursunny said:

@Neoon said:
The ebtables problem is pretty known since a while and virtualizor is not doing anything to solve it.

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?

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.

yoursunny

@Abdullah said:
To me, it sounds more like a router problem... checking.
did you do a traceroute when this happens?

I have tcpdump, ping, and traceroute all running in a loop.
I'm waiting for the next outage alert from UptimeRobot.

---

@Neoon said:
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.

It's the second time this week that someone told me they have no clue what Virtualizor is doing.
Link to previous cluelessness.

Brueggus

@yoursunny said: It's the second time this week that someone told me they have no clue what Virtualizor is doing.

You can add one. Quote from a recent ticket reply:

and (as usual?) ebtables got enabled again which effectively blocks all ipv6 traffic from OVZ containers.

Neoon

@yoursunny said:

@Abdullah said:
To me, it sounds more like a router problem... checking.
did you do a traceroute when this happens?

I have tcpdump, ping, and traceroute all running in a loop.
I'm waiting for the next outage alert from UptimeRobot.

---

@Neoon said:
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.

It's the second time this week that someone told me they have no clue what Virtualizor is doing.
Link to previous cluelessness.

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.

mikho

@Neoon said:

@yoursunny said:

@Abdullah said:
To me, it sounds more like a router problem... checking.
did you do a traceroute when this happens?

I have tcpdump, ping, and traceroute all running in a loop.
I'm waiting for the next outage alert from UptimeRobot.

---

@Neoon said:
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.

It's the second time this week that someone told me they have no clue what Virtualizor is doing.
Link to previous cluelessness.

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.

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.

Neoon

@mikho said:

@Neoon said:

@yoursunny said:

@Abdullah said:
To me, it sounds more like a router problem... checking.
did you do a traceroute when this happens?

I have tcpdump, ping, and traceroute all running in a loop.
I'm waiting for the next outage alert from UptimeRobot.

---

@Neoon said:
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.

It's the second time this week that someone told me they have no clue what Virtualizor is doing.
Link to previous cluelessness.

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.

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.

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.

mikho

@Neoon said:

@mikho said:

@Neoon said:

@yoursunny said:

@Abdullah said:
To me, it sounds more like a router problem... checking.
did you do a traceroute when this happens?

I have tcpdump, ping, and traceroute all running in a loop.
I'm waiting for the next outage alert from UptimeRobot.

---

@Neoon said:
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.

It's the second time this week that someone told me they have no clue what Virtualizor is doing.
Link to previous cluelessness.

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.

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.

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.

It doesn't really matters, the traffic stops at the node, independent of the size of the ipv6 subnet

Neoon

@mikho said:

@Neoon said:

@mikho said:

@Neoon said:

@yoursunny said:

@Abdullah said:
To me, it sounds more like a router problem... checking.
did you do a traceroute when this happens?

I have tcpdump, ping, and traceroute all running in a loop.
I'm waiting for the next outage alert from UptimeRobot.

---

@Neoon said:
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.

It's the second time this week that someone told me they have no clue what Virtualizor is doing.
Link to previous cluelessness.

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.

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.

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.

It doesn't really matters, the traffic stops at the node, independent of the size of the ipv6 subnet

I did read enabled as disabled, my fault.

yoursunny

@Abdullah said:
To me, it sounds more like a router problem... checking.
did you do a traceroute when this happens?

I finished my investigation and I blame the router.
Wireshark packet trace and traceroute are provided in Ticket #4562666.

---

@Neoon said:
In the cases I asked for ebtables to be disabled,

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.

the VM's had its own /64.
I don't buy anything less than a /64 anymore.

You can start a less than /64 hall of shame.
However, a subset of microLXC locations would be listed.

Neoon

@yoursunny said:

@Abdullah said:
To me, it sounds more like a router problem... checking.
did you do a traceroute when this happens?

I finished my investigation and I blame the router.
Wireshark packet trace and traceroute are provided in Ticket #4562666.

---

@Neoon said:
In the cases I asked for ebtables to be disabled,

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.

True likely just a symptom and not the issue.

the VM's had its own /64.
I don't buy anything less than a /64 anymore.

You can start a less than /64 hall of shame.
However, a subset of microLXC locations would be listed.

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.

yoursunny

@Neoon said:

@yoursunny said:
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.

True likely just a symptom and not the issue.

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.

Abdullah

Wireshark packet trace and traceroute are provided in Ticket #4562666.

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.

nullnothere

@Abdullah said: root cause

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.

Abdullah

@nullnothere said:

@Abdullah said: root cause

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.

nullnothere

@Abdullah said: uplink malfunction

Thanks.

It wasn't a config issue at all then - nice to know.

kuduku

@nullnothere said:

@Abdullah said: root cause

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.

Exact same issue for with me from last 5/6 days with @ApeWeb

Abdullah

@kuduku said:

@nullnothere said:

@Abdullah said: root cause

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.

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.

kuduku

@Abdullah said:

@kuduku said:

@nullnothere said:

@Abdullah said: root cause

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.

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.

Exactly correct , no downtime today

yoursunny

@Abdullah said:
@yoursunny does the NDP Responder works now?
lmk if need ebtables disabled.

Yes, NDP responder is working.
Moreover, I made the original ndppd working too.
Technical/Tutorial thread will be posted in next few days.

---

@Abdullah said:
there was one uplink malfunction affecting traffic partially, got that uplink replaced & issue solved.

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:

• In 2016, my ADSL line drops frequently, and the technician found that the telephone cord between the wall socket and the MODEM is bad.
• In 2018, our 100Gbps network is having significant packet loss such that TCP runs at 500Kbps, and it's caused by dust in an optical transceiver.
• BONUS: in 1998, my keyboard stopped working.
  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.

Abdullah

@yoursunny said:

@Abdullah said:
@yoursunny does the NDP Responder works now?
lmk if need ebtables disabled.

Yes, NDP responder is working.
Moreover, I made the original ndppd working too.
Technical/Tutorial thread will be posted in next few days.

Ask @mikho and just get it posted on les blog. better than thread