Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Shells Virtual Desktop
BMail.ag - Secure Email Service
Server.net
CPLicense.net
VPS Server
Buy VPN
Vultr
VMs for AI
HostDare
ReliableSite White-Label Dedicated Hosting for Resellers
InterServer VPS
BMail.ag - Secure Email Service
Best VPN
High-Performance Bare Metal Server Solutions
Karvl.com
Server Mania Cloud Hosting
DataWagon Hosting
AlphaVPS Hosting
Evoxt.com
Clouvider
VPS Hosting with NVMe
Residential IPs in the US & 4G Mobile Proxies in EU & US with Unlimited Bandwidth
ReliableSite White-Label Dedicated Hosting for Resellers
Rabisu - Hosting Solutions
Shells Virtual Desktop
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

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

24

Comments

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

    Thanked by 1wadhah
  • Cool bro. Ipv6

    Thanked by 1elusiVeRPG
  • @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.

  • @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?

  • elusiVeRPGelusiVeRPG Member, Host Rep

    @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.

  • @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).

  • elusiVeRPGelusiVeRPG Member, Host Rep
    edited April 2025

    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 :)

  • @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.

  • @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.

  • elusiVeRPGelusiVeRPG Member, Host Rep
    edited April 2025

    @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.

  • cmeerwcmeerw Member
    edited April 2025

    @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)

  • elusiVeRPGelusiVeRPG Member, Host Rep

    @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....

  • @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?

  • wadhahwadhah Member, Host Rep

    @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

  • We need via wireguard

    Thanked by 2Carlin0 yoursunny
  • elusiVeRPGelusiVeRPG Member, Host Rep

    @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)

  • @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?

  • @BetaRacks said:
    We need via wireguard

    Me too

  • elusiVeRPGelusiVeRPG Member, Host Rep

    @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 :)

  • @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.

  • elusiVeRPGelusiVeRPG Member, Host Rep
    edited April 2025

    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

    Thanked by 1Starnberg
  • @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

    Thanked by 1elusiVeRPG
  • 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?

    Thanked by 1elusiVeRPG
  • ehabehab Member

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

    Thanked by 1yoursunny
  • elusiVeRPGelusiVeRPG Member, Host Rep

    @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 :)

    Thanked by 1Starnberg
  • d1m4sd1m4s Member

    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.

    Thanked by 1yoursunny
  • elusiVeRPGelusiVeRPG Member, Host Rep

    @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

  • MMzFMMzF Member

    @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.

  • @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.

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

Sign In or Register to comment.