Thanks Tim,<br><br>I should have remembered to put the router in - it's a Linksys WRT54g. I have used it before and am quite certain I was able to do the u-turn thing before. It doesn't offer iptables at all (or at least not any interface to that), although my CentOS server does. Even with the iptables turned off temporarily, I still could not do the u-turn. I am positive I did this before with this same router. I am actually considering upgrading the router - this one is ancient and I would like one that supports IPv6 as well as IPv4.<br>
<br>I am open to recommendations on such a router as well.<br><br><div class="gmail_quote">On Thu, Feb 2, 2012 at 13:39, Tim Young <span dir="ltr"><<a href="mailto:Tim.Young@lightsys.org">Tim.Young@lightsys.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Some routers support this, others do not. So this could be a router issue, not just a routing issue.<br>
<br>
What is happening is this. From inside your network on your client computer, you attempt to access the external interface. The local computer compares the destination ipaddress and netmask with it's own IP address and determines that the destination IP is not local. So, it sends it to the firewall (gateway). The gateway, upon receiving the packet, realizes that it needs to port-forward the packet back to the internal server. The return packet then goes from the server, back through the reverse NAT, and then back inside to your client computer. The issue is probably occurring inside the firewall when it first gets a packet from the client.<br>
<br>
Many firewalls on the port forwarding side of things only forward packets that come from the Internet. They do not have rules that look for packets with the source on the inside. The packets from the client are usually masqueraded to the outside world (so the source IP appears to be 174.96.151.128 to the outside). All sort of odd things could occur based on how the iptables rules are configured, which order they are in, etc.<br>
<br>
Anyway. Most likely your issue is an iptables issue on your firewall. Is that a linux box, or something else? Do you have the ability to hand-edit the iptables rules, or are they simply generated by a GUI? When you say "you have done this before", was that with this router with this configuration, or was that using a different router/firewall?<br>
<br>
- Tim Young<div><div class="h5"><br>
<br>
On 2/2/2012 11:35 AM, Don Parris wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
Guys,<br>
<br>
I have a routing issue. I am fairly certain it is a routing issue. I have configured my CentOS 6.2 server to provide SSH and WWW service. I can connect to the server via the internal IP (192.168*). I can likewise connect to the server via the external IP, but only from outside the LAN. What I cannot do is connect to the external IP from inside my LAN. I have done this several times before, but right now am just really confused.<br>
<br>
Router Internal IP is *.1 (provides DHCP to my LAN), External = *128<br>
Server IP is *.22<br>
<br>
<br>
Running traceroute from the server to the internal IP of the router gave *** as a result.<br>
Running traceroute from the laptop the the external IP of the router gave *** as a result.<br>
<br>
Running traceroute from my laptop to the server (from inside the router) gave this result:<br>
traceroute to 192.168.1.22 (192.168.1.22), 30 hops max, 60 byte packets<br>
1 192.168.1.22 (192.168.1.22) 7.639 ms !X 7.646 ms !X 7.639 ms !X<br>
<br>
man traceroute says the !X means "communication administratively prohibited".<br>
<br>
Here is my routing table on my router:<br>
0.0.0.0 255.255.255.0 174.96.151.128 WAN (Internet)<br>
0.0.0.0 0.0.0.0 174.96.128.1 WAN (Internet)<br>
174.96.128.0 255.255.224.0 174.96.151.128 WAN (Internet)<br>
192.168.1.0 255.255.255.0 192.168.1.1 LAN & Wireless<br>
<br>
<br>
I am just really confused.<br>
<br>
<br>
-- <br>
D.C. Parris, FMP, LEED AP O+M, ESL Certificate<br>
Minister, Security/FM Coordinator, Free Software Advocate<br>
<a href="https://www.xing.com/profile/Don_Parris" target="_blank">https://www.xing.com/profile/<u></u>Don_Parris</a> | <a href="http://www.linkedin.com/in/dcparris" target="_blank">http://www.linkedin.com/in/<u></u>dcparris</a><br>
GPG Key ID: F5E179BE<br>
<br>
<br>
<br></div></div>
______________________________<u></u>_________________<br>
ChristianSource FSLUG mailing list<br>
<a href="mailto:Christiansource@ofb.biz" target="_blank">Christiansource@ofb.biz</a><br>
<a href="http://cs.uninetsolutions.com" target="_blank">http://cs.uninetsolutions.com</a><br>
</blockquote>
<br>
______________________________<u></u>_________________<br>
ChristianSource FSLUG mailing list<br>
<a href="mailto:Christiansource@ofb.biz" target="_blank">Christiansource@ofb.biz</a><br>
<a href="http://cs.uninetsolutions.com" target="_blank">http://cs.uninetsolutions.com</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>D.C. Parris, FMP, LEED AP O+M, ESL Certificate<br>Minister, Security/FM Coordinator, Free Software Advocate<div><a href="https://www.xing.com/profile/Don_Parris" target="_blank">https://www.xing.com/profile/Don_Parris</a> | <a href="http://www.linkedin.com/in/dcparris" target="_blank">http://www.linkedin.com/in/dcparris</a></div>
<div>GPG Key ID: F5E179BE</div><br>