Firewalled On Kad No More!

Let me share with you what I've learned from my successfully fighting "firewalled" status on the Kad network. As most folks reporting the problem do, I run eMule on a Windows host with a private IP, behind NAT.

Thank the Holy Mule, I'm the admin at my site, so I've been able to investigate the problem in detail. The story began as usual: I had opened needed ports on the WinXP host running eMule and forwarded the TCP and UDP ports from my border router to it, but yet my Kad status was "firewalled". To tease me further, it flipped to "open" and back once, when I was not touching my configuration at all. At the same time I was getting High ID on Ed2k.

Later I found that mapping the private IP to a dedicated public IP instead of just forwarding the ports would give me "open" status on Kad instantly. Then I returned to port forwarding configuration and tcpdumped on the internal and external interfaces simultaneously. Imagine my surprise when I saw that my NAT still was translating the source port in UDP datagrams initiated by my eMule, i.e., sent not in responce to a UDP request from the remote node.

That is, port forwarding configuration, at least in some routers, doesn't work in the opposite direction. You may have to configure your NAT additionally for it to keep the UDP source port when your eMule tries to contact a node outside. Keeping the UDP port is crucial for Kad because info on your IP and port is spread over the whole network.

Example:

Assume your eMule host is 10.1.1.10 on your intranet and gets NAT'ed to 2.2.2.2 on the Internet. The UDP port initially is 4672.

When your eMule tries to contact a Kad node with IP 3.3.3.3, your NAT translates its IP 10.1.1.10 to IP 2.2.2.2 and port 4672 to port, say, 65000. As long as your NAT keeps the translation entry, node 3.3.3.3 can contact you back at port 65000, too. However, other Kad nodes that have learned about you from 3.3.3.3 will believe that your UDP port is 65000, not 4672. Undoubtedly, they will fail to contact you at this port because the translation entry is valid for IP 3.3.3.3 only.

The solution is to tell your NAT to keep the source port, usually 4672, in outgoing Kad "sessions" (NAT entries created from outgoing UDP datagrams.)

A few days ago I returned to my old post to recall what the problem with Kad and NAT was, and I had hard time understanding my own text! Oh my, I had been so wordy back then! So I'll try to put it short now for the sake of clarity.

Suppose you are behind a NAT box under your control. If you have HighID on Ed2k servers but your Kad status stays Firewalled, you may need to review your NAT setup as follows.

First of all, make sure that UDP packets coming from the Internet to your public IP, say 2.2.2.2, and your Kad port, often 4672, are forwarded (redirected, mapped) to the actual IP of your eMule machine, say 10.1.1.10, and the same port, that is 4672. This is the obvious part: So other Kad peers on the Internet can initiate packet exchanges with you.

Now comes the less obvious part. You also need to arrange so that Kad UDP packets from your eMule to the Internet still have their source port equal to 4672 after NAT. I.e., the NAT box should be told to keep the soure port the same in outgoing Kad packets. At least some NAT boxes require a separate configuration rule for that. This rule will be applied by the NAT box to packet exchanges initiated by your own eMule.

Why is the latter NAT rule necessary? When you start up your eMule, no Kad peer on the Internet knows that your eMule is going to be reachable on IP 2.2.2.2 and port 4672. The Kad network learns about your node when your node initiates its firts Kad packet exchanges with some peers. This is why it's so important to preserve the source port number in your outgoing packets: Otherwise the Kad network would learn a wrong port and most Kad nodes wouldn't be able to contact you.

Keep in mind that today's NAT can substitute not only IP addresses but also port numbers unless told not to do so. E.g., when your eMule sends its opening packet to a peer from 10.1.1.10:4672, it can appear on the Internet as though coming from 2.2.2.2:65123 unless you've nailed down your outgoing Kad traffic to source port 4672 in your NAT config.

The above applies not only to eMule but to any Kad software, of course.

I understand little about networks etc, but I understand what you're saying about the 2 directions. However, how do I execute all this?
On my router, when I make a port forwaring rule, I have 2 textboxes, saying "port translation: start point, end point". Do I fill in the UDP port, so it doesn't change but stays the same number?

Lets assume that your firewall and router are indeed set up properly. If you have questions concerning your specific model, I suggest consulting the manual or Google.

On to the question:
Did you use the commands that are suggested when you request a file? i.e.
/mode me -x
and
/dccserver s on 59

Also note that these are mirc commands. If you are using some other funky client, they might be different.
Other than that, there isnt really much you can do. Certain firewalled bots just dont work for some people.
Good luck getting it to work. _