More problems with OWAMP behind NAT

Well, not all NAT problems were solved with the fixes detailed in the previous post. Indeed, the server does not check that the OWAMP client is sending from the address specified in the "receiver IP address" field of the Request-session message, but there are some outstanding problems.

First, the server will create a new socket for the test session, and will attempt to bind that socket to the address specified for the sender or the receiver in the request-session message. This address is, of course, the public address of the server as the message was created and sent by the client. Obviously, the server will fail in binding that socket to a public address it is not in none of its interfaces.

Second, the client must specify its actual public address in the sender/receiver IP address field of the request-session message, otherwise, the other end will not be able to send test packets to that address.

Therefore, some modification is required in the OWAMP code. On the client side, the public address must be specified in the messages. Also, on the server side, the server should bind the test socket to the private address, regardless of the address specified in the session-request message.

The client needs to know its actual public address on the public side of the NAT, which is specified by the new '-x' option of the owping program. The owampd daemon only needs to know if it is running behind a NAT or not, but it doesn't know the public address, makeing the server setup more simple. The -N flag is used in this case.

So, the extra requirement is for the client to know its public address, which can be obtained by a STUN client or a similar service.

Now, it definitely works fine, with both the server and the client running behind their respective NATs.