NAT within packets

[Tamadite]

I am using firmware 1.8.1.9 and I have detected that it does not NAT IP addresses that are contained within the data area of packets.

You can see this when using "MSN Remote Assistance". When a PC behind a firewall accepts a remote assistance invitation, on a certain stage the PC behind the firewall informs the remote machine of its IP address and the port that the remote machine should use to get connected. When the packet goes through the firewall, it seems the firewall does inspect the whole packet down to the data field so the firewall does not NAT the LAN IP address that is provided by the host behind the firewall. This results on failed connection since the remote PC is to send a packet with a private IP address, eg. 192.168.1.2. It should be noticed here that it is not the return IP address of the packet (source/destination).

Even when it can not be considered a failure or bug, it is worth saying that such feature can be found in high-end routers (eg. Cisco PIX).

My questions are:
.1. Has this enhancement been implemented on some other firmware release for WL-500g?
.2. What is or could be the impact of this operation on the router? Obviously this will produce an extra-load on router's operations that would affect its throughput.

[brubber]

If both routers and workstations are UPnP compatible and configured correctly this shouldn't be a problem I think. As far as I know the WL-500g is UPnP compatible.

For configuration and some background see attached pdf

[Tamadite]

uPnP opens a security issue I'm not going to discuss in this thread. Thanks for your help and recommended link.

[brubber]

uPnP opens a security issue I'm not going to discuss in this thread. Thanks for your help and recommended link.I fully agree, this has been discussed in detail by Steve Gibson http://grc.com/unpnp/unpnp.htm. He also provides a small utility to enable / disable it on the fly.

Personally I think remote assistance is a security issue anyway, unless you are using a well secured connection.

[Antiloop]

i'll quote one thing


UnPnP says that UPnP is safely disabled, but my system's personal firewall keeps reporting UPnP traffic on port 1900.
UnPlug and Pray shuts down the UPnP server services, but it does not prevent Windows or its programs from acting as UPnP clients. Client programs like Windows itself, and later versions of Windows Messenger, periodically search the local network for a UPnP router to control. This network noise is annoying, but it does not mean that Windows' UPnP server is still active and insecure.

in fact UnPnP disables the server, and thus not the Windows uPnP client..

the wl500g does not accept uPnP shit from the outside..

meaning that you can run with uPnP...

[Tamadite]

Despite of the uPnP implementation Microsoft has done of this technology my concerns about security are mainly related to the whole concept itself.

A malicious code on a host in the LAN can exploit the uPnP technology to send unauthorised user information/system though a firewall by freely opening ports on the firewall.

(IMHO Asus firewall should show or keep the track of the opened ports by uPnP.)