[FREE] IPv6 Tunnel Broker (https://tb.tahio.eu) - Connect to IPv6 via IPv4

ashish168527

@elusiVeRPG please ping me in dm once you publish it on GitHub , would love to contribute whatever i can

letstayfree

Cool bro. Ipv6

ScreenReader

@elusiVeRPG said:

@cmeerw said:

@ashish168527 said:
Will be better if we can easily update client ipv4 by http request without logging into account ,

&
can you enable SMTP port on request?

While I might have some sympathy for blocking port 25 (for a free service), what's the reason for blocking 465, 587, 110, 143, etc.?

For now I block all email related ports as Im not an expert from those services and I do not want to get ip blacklisted. If somebody is an expert here from those kind of stuff I will be more then happy to discuss this and consider to open some ports if this is safe for ip.

if this is one-man project just keep email ports blocked. less headache. put your time and energy anywhere else instead of arguing and dealing with email abuse.

the last free ipv6 project also went down due to abuse, so no need to repeat their mistake.
even with max 2 tunnel per account you're still going have to deal with abuse, so don't get your palate full with email problems.

cmeerw

@ScreenReader said:

@elusiVeRPG said:

@cmeerw said:

@ashish168527 said:
Will be better if we can easily update client ipv4 by http request without logging into account ,

&
can you enable SMTP port on request?

While I might have some sympathy for blocking port 25 (for a free service), what's the reason for blocking 465, 587, 110, 143, etc.?

For now I block all email related ports as Im not an expert from those services and I do not want to get ip blacklisted. If somebody is an expert here from those kind of stuff I will be more then happy to discuss this and consider to open some ports if this is safe for ip.

if this is one-man project just keep email ports blocked. less headache. put your time and energy anywhere else instead of arguing and dealing with email abuse.

But I would only associate email abuse with port 25, not with the other ports - those all require authentication, so it would just be abuse as any other kind of abuse. I am also seeing significantly less abuse on those ports than port 22. So why not also block port 22 then? And what about all the abuse on port 443?

elusiVeRPG

@cmeerw said:

@ScreenReader said:

@elusiVeRPG said:

@cmeerw said:

@ashish168527 said:
Will be better if we can easily update client ipv4 by http request without logging into account ,

&
can you enable SMTP port on request?

While I might have some sympathy for blocking port 25 (for a free service), what's the reason for blocking 465, 587, 110, 143, etc.?

For now I block all email related ports as Im not an expert from those services and I do not want to get ip blacklisted. If somebody is an expert here from those kind of stuff I will be more then happy to discuss this and consider to open some ports if this is safe for ip.

if this is one-man project just keep email ports blocked. less headache. put your time and energy anywhere else instead of arguing and dealing with email abuse.

But I would only associate email abuse with port 25, not with the other ports - those all require authentication, so it would just be abuse as any other kind of abuse. I am also seeing significantly less abuse on those ports than port 22. So why not also block port 22 then? And what about all the abuse on port 443?

not incoming abuse, outgoing email spam abuse.

cmeerw

@elusiVeRPG said:

@cmeerw said:

@ScreenReader said:

@elusiVeRPG said:

@cmeerw said:

@ashish168527 said:
Will be better if we can easily update client ipv4 by http request without logging into account ,

&
can you enable SMTP port on request?

While I might have some sympathy for blocking port 25 (for a free service), what's the reason for blocking 465, 587, 110, 143, etc.?

For now I block all email related ports as Im not an expert from those services and I do not want to get ip blacklisted. If somebody is an expert here from those kind of stuff I will be more then happy to discuss this and consider to open some ports if this is safe for ip.

if this is one-man project just keep email ports blocked. less headache. put your time and energy anywhere else instead of arguing and dealing with email abuse.

But I would only associate email abuse with port 25, not with the other ports - those all require authentication, so it would just be abuse as any other kind of abuse. I am also seeing significantly less abuse on those ports than port 22. So why not also block port 22 then? And what about all the abuse on port 443?

not incoming abuse, outgoing email spam abuse.

But that would only be for port 25, not the other ports. The only abuse on those ports would be brute-force attacks (same as you would see on port 22).

elusiVeRPG

For now it stays li> @cmeerw said:

@elusiVeRPG said:

@cmeerw said:

@ScreenReader said:

@elusiVeRPG said:

@cmeerw said:

@ashish168527 said:
Will be better if we can easily update client ipv4 by http request without logging into account ,

&
can you enable SMTP port on request?

While I might have some sympathy for blocking port 25 (for a free service), what's the reason for blocking 465, 587, 110, 143, etc.?

For now I block all email related ports as Im not an expert from those services and I do not want to get ip blacklisted. If somebody is an expert here from those kind of stuff I will be more then happy to discuss this and consider to open some ports if this is safe for ip.

if this is one-man project just keep email ports blocked. less headache. put your time and energy anywhere else instead of arguing and dealing with email abuse.

But I would only associate email abuse with port 25, not with the other ports - those all require authentication, so it would just be abuse as any other kind of abuse. I am also seeing significantly less abuse on those ports than port 22. So why not also block port 22 then? And what about all the abuse on port 443?

not incoming abuse, outgoing email spam abuse.

But that would only be for port 25, not the other ports. The only abuse on those ports would be brute-force attacks (same as you would see on port 22).

For now it stays like it is and cut off this topic. Im noob in this mater so I need to make consult with somebody who really has some knowledge about topic. EOL

---

So I have just confirmed with my colleagues that do secops and the ports

Blocked email ports:
SMTP: 25, 465, 587, 2525
POP3: 110, 995
IMAP: 143, 993

remain blocked.

And please to end the discussion about this as I will be more happy to spend my time for developing then talking

ScreenReader

@elusiVeRPG said:

For now it stays like it is and cut off this topic. Im noob in this mater so I need to make consult with somebody who really has some knowledge about topic. EOL

• email abuse has monetary incentive, and is punished more harshly in your own IP range
• abuse email lands on average joes mailbox, only small % of them literate enough (again, this is why the punishment is harsher than yeeyeeahh ssh/web https bruteforce)
• people pretend to be dense and reguarded all the time so you will eventually allow email traffic
• traffic abuse will happens, pick the least punishment on you as a provider

@cmeerw said: But I would only associate email abuse with port 25, not with the other ports - those all require authentication, so it would just be abuse as any other kind of abuse. I am also seeing significantly less abuse on those ports than port 22. So why not also block port 22 then? And what about all the abuse on port 443?

why are you trying so hard to get OP allow email ports? are you one of 'em waiting to abuse this ipv6 project too?

cmon man, no need to pretend being dense.

Reguards.

cmeerw

@ScreenReader said:

@elusiVeRPG said:

For now it stays like it is and cut off this topic. Im noob in this mater so I need to make consult with somebody who really has some knowledge about topic. EOL

• email abuse has monetary incentive, and is punished more harshly in your own IP range
• abuse email lands on average joes mailbox, only small % of them literate enough (again, this is why the punishment is harsher than yeeyeeahh ssh/web https bruteforce)
• people pretend to be dense and reguarded all the time so you will eventually allow email traffic
• traffic abuse will happens, pick the least punishment on you as a provider

@cmeerw said: But I would only associate email abuse with port 25, not with the other ports - those all require authentication, so it would just be abuse as any other kind of abuse. I am also seeing significantly less abuse on those ports than port 22. So why not also block port 22 then? And what about all the abuse on port 443?

why are you trying so hard to get OP allow email ports? are you one of 'em waiting to abuse this ipv6 project too?

cmon man, no need to pretend being dense.

Please read up on how email works and what ports are used for what purposes, as what you are writing here shows a complete lack of understanding of the technical details.

elusiVeRPG

@cmeerw said:

@ScreenReader said:

@elusiVeRPG said:

For now it stays like it is and cut off this topic. Im noob in this mater so I need to make consult with somebody who really has some knowledge about topic. EOL

• email abuse has monetary incentive, and is punished more harshly in your own IP range
• abuse email lands on average joes mailbox, only small % of them literate enough (again, this is why the punishment is harsher than yeeyeeahh ssh/web https bruteforce)
• people pretend to be dense and reguarded all the time so you will eventually allow email traffic
• traffic abuse will happens, pick the least punishment on you as a provider

@cmeerw said: But I would only associate email abuse with port 25, not with the other ports - those all require authentication, so it would just be abuse as any other kind of abuse. I am also seeing significantly less abuse on those ports than port 22. So why not also block port 22 then? And what about all the abuse on port 443?

why are you trying so hard to get OP allow email ports? are you one of 'em waiting to abuse this ipv6 project too?

cmon man, no need to pretend being dense.

Please read up on how email works and what ports are used for what purposes, as what you are writing here shows a complete lack of understanding of the technical details.

So you are wrong I can consider to open 110, 995, 143, 993 but not
25, 465, 587, 2525 - as they can be used for SENDING emails and this is not under further discussion. Don't care that 465 and 587 are consider secure ports.

cmeerw

@elusiVeRPG said:

@cmeerw said:

@ScreenReader said:

@elusiVeRPG said:

For now it stays like it is and cut off this topic. Im noob in this mater so I need to make consult with somebody who really has some knowledge about topic. EOL

• email abuse has monetary incentive, and is punished more harshly in your own IP range
• abuse email lands on average joes mailbox, only small % of them literate enough (again, this is why the punishment is harsher than yeeyeeahh ssh/web https bruteforce)
• people pretend to be dense and reguarded all the time so you will eventually allow email traffic
• traffic abuse will happens, pick the least punishment on you as a provider

@cmeerw said: But I would only associate email abuse with port 25, not with the other ports - those all require authentication, so it would just be abuse as any other kind of abuse. I am also seeing significantly less abuse on those ports than port 22. So why not also block port 22 then? And what about all the abuse on port 443?

why are you trying so hard to get OP allow email ports? are you one of 'em waiting to abuse this ipv6 project too?

cmon man, no need to pretend being dense.

Please read up on how email works and what ports are used for what purposes, as what you are writing here shows a complete lack of understanding of the technical details.

So you are wrong I can consider to open 110, 995, 143, 993 but not
25, 465, 587, 2525 - as they can be used for SENDING emails and this is not under further discussion. Don't care that 465 and 587 are consider secure ports.

Well, the thing is that mail servers only accept unauthenticated email on port 25, but require authentication on any submission ports (you should expect to see as many email servers accepting unauthenticated mail on submission ports as you would expect IMAP servers to let you read emails without a password).

Edit: for additional details, feel free to consult RFC 6409 (and maybe pay particular attention to 4.3)

elusiVeRPG

@cmeerw said:

@elusiVeRPG said:

@cmeerw said:

@ScreenReader said:

@elusiVeRPG said:

For now it stays like it is and cut off this topic. Im noob in this mater so I need to make consult with somebody who really has some knowledge about topic. EOL

• email abuse has monetary incentive, and is punished more harshly in your own IP range
• abuse email lands on average joes mailbox, only small % of them literate enough (again, this is why the punishment is harsher than yeeyeeahh ssh/web https bruteforce)
• people pretend to be dense and reguarded all the time so you will eventually allow email traffic
• traffic abuse will happens, pick the least punishment on you as a provider

@cmeerw said: But I would only associate email abuse with port 25, not with the other ports - those all require authentication, so it would just be abuse as any other kind of abuse. I am also seeing significantly less abuse on those ports than port 22. So why not also block port 22 then? And what about all the abuse on port 443?

why are you trying so hard to get OP allow email ports? are you one of 'em waiting to abuse this ipv6 project too?

cmon man, no need to pretend being dense.

Please read up on how email works and what ports are used for what purposes, as what you are writing here shows a complete lack of understanding of the technical details.

So you are wrong I can consider to open 110, 995, 143, 993 but not
25, 465, 587, 2525 - as they can be used for SENDING emails and this is not under further discussion. Don't care that 465 and 587 are consider secure ports.

Well, the thing is that mail servers only accept unauthenticated email on port 25, but require authentication on any submission ports (you should expect to see as many email servers accepting unauthenticated mail on submission ports as you would expect IMAP servers to let you read emails without a password).

Edit: for additional details, feel free to consult RFC 6409 (and maybe pay particular attention to 4.3)

Do you see any technical problems to use authentication by spammers? This days is not a problem to send spam or scam and have ssl/tls....

cmeerw

@elusiVeRPG said:

@cmeerw said:

@elusiVeRPG said:

@cmeerw said:

@ScreenReader said:

@elusiVeRPG said:

For now it stays like it is and cut off this topic. Im noob in this mater so I need to make consult with somebody who really has some knowledge about topic. EOL

• email abuse has monetary incentive, and is punished more harshly in your own IP range
• abuse email lands on average joes mailbox, only small % of them literate enough (again, this is why the punishment is harsher than yeeyeeahh ssh/web https bruteforce)
• people pretend to be dense and reguarded all the time so you will eventually allow email traffic
• traffic abuse will happens, pick the least punishment on you as a provider

@cmeerw said: But I would only associate email abuse with port 25, not with the other ports - those all require authentication, so it would just be abuse as any other kind of abuse. I am also seeing significantly less abuse on those ports than port 22. So why not also block port 22 then? And what about all the abuse on port 443?

why are you trying so hard to get OP allow email ports? are you one of 'em waiting to abuse this ipv6 project too?

cmon man, no need to pretend being dense.

Please read up on how email works and what ports are used for what purposes, as what you are writing here shows a complete lack of understanding of the technical details.

So you are wrong I can consider to open 110, 995, 143, 993 but not
25, 465, 587, 2525 - as they can be used for SENDING emails and this is not under further discussion. Don't care that 465 and 587 are consider secure ports.

Well, the thing is that mail servers only accept unauthenticated email on port 25, but require authentication on any submission ports (you should expect to see as many email servers accepting unauthenticated mail on submission ports as you would expect IMAP servers to let you read emails without a password).

Edit: for additional details, feel free to consult RFC 6409 (and maybe pay particular attention to 4.3)

Do you see any technical problems to use authentication by spammers? This days is not a problem to send spam or scam and have ssl/tls....

Authentication means having some account credentials for that system (not just the use of SSL/TLS). And if they have those credentials, they could just as well use the web interface of the mail server to send their spam.

Do you block the Gmail web interface (or any other mail provider's web interface) because a spammer could log in to some Gmail account and send spam from there?

wadhah

@cmeerw why are you arguing so hard about opening mail ports on a free ipv6 tunnel service dude?

He dosent wanna deal with abuse, leave it at that. The project is going to be open source in the future so just fork it and open the mail ports all you want

BetaRacks

We need via wireguard

elusiVeRPG

@BetaRacks said:
We need via wireguard

Any source where to get know better how use wireguard protocols to tunnel ipv6 (never use it, so first I need to expand my knowledge in this topic)

cmeerw

@wadhah said:
@cmeerw why are you arguing so hard about opening mail ports on a free ipv6 tunnel service dude?

Because there is so much misinformation being repeated here.

He dosent wanna deal with abuse, leave it at that. The project is going to be open source in the future so just fork it and open the mail ports all you want

Please explain (maybe after reading some relevant technical documentation like RFC 6409) why blocking port 587 helps in dealing with abuse (I would think blocking port 587 would just confuse users for no good reason). Why not also block ports 22 and/or port 443 then? What criteria do you use for deciding what ports to block?

Carlin0

@BetaRacks said:
We need via wireguard

Me too

elusiVeRPG

@cmeerw said:

@wadhah said:
@cmeerw why are you arguing so hard about opening mail ports on a free ipv6 tunnel service dude?

Because there is so much misinformation being repeated here.

He dosent wanna deal with abuse, leave it at that. The project is going to be open source in the future so just fork it and open the mail ports all you want

Please explain (maybe after reading some relevant technical documentation like RFC 6409) why blocking port 587 helps in dealing with abuse (I would think blocking port 587 would just confuse users for no good reason). Why not also block ports 22 and/or port 443 then? What criteria do you use for deciding what ports to block?

Lets say im a lame and noob and I just want to block this port as I don't like this number

cmeerw

@elusiVeRPG said:

@cmeerw said:

@wadhah said:
@cmeerw why are you arguing so hard about opening mail ports on a free ipv6 tunnel service dude?

Because there is so much misinformation being repeated here.

He dosent wanna deal with abuse, leave it at that. The project is going to be open source in the future so just fork it and open the mail ports all you want

Please explain (maybe after reading some relevant technical documentation like RFC 6409) why blocking port 587 helps in dealing with abuse (I would think blocking port 587 would just confuse users for no good reason). Why not also block ports 22 and/or port 443 then? What criteria do you use for deciding what ports to block?

Lets say im a lame and noob and I just want to block this port as I don't like this number

Sure, that's fine.

elusiVeRPG

Bug not allowing second tunnel creation has been fixed.

Future plan:

If nothing else happens I hope to add NS records change ability for routed subnets and api for endpoint ip update till 15.04.2025

ashish168527

@elusiVeRPG said:
Bug not allowing second tunnel creation has been fixed.

Future plan:

If nothing else happens I hope to add NS records change ability for routed subnets and api for endpoint ip update till 15.04.2025

Awesome looking forward to it

nagual

Hello. This isn’t the first time I’ve encountered the tunnel broker’s 50 Mbps limitation. What is the reason for this restriction? Are there any issues with the tunnel?

ehab

i love it when mysunny always always has the ip6 balls in the thread

elusiVeRPG

@nagual said:
Hello. This isn’t the first time I’ve encountered the tunnel broker’s 50 Mbps limitation. What is the reason for this restriction? Are there any issues with the tunnel?

No just im new in this and I need first see how the usage will be after month or 2 then I will consider for example do 100mbps. Im limited to 1 gbps from my provider, this is one person project

d1m4s

wish you support ipv6 over wireguard since most of ISPs in my country are CGnat (both for mobile and fixed ISP) and they disable icmp packet.

elusiVeRPG

@d1m4s said:
wish you support ipv6 over wireguard since most of ISPs in my country are CGnat (both for mobile and fixed ISP) and they disable icmp packet.

I will think about it later on I haw no knowledge how to do it with wireguard

MMzF

@elusiVeRPG said:

@d1m4s said:
wish you support ipv6 over wireguard since most of ISPs in my country are CGnat (both for mobile and fixed ISP) and they disable icmp packet.

I will think about it later on I haw no knowledge how to do it with wireguard

Do let me know when you're ready to try setting up WireGuard, maybe I can help with that.

Starnberg

@d1m4s said: most of ISPs in my country are CGnat (both for mobile and fixed ISP) and they disable icmp packet

I've found that outgoing keep-alives (e.g., ICMPv6 ping) through the tunnel often helps work around CGNAT or stateful filtering (firewall, NAT, ...). As that goes through the tunnel, it should not be affected by the ISP filtering icmp.

Some ISPs don't support anything other than TCP, UDP, and ICMP, that often is the bigger challenge.

Obviously, YMMV.

Lucy9527

It's very cool. I think I'll like it.