Netgear → Re: Trouble with SSL NAT - FR114P

It would be easier to understand it if you knew that in any TCP connection there is a source port and there is a destination port. The TCP header in each and every packet that travels over the networks has the information for both of these port numbers. Thus a destination port is always a port number which is what the server (in your case SSL 443) is listening on and a source port is a random port (selectable by the Operating System Socket library) usually greater than 1024 and less than 5000. The Internet Naming Authority (IANA) has reserved this port range for dynamic source port assignment.

The reason why this is done is to maintain a pipelining of a virtual circuit that the TCP connection requires for end to end reliable connectivity. If the source port and the destination port is the same then TCP multiplexing would never have been possible. To understand the concept in greater detail I suggest some additional reading on this subject. The TCP RFC would be an excellent reference (»www.faqs.org/rfcs/rfc793.html).

Coming back to your problem, if you are trying to access the server from behind the router itself by using the public IP or the Dynamic DNS name then this would never work since the router does not support loopback proxy (meaning that it cannot establish a port connection for the same port inbound as well as outbound). If you are connecting to the server externally then you must be going to something like this:

code:

---

https://yourserver.dyndns.org/

---

If the router is still dropping the connection then seems like some problem with the router only. You could try to upload the same Firmware again and then afterwards reset and reconfigure the router. Also as melevittfl said, posting the logs would be a great help in really understanding the problem.

Thanks, I think I have a pretty good grasp of the IP port basics now. Here is an excerpt from the log:

Wed, 2003-06-25 11:24:52 - TCP packet - Source:194.xxx.xxx.xxx
,49450 WAN - Destination:217.xxx.xxx.xxx,443 LAN - [Inbound Rule(1) not match]

This is what I get when using the »etc URL from the outside. I'm not doing any loopback.

The rule itself looks like this:

Rule 4 HTTPS ALLOW always 192.168.50.5 Any Always

I can connect to another site on the same server, not using SSL. I have verified that the rule uses port 443.

Any suggestions?

//nize

said by nize123:

---

Here is an excerpt from the log:

Wed, 2003-06-25 11:24:52 - TCP packet - Source:194.xxx.xxx.xxx
,49450 WAN - Destination:217.xxx.xxx.xxx,443 LAN - [Inbound Rule(1) not match]

The rule itself looks like this:

Rule 4 HTTPS ALLOW always 192.168.50.5 Any Always

---

Hmm. Interesting. Your stating that HTTPS Allow rule is number 4. The Log is saying that Rule number 1 did not match. That's reasonable. The log is saying that the incoming packet was evaluated by rule #1 but it didn't match. There's nothing there about Rule number 4 matching? Also, the log isn't saying it dropped the packet.

Need more data:
What does Rule 1 say? Is there any log entry that mentions Rule 4? I.e., [Inbound rule(4) match]... please post it. Also, if there is a log entry that shows the final outcome of the packet (dropped, forwarded, etc) please post that as well.

It may help to know what rule 2 and 3 say as well.

Thanks for all the help with this issue, guys. Clearing up my confusion concerning the TCP/IP ports really helped me trace the problem. It seems to have been related to the SSL certificate after all - after a bit of work on that end it now works. The log entries led me to believe that it was related to the firewall, but after getting the port functions explained to me I could narrow the scope down and start to exclude certain things.

Anyway, I got it working now - so thanks a lot for all the help!

//nize