I'm trying to make a simple P2P chat application (in VB 2010 - just for practice) that uses UDP. I've finished the application, and I can send messages locally by sending on 127.0.0.1.

I've sent the executable to a buddy of mine to help me test it, but I'm unable to receive anything. My initial thought was that this was a NAT issue, and that I would have to employ an introducer to punch through my NAT. To keep things simple for now, I decided to just bypass my router entirely and connect directly to my modem in order to test this.

Still no dice. Just to be clear, I gave my friend my IP (96.55.XX.XX ... not a local address) and the port that my client is listening on.

Even if my friend is behind a NAT, shouldn't I still be able to receive packets? If I tried to reply to his messages, that could obviously be a problem if he's behind a NAT. I'm strictly talking about a one-way communication here though. Him sending messages to me.

I can't see it being a firewall issue either, since I've added a rule for my application in my firewall settings. Can anyone think of a reason as to why I wouldn't be able to receive his messages, despite the precautions I've taken?

Thanks in advance!

Some things to check:

1. Check that you are listening at the IP of your network card and not on 127.0.0.1

2. Activate the firewall and check if the packets of your college get blocked.

3. Take a packet sniffer and check if you can receive the packets with it.

#1) Could you elaborate on this point a bit? I create a UDPClient reciever that listens on port XYZ. I didn't specify a host address (although I could without any difficulty...perhaps I'll give this a shot - maybe it's defaulting to listen on 127.0.0.1 or something)

Update #1: I looked into this a bit more, and found the following documentation: http://msdn.microsoft.com/en-us/library/35e07es2.aspx

This constructor creates an underlying Socket and binds it to the port number from which you intend to communicate. Use this constructor if you are only interested in setting the local port number. The underlying service provider will assign the local IP address. If you pass 0 to the constructor, the underlying service provider will assign a port number. If this constructor is used, the UdpClient instance is set with an address family of IPv4 that cannot be changed or overwritten by a connect method call with an IPv6 target.

Maybe this is the problem! I'll update this again with my findings after I test it.

Update #2: I tested it again, specifying a listening host address set to my public IP, but still no luck. I performed this test while directly connecting to my modem to avoid any problems that my router might introduce. I also checked the traffic with Wireshark and noticed that the packets were being sent correctly, with the correct address and port, however, I was being informed by the ICMP that the destination was unreachable (port unreachable).

#2) I'm on a home network right now, so there shouldn't be any problem with certain packets getting blocked

#3) I have Wireshark, but I'm a bit inexperienced with it. I'll look into it though.

The "listening" part should bind to address 0.0.0.0 with a specific port (remember to use htons()). This will bind to all public interfaces. You can use "netstat -l" to see all bound services from the command line (both on Unix and Windows.)

Then you should make sure you allow the application to listen to public networks in the Windows Firewall settings, and it should work.

You can try running Ethereal on both your buddy's machine and your own machine when trying to connect, to see what kinds of packets are on the network in both places.

I define my listener as follows:

Public listenerEndpoint As New IPEndPoint(System.Net.IPAddress.Any, 54329)
Public rxClient As New UdpClient(listenerEndpoint) 'This client will listen on port 54329

I ran a netstat -a -p UDP command and found the following line:

Proto          Local Address       Foreign Address       State
  .                  .                    .
  .                  .                    .
 UDP           0.0.0.0:54329             *:*

It would appear as though everything is normal. I made an Inbound Rule in my firewall for my application and made sure that it's profiles are enabled for Domain, Public and Private connections. I also made Inbound and Outbound rules for Port 54329 which is the port that I'm listening on.

I tested it with my friend once again, and got the exact same results - I still don't receive anything. I can still receive messages locally if I send them to 127.0.0.1:54329 which tells me that the code for the listener is at least working as intended... I looked in Wireshark (on my end) and it still says that the port is unreachable when I send messages to my public IP address on port 54329.

Check to see if you ip from ipconfig/ifconfig and from a website such as whatismyipaddress.com gives the same ip.

You could be under an ISP NAT.

Check to see if you ip from ipconfig/ifconfig and from a website such as whatismyipaddress.com gives the same ip.

You could be under an ISP NAT.

I was always kind of hoping that this wouldn't be the case. I ran ipconfig and my public IP wasn't listed anywhere. I get the typical 192.168.XX.XX. This is all while bypassing my router and plugging directly into the modem.

If this is the case, and my ISP is providing NAT services, is there anything I can do? Also, is there a way that I can verify that this is absolutely the case, and not something else?

Update: Pretty sure the issue is with my modem. It has it's own NAT that I need to work around. I'm in the process of trying to find the default username / password that my ISP uses for this modem right now. I'll keep this post updated.

I figured it out!

It was my modem's settings. I had to forward the port I was using on my modem. It has it's own NAT which was enabled. For anyone who might be curious, my modem model is: SMCD3GN. The username / password were posted on a little sticker attached to the modem.

I've been struggling with this problem on and off for ages, and it never occurred to me that it was my modem that needed to be configured properly, and not my router.

Works like a charm now!