On Tue, 19 Jun 2012 22:21:11 +0900, Masataka Ohta said:
Or, a NAT gateway may receive packets to certain ports and behave as an application gateway to end hosts, if request messages to the server contains information, such as domain names, which is the case with DNS, SMTP and HTTP, to demultiplex the request messages to end
For SMTP, you'll have already consumed the 3 packet handshake and the EHLO, MAIL FROM, and at least one RCPT TO before you know which end host to demultiplex to (and even then, you may not unless the end hosts are running a DNS that advertises MX's with the NAT'ed IP in them). At that point, you have little choice but to then start up a conversation with the end host and relay the EHLO/MAIL FROM/RCPT TO and hope to heck that the end host doesn't reply differently to you than you did to the other end (in particular, you had to respond to the EHLO with a list of extensions supported - if you said you supported an extension that the end system doesn't actually have, you get to do fixups on the fly as you continue the MITM). And some things, like ssh or anything that uses OpenSSL, you'll have a very hard time because you need to respond with the right certificate or key, which you don't have.
hosts. However, for an ISP operating the NAT gateway, it may be easier to operate independent servers at default port for DNS, SMTP, HTTP and other applications for their customers than operating application relays.
So you're admitting that the NAT breaks things badly enough at the ISP level that running a forwarding ALG is easier than actually making the NAT work.
(HInt - we haven't solved that problem for NAT yet, it's one of the big reasons that NAT breaks stuff)
As you can see, there is no such problem.
You haven't actually *deployed* your solution in a production environment, have you?