Rendered at 15:52:24 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
21 minutes ago [-]
mintflow 2 hours ago [-]
Why you want to do this on mobile or end device? If all the node is controlled by yourself I guess srv6 is indeed okay to use
But for ordinary user and mobile, and given the jitter of wireless network, seems it may cause unnecessary changes
But overall this is a neat project combine of technology I was fiddling and enjoy
StepBroBD 2 hours ago [-]
> Why you want to do this on mobile or end device
mobile clients will lose a lot of features but i want ranet3 to FULLY replace other wg based solution (meaning DNS, control plane, sharing, etc)
evanjrowley 20 hours ago [-]
I'd really like to know what you did to get stable v6. My ISP is also limited in a similar way - no IPv6.
StepBroBD 19 hours ago [-]
i happen to have v6 address allocation, im using the ranet3 to directly route v6 traffic to nearest bgp exit node
in the near future, when the tool is more mature (namely control plane and web ui), i’ll potentially open up a low cost (or hopefully free) tunnel broker
roderode 7 hours ago [-]
Interesting. Basically what i've been looking for. would love to try this out for my cloud project.
adulau 19 hours ago [-]
Looks cool until I saw the license which is clearly not an open-source license.
StepBroBD 19 hours ago [-]
yeah... im thinking of moving the license to a less restrictive one when i can better feed myself
currently its source available and auto converts to apache 2 after 2 years
StepBroBD 19 hours ago [-]
ranet3 is in the yc winter batch application pool, if you happen to be an investor, lmk i’d be happy to give you a demo!
palisade 3 hours ago [-]
ipsec is compromised, but ok, spread your net wide
StepBroBD 3 hours ago [-]
i mean the protocol itself is still very much safe (especially so with ikev2 and strong crypto algo suites)
maybe other hw vendors have "compromised" implementation
StepBroBD 5 hours ago [-]
I answered some questions on lobsters and wanted to share them here as well:
> I'm pretty dissatisfied with all the mesh VPNs options
Me too! Especially so if you want to play with overlay network _intensively_
> From this I infer your project is some sort of alternative to the various mesh VPNs
Yes. Not only this, I want ranet3 to interact nicely with other RFC compliant VPN (say any other ipsec apps on your phone or server) and routing daemons (say BIRD ‘s babel implementation)
Btw this already woks ;)
> In a typical mesh VPN, when might it be faster to route via another node, than to go direct?
Maybe during provider outages if you are behind residential ISPs? or busy hours? I'm not sure exactly when multiple hops will be faster.
This behavior is actually a "nice byproduct" of wanting to have ranet3 on laptops (which moves between networks). Babel is more often used to track lossy links, I would want routable addresses configured on laptops to be withdrew quickly when its not reachable
> In a typical mesh VPN, when might I want a policy to route via a chosen waypoint?
This is probably fairly useless to normal users but quite standard in ISP deployments. For example some transit provider have lower cost and operators might want to send most of the traffic to that link instead of sending traffic to more expensive providers.
But you can interpret this as traffic can take arbitrary routes you asked for, or the route with lowest metric value
> For the "chosen exit" case, is this similar to Tailscale exit nodes?
Exactly
> I suppose it doesn't do NAT punching
This is planned and will be implemented very soon
> Is it end-to-end encrypted? i.e. If traffic from node A to node B is routed via a waypoint W, does W see the original packet, or the encrypted packet?
No. Transit node traffic are decrypted and re-encrypted (I mean it's just a "routed mesh" right now). Also I think making it "real e2ee" will result in some performance penalties (in the sense of ESP in ESP) and losing some information of the packet (say clamping TCP MSS)
One argument I would make is that, (similar to Tailscale and other existing solutions) you should probably trust the nodes you add to the mesh...
> Where does addressing fit here? A typical mesh VPN gives nodes their own address, on a "flat" (?) network.
You can use arbitrary addresses, if you prefer tailscale like behavior you can just carve out the entire CGNAT range or subset of it, or go IPv6 only
> IIUC, ranet is "bring your own addressing"? Your page mentions you run two ASs on this, so "bring your own addressing" is a feature, I suppose?
Yes :)
> If I don't have an AS (but I do have an ISP or VPS that gives me a /56) what might a typical way be to allocate an address or prefix to my laptop? Static routing?
This is exactly the target use case. You can configure the VPS to allow traffic egress for the /56, and arbitrary addresses from that prefix can be added to devices connected to your VPS (in some sense, yes, static routing, since you do need to manually list address on nodes that want to use the addresses in the prefix)
> If I travel internationally and want to avoid round trips to my home when accessing my mesh nodes, how might I do that? Is this the "faster to route via another node, than to go direct" case?
Whichever route have the lowest metrics will be used, be it direct or going thru multiple hops
But for ordinary user and mobile, and given the jitter of wireless network, seems it may cause unnecessary changes
But overall this is a neat project combine of technology I was fiddling and enjoy
mobile clients will lose a lot of features but i want ranet3 to FULLY replace other wg based solution (meaning DNS, control plane, sharing, etc)
in the near future, when the tool is more mature (namely control plane and web ui), i’ll potentially open up a low cost (or hopefully free) tunnel broker
currently its source available and auto converts to apache 2 after 2 years
maybe other hw vendors have "compromised" implementation
> I'm pretty dissatisfied with all the mesh VPNs options
Me too! Especially so if you want to play with overlay network _intensively_
> From this I infer your project is some sort of alternative to the various mesh VPNs
Yes. Not only this, I want ranet3 to interact nicely with other RFC compliant VPN (say any other ipsec apps on your phone or server) and routing daemons (say BIRD ‘s babel implementation)
Btw this already woks ;)
> In a typical mesh VPN, when might it be faster to route via another node, than to go direct?
Maybe during provider outages if you are behind residential ISPs? or busy hours? I'm not sure exactly when multiple hops will be faster.
This behavior is actually a "nice byproduct" of wanting to have ranet3 on laptops (which moves between networks). Babel is more often used to track lossy links, I would want routable addresses configured on laptops to be withdrew quickly when its not reachable
> In a typical mesh VPN, when might I want a policy to route via a chosen waypoint?
This is probably fairly useless to normal users but quite standard in ISP deployments. For example some transit provider have lower cost and operators might want to send most of the traffic to that link instead of sending traffic to more expensive providers.
But you can interpret this as traffic can take arbitrary routes you asked for, or the route with lowest metric value
> For the "chosen exit" case, is this similar to Tailscale exit nodes?
Exactly
> I suppose it doesn't do NAT punching
This is planned and will be implemented very soon
> Is it end-to-end encrypted? i.e. If traffic from node A to node B is routed via a waypoint W, does W see the original packet, or the encrypted packet?
No. Transit node traffic are decrypted and re-encrypted (I mean it's just a "routed mesh" right now). Also I think making it "real e2ee" will result in some performance penalties (in the sense of ESP in ESP) and losing some information of the packet (say clamping TCP MSS)
One argument I would make is that, (similar to Tailscale and other existing solutions) you should probably trust the nodes you add to the mesh...
> Where does addressing fit here? A typical mesh VPN gives nodes their own address, on a "flat" (?) network.
You can use arbitrary addresses, if you prefer tailscale like behavior you can just carve out the entire CGNAT range or subset of it, or go IPv6 only
> IIUC, ranet is "bring your own addressing"? Your page mentions you run two ASs on this, so "bring your own addressing" is a feature, I suppose?
Yes :)
> If I don't have an AS (but I do have an ISP or VPS that gives me a /56) what might a typical way be to allocate an address or prefix to my laptop? Static routing?
This is exactly the target use case. You can configure the VPS to allow traffic egress for the /56, and arbitrary addresses from that prefix can be added to devices connected to your VPS (in some sense, yes, static routing, since you do need to manually list address on nodes that want to use the addresses in the prefix)
> If I travel internationally and want to avoid round trips to my home when accessing my mesh nodes, how might I do that? Is this the "faster to route via another node, than to go direct" case?
Whichever route have the lowest metrics will be used, be it direct or going thru multiple hops