Does not use bind to local address for outgoing connections #6476

issue kroeckx openend this issue on July 26, 2015
  1. kroeckx commented at 10:38 am on July 26, 2015: none

    I have several IPv4 / IPv6 addresses on a host and I wish to use a specific one. So I set up the bind so it would use that. It seems to be using that for the bind() in the listen socket but not for the outgoing connections.

    I’ve tried settings externalip. That only seems to change the “localaddresses” returned by getnetworkinfo. I’m guessing that’s mostly useful for NAT.

  2. laanwj added the label Feature on Jul 27, 2015
  3. laanwj added the label P2P on Jul 27, 2015
  4. laanwj commented at 1:04 pm on July 27, 2015: member
    Right, there is no option to specify binding for outgoing connections. I’d be OK with a per-network (IPv4/IPv6) setting that specifies this. Be aware that enforcing this at application level is, in practice, impossible to make watertight - e.g. impossible for DNS lookups. So if this is for security or privacy reasons I’d strongly recommend to do this at the OS level (eg by giving a certain user only access to certain network interface).
  5. kroeckx commented at 4:54 pm on July 31, 2015: none
    I don’t care about things like DNS, I would just like the bitcoin traffic itself to go over the addresses I select.
  6. sipa commented at 5:44 pm on July 31, 2015: member
    Seems reasonable to implement.
  7. phatkiller commented at 2:29 am on May 2, 2016: none
    Has this been implemented ? If not is there a timeframe for it ?
  8. jonasschnelli commented at 6:57 am on May 2, 2016: contributor
    @phatkiller: The issue is still open that’s a sign that nobody has implemented it right now. We don’t have a timeframe for features. Bitcoin-Core is an open source project, it will only be implemented if someone invests time to implement a such feature (which mostly is a sign that someone requires that feature).
  9. laanwj commented at 9:57 am on May 4, 2016: member
    If you need this, you need to make sure it gets implemented yourself. This is not a place to get free (as in beer) development resources.
  10. mrobinton commented at 9:41 pm on October 2, 2019: none

    What is required is to bind the socket to the -bind address prior to connecting to the remote site, not the usual way this would be done. I’ve looked at the code in net.cpp and netbase.cpp and boost appears to be in use and the location of the -bind ip constant is not obvious to me. I’m not skilled with c++. Here’s a rough outline of what needs to be done but I don’t have the skill to do it in the cpp environment. Perhaps someone else will pick up this thread.

    Found this doing research on the issue. No error checking.

    int sockfd = socket(AF_INET, SOCK_STREAM, 0); // Bind to a specific network interface (and optionally a specific local port) struct sockaddr_in localaddr; localaddr.sin_family = AF_INET; localaddr.sin_addr.s_addr = inet_addr(“192.168.1.100”); localaddr.sin_port = 0; // Any local port will do bind(sockfd, (struct sockaddr *)&localaddr, sizeof(localaddr));

  11. ryanofsky commented at 3:16 pm on October 3, 2019: contributor
    This seems like an unusual request. Do you need bitcoin to use different outgoing IP address than other applications on the system? Or to connect from a different IP address than it it listens on? If not, it seems like you could be better off just fixing the routing table: https://serverfault.com/questions/182550/specifing-ip-address-for-outbound-connections-on-a-multi-ip-host
  12. infernix commented at 11:32 am on October 4, 2019: none
    This can’t be fixed through a routing table because it’s not about return packets for incoming connections but for packets that are for connections initiated by the process itself, which if not bindable to a specific IP (as per this request) will just use the hosts’ default IP (which may not be the IP where incoming packets arrive). So not that unusual of a request, I had to dockerize and apply some iptables magic to make this work right on a node with multiple IPs within the same subnet.
  13. Nyanraltotlapun commented at 3:40 pm on November 16, 2021: none

    This seems like an unusual request. Do you need bitcoin to use different outgoing IP address than other applications on the system?

    I feel that this is needed for avoiding mess up with IPv6 privacy randomized addresses.

  14. vasild commented at 11:00 am on August 5, 2023: contributor

    This request looks reasonable. Is there still interest in it?

    Something like this should do it (and pass the proper argument to ConnectSocketDirectly() untested):

     0-bool ConnectSocketDirectly(const CService &addrConnect, const Sock& sock, int nTimeout, bool manual_connection)
     1+bool ConnectSocketDirectly(const std::optional<CNetAddr>& addr_from, const CService &addrConnect, const Sock& sock, int nTimeout, bool manual_connection)
     2 {
     3     // Create a sockaddr from the specified service.
     4     struct sockaddr_storage sockaddr;
     5     socklen_t len = sizeof(sockaddr);
     6     if (sock.Get() == INVALID_SOCKET) {
     7         LogPrintf("Cannot connect to %s: invalid socket\n", addrConnect.ToStringAddrPort());
     8         return false;
     9     }
    10     if (!addrConnect.GetSockAddr((struct sockaddr*)&sockaddr, &len)) {
    11         LogPrintf("Cannot connect to %s: unsupported network\n", addrConnect.ToStringAddrPort());
    12         return false;
    13     }
    14 
    15+    if (addr_from.has_value()) {
    16+        struct sockaddr_storage storage;
    17+        struct sockaddr* saddr_from = reinterpret_cast<struct sockaddr*>(&storage);
    18+        socklen_t saddr_from_len = sizeof(storage);
    19+        if (!CService{addr_from.value(), /*port=*/0}.GetSockAddr(saddr_from, &saddr_from_len)) {
    20+            LogPrintLevel(
    21+                BCLog::NET,
    22+                BCLog::Level::Error,
    23+                "Cannot connect to %s: unsupported network of the specified outbound address %s\n",
    24+                addrConnect.ToStringAddrPort(),
    25+                addr_from->ToStringAddr());
    26+            return false;
    27+        }
    28+        if (sock.Bind(saddr_from, saddr_from_len) == SOCKET_ERROR) {
    29+            LogPrintLevel(
    30+                BCLog::NET,
    31+                BCLog::Level::Error,
    32+                "Cannot connect to %s: unable to bind to the specified outbound address %s: %s\n",
    33+                addrConnect.ToStringAddrPort(),
    34+                addr_from->ToStringAddr(),
    35+                NetworkErrorString(WSAGetLastError()));
    36+            return false;
    37+        }
    38+    }
    39+
    40     // Connect to the addrConnect service on the hSocket socket.
    41     if (sock.Connect(reinterpret_cast<struct sockaddr*>(&sockaddr), len) == SOCKET_ERROR) {
    
  15. Nyanraltotlapun commented at 11:05 am on August 6, 2023: none
    Well, I still interested in it. It is a logical thing to do in general. I think people uses some workarounds for this when they need this, but have native behavior is right thing to do.
  16. mahdibx commented at 10:26 pm on April 16, 2025: none
    Also, as the score is set by address, having multiple outgoing addresses means that the score of your node will be all over the place depending on which address other nodes know you by. I think it’s reasonable to add an option to set the outgoing ipv6 address.
  17. 8144225309 commented at 4:30 am on January 26, 2026: none

    I’m running 3 node implementations: Core, Knots, and Libre on one VPS with symlinked blocks, so I would benefit from this feature directly. I’m going to do some reviews then take a crack at this unless someone else is still interested, or if anyone wants to share ideas for this.

    edit: #35027

  18. 8144225309 referenced this in commit 9525e07002 on Apr 3, 2026
  19. 8144225309 referenced this in commit b18f44a073 on Apr 3, 2026
  20. 8144225309 referenced this in commit 84d2db9717 on Apr 3, 2026
  21. 8144225309 referenced this in commit b7aee6f241 on Apr 3, 2026
  22. 8144225309 referenced this in commit a008158a3b on Apr 3, 2026
  23. 8144225309 referenced this in commit 8a18708567 on Apr 5, 2026
  24. 8144225309 referenced this in commit 07df4edda5 on Apr 5, 2026
  25. 8144225309 referenced this in commit 03d8a5679b on Apr 5, 2026
  26. 8144225309 referenced this in commit 03f80e674a on Apr 5, 2026
  27. 8144225309 referenced this in commit 46ed6f7e49 on Apr 5, 2026
  28. 8144225309 referenced this in commit 25d8dc1f97 on Apr 5, 2026
  29. 8144225309 referenced this in commit 0a963c5901 on Apr 7, 2026
  30. 8144225309 referenced this in commit b1d2999372 on Apr 7, 2026

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2026-04-12 09:13 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me