Mac client talking to itself on en0

[blaked36]

I use ipfw, and I have a rule set to allow the computer to talk to itself via loopbacks (i.e., "allow ip from any to any via lo*"). Conversely, I have a rule to deny any other traffic "from me to me" in order to prevent possible spoofing. Transmission commonly gets caught by that rule and is clearly trying to talk to itself on en0 rather than a loopback. Is there a reason for this? What information is being communicated there? Transmission is otherwise working.

[livings124]

This happens to other clients as well. What's happening is the tracker sends you back your own address in the peer list of IP addresses, and there's not a way to get your public IP address that's all 3 of: simple, reliable, portable.

[Waldorf]

I might have a valid suggestion for your "3": ​http://myip.dnsomatic.com/.

[livings124]

We can't feasibly be querying a website all the time for that.

[Waldorf]

Actually, I have no idea why you'd want to do this, or wether this would be necessary, but you could fetch the IP at startup?

[livings124]

That says it all.

[blaked36]

Hmmm... I'm still not sure I understand. I get that my public IP address would be in the list of peers, but the address I'm seeing is the private IP behind NAT: from 192.168.0.10 (me) to 192.168.0.10 over en0. Can you elaborate? Also, is there any drawback to not allowing that traffic? As I said, Transmission otherwise seems to be working. Thanks!

[blaked36]

Actually, maybe I do get it. Please clarify if I'm right. Transmission is actually sending an outbound packet from 192.168.0.10 (me, private) to whatever my public IP happens to be at the time. The router sees the packet's destination is to itself (the WAN side public IP address), translates it back to the private address, then sends it back to me. Correct? That makes sense and explains a lot if I've got it right.

I'm still curious about any drawbacks to blocking the traffic, though. Thanks. This has been enlightening.

[John Clay]

I'm not quite sure how to explain this, other than rehashing what's already been said. The tracker is sending out a list of peers, of which you are one. Not knowing what your external IP address is, Transmission attempts to contact itself. Once the connection is established, and Transmission realizes that it's talking to itself, it hangs up. Unless you've got a subnet setup, your router isn't going to handle any external IPs within the NAT. It's going to translate the forwarded port into a LAN IP (your 192.168.0.10), and send the packet on its way.

There aren't any drawbacks to the end result of blocking self-direct traffic, but there isn't an easy, reliable, and portable way of creating that block. You'd need to verify the port being used, IP address, etc before blocking. It's simply not worth the time and effort.

[blaked36]

If you mean that it's not worth the time and effort to get Transmission itself to block the traffic, I agree. My concern was that I'm already blocking the self-directed traffic as a side-effect of one of my ipfw rules to prevent spoofing: "deny log ip from me to me". So blocking the traffic is quite easy, from that perspective, but it wasn't my intent. Apparently it's not an issue, from what everyone here is saying, so I'm not going to worry about unblocking that traffic.

I'm afraid the last two sentences of your first paragraph don't make much sense from a networking perspective. What do you mean by, "Unless you've got a subnet setup"?

Let me see if I can clarify what I now understand is happening, step by step, for anyone getting lost reading this. Let's say my public IP address is 200.200.200.200, and my private address is 192.168.0.10, with NAT translation obviously being handled at the router. Let's also say Transmission is configured to use port 55555 at the transport layer. Since Transmission sees 200.200.200.200 as a peer--and doesn't know that the address leads to itself--it attempts to talk to that address. The packet Transmission sends is addressed to 200.200.200.200, from 192.168.0.10. It is received by the router, which sees the destination IP address of 200.200.200.200 in the packet header and compares that address to its routing table. It then recognizes that the packet is destined for itself (that is, the router--specifically, the router's WAN side address of 200.200.200.200). Examining the TCP or UDP segment header, the router sees the destination port number of 55555. Consulting its port forwarding configuration for that port, it finds the NAT translation of 200.200.200.200 --> 192.168.0.10 and readdresses the packet for 192.168.0.10. Because the packet is not routed out onto the WAN, NAT translation is not done on the source IP address of the packet, which is left at 192.168.0.10, only the destination address. The packet is then sent from the router back to the host computer (source 192.168.0.10, destination 192.168.0.10), where it is received by Transmission.

Actually, looking at that explanation, one way Transmission could block the outbound traffic at least part of the time is to simply look at the port number. If I'm using port 55555 and my peer is using port 55555, then the peer is me. The only time you'd run into trouble is if more than one peer is using the same port (unlikely, but possible), in which case Transmission could simply allow the traffic. Still, I agree that it's not really worth the trouble. But it is interesting.