[prev in list] [next in list] [prev in thread] [next in thread]
List: firewall-1
Subject: RE: [FW1] Cannot connect using public address
From: Daniel Hitchcock <DHitchcock () breakwatersecurity ! com>
Date: 2001-02-28 19:38:29
[Download RAW message or body]
Thanks to another list member for answering this question for me a while
back -
The reason the ping (and any other IP protocol) fails is that the client
originating the ping receives the reply from a different address than it
expects.
For example, if your machine (e.g. 10.5.5.5) pings server 209.5.5.5
(external NAT address), the firewall then translates the packet destination
and forwards the packet to the internal server (e.g. 10.5.5.1). When server
10.5.5.1 receives the ping and sees that its origin is 10.5.5.5 (on its same
subnet), it sends the reply directly back to the client (with a source of
its real ip, of course - 10.5.5.1). The client, upon receiving this packet,
ignores it, since it is waiting for a reply from 209.5.5.5.
Hope that makes sense. You may be able to work around it by creating a NAT
rule that translates both source and destination for packets from inside
headed for NATs on the firewall. It would need to go above any other NAT
rules involving either the internal network or the public servers. Haven't
had a chance to test...
The solution you propose (DNS) is the most common resolution to this issue.
I don't call it a "problem," since it's just the way that IP works.
Let me know if you have a chance to test, and what happens.
Dan Hitchcock
CCNA, CCSE, MCSE
Security Analyst
Breakwater Security Associates
206.770.0700 x147
dhitchcock@breakwatersecurity.com
http://www.breakwatersecurity.com <http://www.breakwatersecurity.com/>
-----Original Message-----
From: Tony Wong [mailto:twong@SolutionCentral.com]
Sent: Wednesday, February 28, 2001 11:15 AM
To: fw-1-mailinglist@lists.us.checkpoint.com
Subject: [FW1] Cannot connect using public address
We recently moved to usiing NAT on our firewall:
Private range: 192.168.0.0 -- 192.168.0.1- 192.168.0.100 for servers
switches etc
DHCP: 192.168.0.101 - 254 DHCP clients
We have internal web servers and mail server with FQDNs that outside can
access no problems by using static NAT.
Problem is internal client cannot connect to these public (statically
natted) ip addresses within the local network.
They can connect to it with the private address.
The only fix I have so far is by putting host files in their machines so
that the web and mail servers gets resolved to the private ip address. Also
using internal DNS.
Question is why are these internal clients not being able to access the
public ip address of the web server. I cannot ping this web server by its
public ip address.
I can ping the firewall both internal anfd public ip address.
Yes the web server's statically nated address is in the same subnet as the
firewall's external ip.
[Attachment #3 (text/html)]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META content="MSHTML 5.00.2920.0" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=876562619-28022001>Thanks
to another list member for answering this question for me a while back
-</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=876562619-28022001></SPAN></FONT> </DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=876562619-28022001>The
reason the ping (and any other IP protocol) fails is that the client originating
the ping receives the reply from a different address than it
expects.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=876562619-28022001></SPAN></FONT> </DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=876562619-28022001>For
example, if your machine (e.g. 10.5.5.5) pings server 209.5.5.5 (external NAT
address), the firewall then translates the packet destination and forwards the
packet to the internal server (e.g. 10.5.5.1). When server 10.5.5.1
receives the ping and sees that its origin is 10.5.5.5 (on its same subnet), it
sends the reply directly back to the client (with a source of its real ip, of
course - 10.5.5.1). The client, upon receiving this packet, ignores it,
since it is waiting for a reply from 209.5.5.5.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=876562619-28022001></SPAN></FONT> </DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=876562619-28022001>Hope
that makes sense. You may be able to work around it by creating a NAT rule
that translates both source and destination for packets from inside headed for
NATs on the firewall. It would need to go above any other NAT rules
involving either the internal network or the public servers. Haven't had a
chance to test...</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=876562619-28022001></SPAN></FONT> </DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=876562619-28022001>The
solution you propose (DNS) is the most common resolution to this issue. I
don't call it a "problem," since it's just the way that IP
works.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=876562619-28022001></SPAN></FONT> </DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=876562619-28022001>Let me
know if you have a chance to test, and what happens.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=876562619-28022001>
<P><B><FONT face=Garamond>Dan Hitchcock</FONT></B> <BR><B><FONT face=Garamond
size=2>CCNA, CCSE, MCSE</FONT></B> <BR><FONT face=Garamond>Security
Analyst</FONT> <BR><FONT face=Garamond>Breakwater Security Associates</FONT>
<BR><FONT face=Garamond>206.770.0700 x147</FONT> <BR><FONT
face=Garamond>dhitchcock@breakwatersecurity.com</FONT> <BR><FONT
face=Garamond><A href="http://www.breakwatersecurity.com/"
target=_blank>http://www.breakwatersecurity.com</A></FONT>
</P></SPAN></FONT></DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
<DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma
size=2>-----Original Message-----<BR><B>From:</B> Tony Wong
[mailto:twong@SolutionCentral.com]<BR><B>Sent:</B> Wednesday, February 28,
2001 11:15 AM<BR><B>To:</B>
fw-1-mailinglist@lists.us.checkpoint.com<BR><B>Subject:</B> [FW1] Cannot
connect using public address<BR><BR></DIV></FONT>
<DIV><FONT face=Arial size=2>We recently moved to usiing NAT on our
firewall:</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Private range: 192.168.0.0 -- 192.168.0.1-
192.168.0.100 for servers switches etc</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>DHCP: 192.168.0.101 - 254 DHCP
clients</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>We have internal web servers and mail server with
FQDNs that outside can access no problems by using static NAT.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Problem is internal client cannot connect to
these public (statically natted) ip addresses within the local
network.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>They can connect to it with the private
address.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>The only fix I have so far is by putting host
files in their machines so that the web and mail servers gets resolved to
the private ip address. Also using internal DNS.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>Question is why are these internal clients not
being able to access the public ip address of the web server. I cannot ping
this web server by its public ip address. </FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>I can ping the firewall both internal anfd public
ip address. </FONT></DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>Yes the web server's statically nated
address is in the same subnet as the firewall's external
ip.</FONT> </DIV></BLOCKQUOTE></BODY></HTML>
================================================================================
To unsubscribe from this mailing list, please see the instructions at
http://www.checkpoint.com/services/mailing.html
================================================================================
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic