DNS and NAT

DNS and NAT

[Suzana Lojic-Skoric]

Does DNS work with iptables NAT or I need some kind of ALG to get DNS 
answers translated?

I am using Mandrake Linux 10.0. I have two way NAT going on and I am trying 
to get DNS requests through the NAT. I got FTP, HTTP and SMTP working 
through the NAT, but DNS is not working properly, DNS answer is not getting 
translated. Source and Destination addresses in DNS message are properly 
translated, but the actual answer (the ip address embedded in the message) 
is not translated.

Thanks

_________________________________________________________________
Powerful Parental Controls Let your child discover the best the Internet has 
to offer.  
http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines 
  Start enjoying all the benefits of MSN® Premium right now and get the 
first two months FREE*.

Re: DNS and NAT

[Jason Opperisano]

On Mon, Jul 11, 2005 at 12:37:31PM -0700, Suzana Lojic-Skoric wrote:
> Does DNS work with iptables NAT or I need some kind of ALG to get DNS 
> answers translated?
> 
> I am using Mandrake Linux 10.0. I have two way NAT going on and I am trying 
> to get DNS requests through the NAT. I got FTP, HTTP and SMTP working 
> through the NAT, but DNS is not working properly, DNS answer is not getting 
> translated.

nor should it be.

> Source and Destination addresses in DNS message are properly 
> translated, but the actual answer (the ip address embedded in the message) 
> is not translated.

which is exactly how it's supposed to work.  how the $%#@ is iptables
supposed to know what to rewrite the answer to?

if you are using BIND, look into the functionality offered by "views."

-j

--
"Peter: You know, I oughta just give you some beer. Goes straight
 through you. 
 Stewie: Wonderful. And while we're at it, we can light up a doobie and
 watch porn. 
 Peter: Eh... yeah?"
        --Family Guy

Re: DNS and NAT

[Suzana Lojic-Skoric]

OK, thanks I was not sure what is the proper behavior regarding iptables and 
DNS.

If answer is not translated then how do I get DNS to work with two way NAT?
My internal network does not understand any of the ip addresses that belong 
to outside. So if the request for a page that is sent from internal network 
comes back from outside with an answer (ip address) that is not getting 
translated then I can't resolve the page since my internal network doesn't 
understand it and can't route to it.
Is there a way around this problem? How do I get DNS to work in the type of 
environment I described?

Thanks


>From: Jason Opperisano <opie@817west.com>
>To: netfilter@lists.netfilter.org
>Subject: Re: DNS and NAT
>Date: Mon, 11 Jul 2005 15:41:13 -0400
>
>On Mon, Jul 11, 2005 at 12:37:31PM -0700, Suzana Lojic-Skoric wrote:
> > Does DNS work with iptables NAT or I need some kind of ALG to get DNS
> > answers translated?
> >
> > I am using Mandrake Linux 10.0. I have two way NAT going on and I am 
>trying
> > to get DNS requests through the NAT. I got FTP, HTTP and SMTP working
> > through the NAT, but DNS is not working properly, DNS answer is not 
>getting
> > translated.
>
>nor should it be.
>
> > Source and Destination addresses in DNS message are properly
> > translated, but the actual answer (the ip address embedded in the 
>message)
> > is not translated.
>
>which is exactly how it's supposed to work.  how the $%#@ is iptables
>supposed to know what to rewrite the answer to?
>
>if you are using BIND, look into the functionality offered by "views."
>
>-j
>
>--
>"Peter: You know, I oughta just give you some beer. Goes straight
>  through you.
>  Stewie: Wonderful. And while we're at it, we can light up a doobie and
>  watch porn.
>  Peter: Eh... yeah?"
>         --Family Guy
>

_________________________________________________________________
Designer Mail isn't just fun to send, it's fun to receive. Use special 
stationery, fonts and colors. 
http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines 
  Start enjoying all the benefits of MSN® Premium right now and get the 
first two months FREE*.

Re: DNS and NAT

[Jason Opperisano]

On Mon, Jul 11, 2005 at 01:33:34PM -0700, Suzana Lojic-Skoric wrote:
> OK, thanks I was not sure what is the proper behavior regarding iptables 
> and DNS.
> 
> If answer is not translated then how do I get DNS to work with two way NAT?
> My internal network does not understand any of the ip addresses that belong 
> to outside. So if the request for a page that is sent from internal network 
> comes back from outside with an answer (ip address) that is not getting 
> translated then I can't resolve the page since my internal network doesn't 
> understand it and can't route to it.
> Is there a way around this problem? How do I get DNS to work in the type of 
> environment I described?

with what is called "split DNS."  essentially:  requests from the
internal network get internal IP's as responses, requests from the
outside networks get external IP's as responses.  like i said in my
first reply; with BIND, this is accomplished through the use of "views."
i am not familiar with how other DNS servers handle this.

a more complete explanation of BIND views and an example of using views
for split DNS can be found at:

  http://www.zytrax.com/books/dns/ch7/view.html

-j

--
"Chris: Dad, what's the blowhole for?
 Peter: I'll tell you what it's not for. And when I do, you'll
 understand why I can never go back to Sea World."
        --Family Guy

Re: DNS and NAT

[/dev/rob0]

Please don't top-post. Thank you.

Suzana Lojic-Skoric wrote:
> OK, thanks I was not sure what is the proper behavior regarding
> iptables and DNS.

The usual situation is that clients are NAT'ed out, like what you're 
describing.

> If answer is not translated then how do I get DNS to work with two way NAT?

What does not work? Two-way NAT is fine. You go on to say you're not 
really talking about two-way NAT:

> My internal network does not understand any of the ip addresses that 
> belong to outside. So if the request for a page that is sent from 
> internal network comes back from outside with an answer (ip address) 
> that is not getting translated then I can't resolve the page since my 
> internal network doesn't understand it and can't route to it.

Clients need to have a default route through the NAT gateway, which does 
SNAT or MASQUERADE. How is it two-way if the clients can't route out?

> Is there a way around this problem? How do I get DNS to work in the type 
> of environment I described?

If you don't want to allow NAT clients out for some reason, you might 
check into running proxy servers, such as squid for HTTP/FTP. Only the 
services you are proxying can be used by internal clients. SOCKS proxy 
servers can handle multiple protocols, but I don't know anything more 
about it than just that fact.

Proxy servers are a good choice in some circumstances; you maintain 
maximum control over what clients can and cannot do (unless users have 
shell access to the proxy server, perhaps.) But proxying is far more 
resource-intensive than NAT.
-- 
     mail to this address is discarded unless "/dev/rob0"
     or "not-spam" is in Subject: header

Re: DNS and NAT

[Jan Engelhardt]

> Proxy servers are a good choice in some circumstances; you maintain maximum
> control over what clients can and cannot do (unless users have shell access to
> the proxy server, perhaps.) But proxying is far more resource-intensive than
> NAT.

Not hard either. Just catch any non-squid packets and redir them to lo. In 
iptables words:

  -A OUTPUT -j DNAT -p tcp --dport {80|3128} --to-dest 127.0.0.1:80 \
    -m owner ! --uid-owner squid

{80,3128} depending on whether you want transparent(80) proxying or 
intercepted(3128) proxying.

Since squid usually listens on an unprivilegued port (3128), the socket 
creation can be deferred until after the setuid from root to squid; therefore, 
the socket belongs to "squid" and thus, --uid-owner can match.


Jan Engelhardt
-- 
| Alphagate Systems, http://alphagate.hopto.org/

Re: DNS and NAT

[R. DuFresne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 11 Jul 2005, Suzana Lojic-Skoric wrote:

> OK, thanks I was not sure what is the proper behavior regarding iptables and 
> DNS.
>
> If answer is not translated then how do I get DNS to work with two way NAT?
> My internal network does not understand any of the ip addresses that belong 
> to outside. So if the request for a page that is sent from internal network 
> comes back from outside with an answer (ip address) that is not getting 
> translated then I can't resolve the page since my internal network doesn't 
> understand it and can't route to it.
> Is there a way around this problem? How do I get DNS to work in the type of 
> environment I described?


You could always just push /etc/hosts files out with the inside addresses 
there, if you have troubles with DNS setup.  Slow, crude, yet effective. 
The poorman's way...

Thanks,

Ron DuFresne
- -- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         admin & senior security consultant:  sysinfo.com
                         http://sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A  E838 B2DF AFCC 94B0 6629

...We waste time looking for the perfect lover
instead of creating the perfect love.

                 -Tom Robbins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFC00Ghst+vzJSwZikRAiPtAKCN0xJK03V94Z/tqhLH2BH/0j6EhACgvJna
jvGcXe/gClTpOpIyXwzwP+4=
=1FJ3
-----END PGP SIGNATURE-----

Re: DNS and NAT

[Suzana Lojic-Skoric]

>From: /dev/rob0 <rob0@gmx.co.uk>
>To: netfilter@lists.netfilter.org
>Subject: Re: DNS and NAT
>Date: Mon, 11 Jul 2005 16:25:20 -0500
>
>Please don't top-post. Thank you.
>
>Suzana Lojic-Skoric wrote:
>>OK, thanks I was not sure what is the proper behavior regarding
>>iptables and DNS.
>
>The usual situation is that clients are NAT'ed out, like what you're 
>describing.
>
>>If answer is not translated then how do I get DNS to work with two way 
>>NAT?
>
>What does not work? Two-way NAT is fine. You go on to say you're not really 
>talking about two-way NAT:
>
>>My internal network does not understand any of the ip addresses that 
>>belong to outside. So if the request for a page that is sent from internal 
>>network comes back from outside with an answer (ip address) that is not 
>>getting translated then I can't resolve the page since my internal network 
>>doesn't understand it and can't route to it.
>
>Clients need to have a default route through the NAT gateway, which does 
>SNAT or MASQUERADE. How is it two-way if the clients can't route out?
>
I have an internal network that has one set of addresses and outside network 
that has
a different set of addresses. I am using NAT for the sole purpose of 
translation. Both inside and outside network have DNS servers, mail 
servers,.... Both networks need to talk to each other, send mail and request 
web pages... I have a control of inside network but not the outside ntw.

When the client from outside sends a DNS query to the inside ntw I guess I 
can implement split DNS as Jason Opperisano suggested and get it working 
that way. The outside world will get a web page from external view and will 
have answer from global outside address, the inside world will get answer 
from internal view with inside global ip.

The problem is I don't understand how it is supposed to work when the client 
is inside and sending a request for a page whose server happens to be 
outside...
I have a default route through the NAT, so when a client on the inside 
network
sends a DNS query it goes out through the NAT, in my case both source
and destination gets translated and forwarded to outside DNS server.( I have 
to translate the destination as well because the clients on internal network 
send a request to an internal DNS server with the internal IP address as 
destination. So the request gets forwarded to the outside world through the 
NAT and both SNAT-ed and DNAT-ed.) When the answer comes back to NAT, the 
outside source and destination IP gets translated back to the internal 
addresses, but the actual IP that resolves the requested page is embedded in 
the message, and it does not get translated ( it is outside IP) When the 
client gets the answer, it processes it, gets the outside IP from the 
message and try talk to it. But this is outside IP and inside clients can't 
route to it.

I am trying to understand how is this supposed to work. I can't quite use 
the wisdom from masquerade because masquerade is simpler, masquerade 
messages are only SNAT-ed, meaning only source address is translated and 
when the request comes back it is then DNAT-ed to internal network, meaning 
destination is translated so the message can find your machine. But you 
don't care that google.com resolved as 216.239.39.99 because your NAT is one 
way NAT in you can talk to 216.239.39.99. In my case, I have to translate 
the 216.239.39.99 to something else (for example 10.1.1.1) so that the 
inside network can talk to it. And then on the exit through the nat 10.1.1.1 
will be translated back to 216.239.39.99. The problem is I have no way of 
translating the 216.239.39.99 to 10.1.1.1 because iptables NAT does not 
inspect the payload of the DNS answer and does not translate it. ... and 
this is how iptables is supposed to work.

I have both DNAT and SNAT happening both ways, when the message goes out and 
comes back in. All messages on inside network mast have both source and 
destination from the inside IP address range. Also I can't advertise my 
inside addresses to the outside world.


>>Is there a way around this problem? How do I get DNS to work in the type 
>>of environment I described?
>
>If you don't want to allow NAT clients out for some reason, you might check 
>into running proxy servers, such as squid for HTTP/FTP. Only the services 
>you are proxying can be used by internal clients. SOCKS proxy servers can 
>handle multiple protocols, but I don't know anything more about it than 
>just that fact.
>
>Proxy servers are a good choice in some circumstances; you maintain maximum 
>control over what clients can and cannot do (unless users have shell access 
>to the proxy server, perhaps.) But proxying is far more resource-intensive 
>than NAT.
>--
>     mail to this address is discarded unless "/dev/rob0"
>     or "not-spam" is in Subject: header
>

_________________________________________________________________
Take charge with a pop-up guard built on patented Microsoft® SmartScreen 
Technology  
http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines 
  Start enjoying all the benefits of MSN® Premium right now and get the 
first two months FREE*.

Re: DNS and NAT

[Jörg Harmuth]

Suzana Lojic-Skoric schrieb:

> I have an internal network that has one set of addresses and outside
> network that has
> a different set of addresses. I am using NAT for the sole purpose of
> translation. Both inside and outside network have DNS servers, mail
> servers,.... Both networks need to talk to each other, send mail and
> request web pages... I have a control of inside network but not the
> outside ntw.
> 
> When the client from outside sends a DNS query to the inside ntw I guess
> I can implement split DNS as Jason Opperisano suggested and get it
> working that way. The outside world will get a web page from external
> view and will have answer from global outside address, the inside world
> will get answer from internal view with inside global ip.
> 
> The problem is I don't understand how it is supposed to work when the
> client is inside and sending a request for a page whose server happens
> to be outside...
> I have a default route through the NAT, so when a client on the inside
> network
> sends a DNS query it goes out through the NAT, in my case both source
> and destination gets translated and forwarded to outside DNS server.( I
> have to translate the destination as well because the clients on
> internal network send a request to an internal DNS server with the
> internal IP address as destination. So the request gets forwarded to the
> outside world through the NAT and both SNAT-ed and DNAT-ed.) When the
> answer comes back to NAT, the outside source and destination IP gets
> translated back to the internal addresses, but the actual IP that
> resolves the requested page is embedded in the message, and it does not
> get translated ( it is outside IP) When the client gets the answer, it
> processes it, gets the outside IP from the message and try talk to it.
> But this is outside IP and inside clients can't route to it.
> 
> I am trying to understand how is this supposed to work. I can't quite
> use the wisdom from masquerade because masquerade is simpler, masquerade
> messages are only SNAT-ed, meaning only source address is translated and
> when the request comes back it is then DNAT-ed to internal network,
> meaning destination is translated so the message can find your machine.
> But you don't care that google.com resolved as 216.239.39.99 because
> your NAT is one way NAT in you can talk to 216.239.39.99. In my case, I
> have to translate the 216.239.39.99 to something else (for example
> 10.1.1.1) so that the inside network can talk to it. And then on the
> exit through the nat 10.1.1.1 will be translated back to 216.239.39.99.
> The problem is I have no way of translating the 216.239.39.99 to
> 10.1.1.1 because iptables NAT does not inspect the payload of the DNS
> answer and does not translate it. ... and this is how iptables is
> supposed to work.

If I understand everything correctly, your problem is something alike
"How can my clients find google.com ? My clients have non-routable
addresses (RFC1918), so they cannot talk to routable addresses". Your
szenario: Client starts DNS request for google.com to internal DNS. This
box returns 216.239.39.99 to the client and the client doesn't know how
to get there. Right ?

Hmm, your client already knows how to get to 216.239.39.99, because he
has a default route to the nat box (as you said above). The nat box
recieves something like

src=10.0.0.1 dst=216.239.39.99 spt=22222 dpt=80

This is not local to the nat box, so - if /proc/sys/net/ipv4/ip_forward
is set to 1 - the nat box will forward the packet to its default
gateway, say via ppp0. If you applied MASQUERADE to ppp0, the source
address is rewritten to the (internet) address of ppp0 and the packet
reaches google.

The return package from google hits your nat box and the connection
tracking code automatically "retranslates" (this time the destination
address) to 10.0.0.1 and the package reaches your client. That's all. A
rule like

iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

and everything is as described.

As /dev/rob0 pointed out, if you don't want your clients to talk with
google directly use proxies.

Sorry, if I missed the point.

Joerg

Re: DNS and NAT

[Suzana Lojic-Skoric]

>From: Jörg Harmuth <harmuth@mnemon.de>
>To: netfilter@lists.netfilter.org
>Subject: Re: DNS and NAT
>Date: Thu, 14 Jul 2005 15:29:37 +0200
>
>Suzana Lojic-Skoric schrieb:
>
> > I have an internal network that has one set of addresses and outside
> > network that has
> > a different set of addresses. I am using NAT for the sole purpose of
> > translation. Both inside and outside network have DNS servers, mail
> > servers,.... Both networks need to talk to each other, send mail and
> > request web pages... I have a control of inside network but not the
> > outside ntw.
> >
> > When the client from outside sends a DNS query to the inside ntw I guess
> > I can implement split DNS as Jason Opperisano suggested and get it
> > working that way. The outside world will get a web page from external
> > view and will have answer from global outside address, the inside world
> > will get answer from internal view with inside global ip.
> >
> > The problem is I don't understand how it is supposed to work when the
> > client is inside and sending a request for a page whose server happens
> > to be outside...
> > I have a default route through the NAT, so when a client on the inside
> > network
> > sends a DNS query it goes out through the NAT, in my case both source
> > and destination gets translated and forwarded to outside DNS server.( I
> > have to translate the destination as well because the clients on
> > internal network send a request to an internal DNS server with the
> > internal IP address as destination. So the request gets forwarded to the
> > outside world through the NAT and both SNAT-ed and DNAT-ed.) When the
> > answer comes back to NAT, the outside source and destination IP gets
> > translated back to the internal addresses, but the actual IP that
> > resolves the requested page is embedded in the message, and it does not
> > get translated ( it is outside IP) When the client gets the answer, it
> > processes it, gets the outside IP from the message and try talk to it.
> > But this is outside IP and inside clients can't route to it.
> >
> > I am trying to understand how is this supposed to work. I can't quite
> > use the wisdom from masquerade because masquerade is simpler, masquerade
> > messages are only SNAT-ed, meaning only source address is translated and
> > when the request comes back it is then DNAT-ed to internal network,
> > meaning destination is translated so the message can find your machine.
> > But you don't care that google.com resolved as 216.239.39.99 because
> > your NAT is one way NAT in you can talk to 216.239.39.99. In my case, I
> > have to translate the 216.239.39.99 to something else (for example
> > 10.1.1.1) so that the inside network can talk to it. And then on the
> > exit through the nat 10.1.1.1 will be translated back to 216.239.39.99.
> > The problem is I have no way of translating the 216.239.39.99 to
> > 10.1.1.1 because iptables NAT does not inspect the payload of the DNS
> > answer and does not translate it. ... and this is how iptables is
> > supposed to work.
>
>If I understand everything correctly, your problem is something alike
>"How can my clients find google.com ? My clients have non-routable
>addresses (RFC1918), so they cannot talk to routable addresses". Your
>szenario: Client starts DNS request for google.com to internal DNS. This
>box returns 216.239.39.99 to the client and the client doesn't know how
>to get there. Right ?
>
>Hmm, your client already knows how to get to 216.239.39.99, because he
>has a default route to the nat box (as you said above). The nat box
>recieves something like
>
>src=10.0.0.1 dst=216.239.39.99 spt=22222 dpt=80
>
>This is not local to the nat box, so - if /proc/sys/net/ipv4/ip_forward
>is set to 1 - the nat box will forward the packet to its default
>gateway, say via ppp0. If you applied MASQUERADE to ppp0, the source
>address is rewritten to the (internet) address of ppp0 and the packet
>reaches google.
>
>The return package from google hits your nat box and the connection
>tracking code automatically "retranslates" (this time the destination
>address) to 10.0.0.1 and the package reaches your client. That's all. A
>rule like
>
>iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
>
>and everything is as described.
>
Yes, you are right, but the problem is between my inside client and the NAT 
gateway I have a machine that drops everything that is not 10.x.x.x. I know, 
I know, it is insane... but my job is to find a solution for DNS in such 
network.

So basically, my inside network can only route 10.x.x.x and everything else 
is dropped.

>As /dev/rob0 pointed out, if you don't want your clients to talk with
>google directly use proxies.
>

I'll check out the proxy idea. Thanks for your input.

Suzana

>Sorry, if I missed the point.
>
>Joerg
>
>
>

_________________________________________________________________
Powerful Parental Controls Let your child discover the best the Internet has 
to offer. 
http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines 
  Start enjoying all the benefits of MSN® Premium right now and get the 
first two months FREE*.

Re: DNS and NAT

[primero]

Suzana Lojic-Skoric wrote:

>> iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
>>
>> and everything is as described.
>>
> Yes, you are right, but the problem is between my inside client and 
> the NAT gateway I have a machine that drops everything that is not 
> 10.x.x.x. I know, I know, it is insane... but my job is to find a 
> solution for DNS in such network.
>
> So basically, my inside network can only route 10.x.x.x and everything 
> else is dropped.
>
>> As /dev/rob0 pointed out, if you don't want your clients to talk with
>> google directly use proxies.
>>
>
> I'll check out the proxy idea. Thanks for your input.
>
> Suzana
>
You could use a Proxy but this would not solve your problem of 'have a 
machine that drops everything that is not 10.x.x.x' ... even with a 
proxy you would need that at least that machine would be able to access 
Public Big Internet.

Maybe i missed the point ... but if you can not access anything else 
then 10.x.x.x because something beetween clients and DefaultGW would 
drop it i don't see any escape other then configuring the proxy on your 
NAT Device because it should have not problem accessing the Public Internet.

Bye
Francesco

Re: DNS and NAT

[Suzana Lojic-Skoric]

>From: primero <primero@fastwebnet.it>
>To: Suzana Lojic-Skoric <s_lojic@hotmail.com>
>CC: harmuth@mnemon.de, netfilter@lists.netfilter.org
>Subject: Re: DNS and NAT
>Date: Thu, 14 Jul 2005 18:00:59 +0200
>
>Suzana Lojic-Skoric wrote:
>
>>>iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
>>>
>>>and everything is as described.
>>>
>>Yes, you are right, but the problem is between my inside client and the 
>>NAT gateway I have a machine that drops everything that is not 10.x.x.x. I 
>>know, I know, it is insane... but my job is to find a solution for DNS in 
>>such network.
>>
>>So basically, my inside network can only route 10.x.x.x and everything 
>>else is dropped.
>>
>>>As /dev/rob0 pointed out, if you don't want your clients to talk with
>>>google directly use proxies.
>>>
>>
>>I'll check out the proxy idea. Thanks for your input.
>>
>>Suzana
>>
>You could use a Proxy but this would not solve your problem of 'have a 
>machine that drops everything that is not 10.x.x.x' ... even with a proxy 
>you would need that at least that machine would be able to access Public 
>Big Internet.
>
>Maybe i missed the point ... but if you can not access anything else then 
>10.x.x.x because something beetween clients and DefaultGW would drop it i 
>don't see any escape other then configuring the proxy on your NAT Device 
>because it should have not problem accessing the Public Internet.
>
>Bye
>Francesco

I don't think proxy can help because it is just caching the web pages, it 
does not change the IP addresses. I'll check if tunneling can help, if not 
then I'll have to change iptables to inspect DNS answer and replace the IP 
in the payload.

Thanks for help,
Suzana

_________________________________________________________________
Take advantage of powerful junk e-mail filters built on patented Microsoft® 
SmartScreen Technology. 
http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines 
  Start enjoying all the benefits of MSN® Premium right now and get the 
first two months FREE*.

Re: DNS and NAT

[Jörg Harmuth]

Suzana Lojic-Skoric schrieb:

> I don't think proxy can help because it is just caching the web pages,
> it does not change the IP addresses. I'll check if tunneling can help,
> if not then I'll have to change iptables to inspect DNS answer and
> replace the IP in the payload.

No. Introducing a proxy at the right location, is much more than just
caching web sites. It means significant changes to at least to the IP
headers.

Wether a proxy helps you or not depends totally on where you place the
proxy. If you place it on the nat box (like primero said) or between
this nasty dropping box and the nat box, everything is probably fine.
The requests will then go to 10.x.x.x and the answers will originate
from 10.x.x.x. The e.g. google address of 216.239.39.99 is within the
*data* part of the 4th packet - not in the headers (headers are
src=10.y.y.y dst=10.x.x.x). As long as the nasty dropping box doesn't
scan the packets payload for proxy requests and the like and drops them,
everything should work.

If, on the other side, it is only possible to place the proxy between
the clients and this nasty dropping box, you're out of luck and a proxy
helps nothing at all. But as far as I understood - and you provided
information - you have access to the nat box. So, this should not be the
case.

BTW, would you please be so kind and provide sufficient information
about your problem in the first posting (introducing this nasty box
changes the whole situation) ? This way people who want to help you do
not have to feel like the "Oracle of Delphi" ;) Thanks.

Have a nice time,

Joerg

Re: DNS and NAT

[Suzana Lojic-Skoric]

>From: Jörg Harmuth <harmuth@mnemon.de>
>To: netfilter@lists.netfilter.org
>Subject: Re: DNS and NAT
>Date: Fri, 15 Jul 2005 10:53:17 +0200
>
>Suzana Lojic-Skoric schrieb:
>
> > I don't think proxy can help because it is just caching the web pages,
> > it does not change the IP addresses. I'll check if tunneling can help,
> > if not then I'll have to change iptables to inspect DNS answer and
> > replace the IP in the payload.
>
>No. Introducing a proxy at the right location, is much more than just
>caching web sites. It means significant changes to at least to the IP
>headers.
>
>Wether a proxy helps you or not depends totally on where you place the
>proxy. If you place it on the nat box (like primero said) or between
>this nasty dropping box and the nat box, everything is probably fine.
>The requests will then go to 10.x.x.x and the answers will originate
>from 10.x.x.x. The e.g. google address of 216.239.39.99 is within the
>*data* part of the 4th packet - not in the headers (headers are
>src=10.y.y.y dst=10.x.x.x). As long as the nasty dropping box doesn't
>scan the packets payload for proxy requests and the like and drops them,
>everything should work.

I can put the proxy on the NAT machine.
As I said, right now just with the NAT, if I send a DNS request for the 
google.com from the client 10.0.0.1 behind the nasty dropping box, it will 
go out through the nasty dropping box and the NAT gateway. NAT will change 
its 10.x.x.x source and destination from 10.x.x.x to some outside addresses 
e.g. 150.x.x.x. The DNS answer comes back to NAT, it's source and 
destination gets translated back to 10.x.x.x and 10.0.0.1 destination, and 
the google address 216.239.39.99 is within the *data* part. This goes fine 
through the nasty dropping box back to the client 10.0.0.1. Client then 
takes the answer from the data part of the message, which is 216.239.39.99 
and tries to contact it. It sends an HTTP message to destination 
216.239.39.99. This gets dropped on the nasty dropping box since it is not 
10.x.x.x (This is what's happening when you type in www.google.com in the 
browser on the client 10.0.0.1).
So the DNS request and answer can get through the internal network, but what 
I need is to somehow replace the 216.239.39.99 that is embedded in the DNS 
*data* with 10.z.z.z. Also my NAT needs to know that 10.z.z.z is actually 
216.239.39.99. to be able to translate it for outside.

Do you still think proxy can help?
>
>If, on the other side, it is only possible to place the proxy between
>the clients and this nasty dropping box, you're out of luck and a proxy
>helps nothing at all. But as far as I understood - and you provided
>information - you have access to the nat box. So, this should not be the
>case.
>
>BTW, would you please be so kind and provide sufficient information
>about your problem in the first posting (introducing this nasty box
>changes the whole situation) ? This way people who want to help you do
>not have to feel like the "Oracle of Delphi" ;) Thanks.

I'll do it next time :) I was afraid it would be too long for anybody to 
read it. Thanks for your help.

Suzana

>
>Have a nice time,
>
>Joerg
>
>

_________________________________________________________________
Take advantage of powerful junk e-mail filters built on patented Microsoft® 
SmartScreen Technology. 
http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines 
  Start enjoying all the benefits of MSN® Premium right now and get the 
first two months FREE*.

Re: DNS and NAT

[R. DuFresne]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 4849 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Has anyone checked to see if beside pre/post routing rules this person has 
added the ip add majik to make NAT more seamless, I'm of course assuming a 
1:1 NAT setup for a network rahter than masq.  And if they are using masq, 
perhaps a 1:1 NAT setup would quell their troubles so that it's IP based 
NAT rather then port based PNAT that is working against em...?

Thanks,

Ron DuFresne


On Fri, 15 Jul 2005, Suzana Lojic-Skoric wrote:

>
>
>> From: Jörg Harmuth <harmuth@mnemon.de>
>> To: netfilter@lists.netfilter.org
>> Subject: Re: DNS and NAT
>> Date: Fri, 15 Jul 2005 10:53:17 +0200
>> 
>> Suzana Lojic-Skoric schrieb:
>> 
>> > I don't think proxy can help because it is just caching the web pages,
>> > it does not change the IP addresses. I'll check if tunneling can help,
>> > if not then I'll have to change iptables to inspect DNS answer and
>> > replace the IP in the payload.
>> 
>> No. Introducing a proxy at the right location, is much more than just
>> caching web sites. It means significant changes to at least to the IP
>> headers.
>> 
>> Wether a proxy helps you or not depends totally on where you place the
>> proxy. If you place it on the nat box (like primero said) or between
>> this nasty dropping box and the nat box, everything is probably fine.
>> The requests will then go to 10.x.x.x and the answers will originate
>> from 10.x.x.x. The e.g. google address of 216.239.39.99 is within the
>> *data* part of the 4th packet - not in the headers (headers are
>> src=10.y.y.y dst=10.x.x.x). As long as the nasty dropping box doesn't
>> scan the packets payload for proxy requests and the like and drops them,
>> everything should work.
>
> I can put the proxy on the NAT machine.
> As I said, right now just with the NAT, if I send a DNS request for the 
> google.com from the client 10.0.0.1 behind the nasty dropping box, it will go 
> out through the nasty dropping box and the NAT gateway. NAT will change its 
> 10.x.x.x source and destination from 10.x.x.x to some outside addresses e.g. 
> 150.x.x.x. The DNS answer comes back to NAT, it's source and destination gets 
> translated back to 10.x.x.x and 10.0.0.1 destination, and the google address 
> 216.239.39.99 is within the *data* part. This goes fine through the nasty 
> dropping box back to the client 10.0.0.1. Client then takes the answer from 
> the data part of the message, which is 216.239.39.99 and tries to contact it. 
> It sends an HTTP message to destination 216.239.39.99. This gets dropped on 
> the nasty dropping box since it is not 10.x.x.x (This is what's happening 
> when you type in www.google.com in the browser on the client 10.0.0.1).
> So the DNS request and answer can get through the internal network, but what 
> I need is to somehow replace the 216.239.39.99 that is embedded in the DNS 
> *data* with 10.z.z.z. Also my NAT needs to know that 10.z.z.z is actually 
> 216.239.39.99. to be able to translate it for outside.
>
> Do you still think proxy can help?
>> 
>> If, on the other side, it is only possible to place the proxy between
>> the clients and this nasty dropping box, you're out of luck and a proxy
>> helps nothing at all. But as far as I understood - and you provided
>> information - you have access to the nat box. So, this should not be the
>> case.
>> 
>> BTW, would you please be so kind and provide sufficient information
>> about your problem in the first posting (introducing this nasty box
>> changes the whole situation) ? This way people who want to help you do
>> not have to feel like the "Oracle of Delphi" ;) Thanks.
>
> I'll do it next time :) I was afraid it would be too long for anybody to read 
> it. Thanks for your help.
>
> Suzana
>
>> 
>> Have a nice time,
>> 
>> Joerg
>> 
>> 
>
> _________________________________________________________________
> Take advantage of powerful junk e-mail filters built on patented Microsoft® 
> SmartScreen Technology. 
> http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines 
> Start enjoying all the benefits of MSN® Premium right now and get the first 
> two months FREE*.
>
>

- -- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         admin & senior security consultant:  sysinfo.com
                         http://sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A  E838 B2DF AFCC 94B0 6629

...We waste time looking for the perfect lover
instead of creating the perfect love.

                 -Tom Robbins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFC1+gast+vzJSwZikRAoIFAKCcx6voNEBSZNMlpZjTJIftXWUplwCcCV4K
ETadeRA1YWhhsaNAASuZCsk=
=PbUZ
-----END PGP SIGNATURE-----

Re: DNS and NAT

[Suzana Lojic-Skoric]

>From: "R. DuFresne" <dufresne@sysinfo.com>
>To: Suzana Lojic-Skoric <s_lojic@hotmail.com>
>CC: harmuth@mnemon.de, netfilter@lists.netfilter.org
>Subject: Re: DNS and NAT
>Date: Fri, 15 Jul 2005 12:45:10 -0400 (EDT)
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>
>Has anyone checked to see if beside pre/post routing rules this person has 
>added the ip add majik to make NAT more seamless, I'm of course assuming a 
>1:1 NAT setup for a network rahter than masq.  And if they are using masq, 
>perhaps a 1:1 NAT setup would quell their troubles so that it's IP based 
>NAT rather then port based PNAT that is working against em...?
>
I have implemented PNAT on inbound direction, means incoming traffic (from 
outside to the NAT box) is port forwarded to appropriate servers inside. Why 
would PNAT work against me?

Thanks,

Suzana

>Thanks,
>
>Ron DuFresne
>
>
>On Fri, 15 Jul 2005, Suzana Lojic-Skoric wrote:
>
>>
>>
>>>From: Jörg Harmuth <harmuth@mnemon.de>
>>>To: netfilter@lists.netfilter.org
>>>Subject: Re: DNS and NAT
>>>Date: Fri, 15 Jul 2005 10:53:17 +0200
>>>
>>>Suzana Lojic-Skoric schrieb:
>>>
>>> > I don't think proxy can help because it is just caching the web pages,
>>> > it does not change the IP addresses. I'll check if tunneling can help,
>>> > if not then I'll have to change iptables to inspect DNS answer and
>>> > replace the IP in the payload.
>>>
>>>No. Introducing a proxy at the right location, is much more than just
>>>caching web sites. It means significant changes to at least to the IP
>>>headers.
>>>
>>>Wether a proxy helps you or not depends totally on where you place the
>>>proxy. If you place it on the nat box (like primero said) or between
>>>this nasty dropping box and the nat box, everything is probably fine.
>>>The requests will then go to 10.x.x.x and the answers will originate
>>>from 10.x.x.x. The e.g. google address of 216.239.39.99 is within the
>>>*data* part of the 4th packet - not in the headers (headers are
>>>src=10.y.y.y dst=10.x.x.x). As long as the nasty dropping box doesn't
>>>scan the packets payload for proxy requests and the like and drops them,
>>>everything should work.
>>
>>I can put the proxy on the NAT machine.
>>As I said, right now just with the NAT, if I send a DNS request for the 
>>google.com from the client 10.0.0.1 behind the nasty dropping box, it will 
>>go out through the nasty dropping box and the NAT gateway. NAT will change 
>>its 10.x.x.x source and destination from 10.x.x.x to some outside 
>>addresses e.g. 150.x.x.x. The DNS answer comes back to NAT, it's source 
>>and destination gets translated back to 10.x.x.x and 10.0.0.1 destination, 
>>and the google address 216.239.39.99 is within the *data* part. This goes 
>>fine through the nasty dropping box back to the client 10.0.0.1. Client 
>>then takes the answer from the data part of the message, which is 
>>216.239.39.99 and tries to contact it. It sends an HTTP message to 
>>destination 216.239.39.99. This gets dropped on the nasty dropping box 
>>since it is not 10.x.x.x (This is what's happening when you type in 
>>www.google.com in the browser on the client 10.0.0.1).
>>So the DNS request and answer can get through the internal network, but 
>>what I need is to somehow replace the 216.239.39.99 that is embedded in 
>>the DNS *data* with 10.z.z.z. Also my NAT needs to know that 10.z.z.z is 
>>actually 216.239.39.99. to be able to translate it for outside.
>>
>>Do you still think proxy can help?
>>>
>>>If, on the other side, it is only possible to place the proxy between
>>>the clients and this nasty dropping box, you're out of luck and a proxy
>>>helps nothing at all. But as far as I understood - and you provided
>>>information - you have access to the nat box. So, this should not be the
>>>case.
>>>
>>>BTW, would you please be so kind and provide sufficient information
>>>about your problem in the first posting (introducing this nasty box
>>>changes the whole situation) ? This way people who want to help you do
>>>not have to feel like the "Oracle of Delphi" ;) Thanks.
>>
>>I'll do it next time :) I was afraid it would be too long for anybody to 
>>read it. Thanks for your help.
>>
>>Suzana
>>
>>>
>>>Have a nice time,
>>>
>>>Joerg
>>>
>>>
>>
>>_________________________________________________________________
>>Take advantage of powerful junk e-mail filters built on patented 
>>Microsoft® SmartScreen Technology. 
>>http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines 
>>Start enjoying all the benefits of MSN® Premium right now and get the 
>>first two months FREE*.
>>
>>
>
>- -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>         admin & senior security consultant:  sysinfo.com
>                         http://sysinfo.com
>Key fingerprint = 9401 4B13 B918 164C 647A  E838 B2DF AFCC 94B0 6629
>
>...We waste time looking for the perfect lover
>instead of creating the perfect love.
>
>                 -Tom Robbins <Still Life With Woodpecker>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.4 (GNU/Linux)
>
>iD8DBQFC1+gast+vzJSwZikRAoIFAKCcx6voNEBSZNMlpZjTJIftXWUplwCcCV4K
>ETadeRA1YWhhsaNAASuZCsk=
>=PbUZ
>-----END PGP SIGNATURE-----

_________________________________________________________________
Take advantage of powerful junk e-mail filters built on patented Microsoft® 
SmartScreen Technology. 
http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines 
  Start enjoying all the benefits of MSN® Premium right now and get the 
first two months FREE*.

Re: DNS and NAT

[Francesco Ciocchetti]

Suzana Lojic-Skoric wrote:

>
>
>> From: Jörg Harmuth <harmuth@mnemon.de>
>> To: netfilter@lists.netfilter.org
>> Subject: Re: DNS and NAT
>> Date: Fri, 15 Jul 2005 10:53:17 +0200
>>
>> Suzana Lojic-Skoric schrieb:
>>
>> > I don't think proxy can help because it is just caching the web pages,
>> > it does not change the IP addresses. I'll check if tunneling can help,
>> > if not then I'll have to change iptables to inspect DNS answer and
>> > replace the IP in the payload.
>>
>> No. Introducing a proxy at the right location, is much more than just
>> caching web sites. It means significant changes to at least to the IP
>> headers.
>>
>> Wether a proxy helps you or not depends totally on where you place the
>> proxy. If you place it on the nat box (like primero said) or between
>> this nasty dropping box and the nat box, everything is probably fine.
>> The requests will then go to 10.x.x.x and the answers will originate
>> from 10.x.x.x. The e.g. google address of 216.239.39.99 is within the
>> *data* part of the 4th packet - not in the headers (headers are
>> src=10.y.y.y dst=10.x.x.x). As long as the nasty dropping box doesn't
>> scan the packets payload for proxy requests and the like and drops them,
>> everything should work.
>
>
> I can put the proxy on the NAT machine.
> As I said, right now just with the NAT, if I send a DNS request for 
> the google.com from the client 10.0.0.1 behind the nasty dropping box, 
> it will go out through the nasty dropping box and the NAT gateway. NAT 
> will change its 10.x.x.x source and destination from 10.x.x.x to some 
> outside addresses e.g. 150.x.x.x. The DNS answer comes back to NAT, 
> it's source and destination gets translated back to 10.x.x.x and 
> 10.0.0.1 destination, and the google address 216.239.39.99 is within 
> the *data* part. This goes fine through the nasty dropping box back to 
> the client 10.0.0.1. Client then takes the answer from the data part 
> of the message, which is 216.239.39.99 and tries to contact it. It 
> sends an HTTP message to destination 216.239.39.99. This gets dropped 
> on the nasty dropping box since it is not 10.x.x.x (This is what's 
> happening when you type in www.google.com in the browser on the client 
> 10.0.0.1).
> So the DNS request and answer can get through the internal network, 
> but what I need is to somehow replace the 216.239.39.99 that is 
> embedded in the DNS *data* with 10.z.z.z. Also my NAT needs to know 
> that 10.z.z.z is actually 216.239.39.99. to be able to translate it 
> for outside.
>
> Do you still think proxy can help?
>
with a *standard proxy* configured on the browser of client 10.0.0.1 
your request for 216.239.39.99 will be in the payload of the proxy 
request that has the IP address of your proxy machine in the destination 
address field of the network layer ... it should be good for your nasty 
dropping box.
 From there the HTTP request will be managed from your proxy wich will 
answer to your client with a connection completely inside the 10.x.x.x 
network.


bye
<f>

Re: DNS and NAT

[Suzana Lojic-Skoric]

Thank you,

Suzana

>From: Francesco Ciocchetti <primero@fastwebnet.it>
>To: netfilter@lists.netfilter.org
>Subject: Re: DNS and NAT
>Date: Fri, 15 Jul 2005 20:52:18 +0200
>
>Suzana Lojic-Skoric wrote:
>
>>
>>
>>>From: Jörg Harmuth <harmuth@mnemon.de>
>>>To: netfilter@lists.netfilter.org
>>>Subject: Re: DNS and NAT
>>>Date: Fri, 15 Jul 2005 10:53:17 +0200
>>>
>>>Suzana Lojic-Skoric schrieb:
>>>
>>> > I don't think proxy can help because it is just caching the web pages,
>>> > it does not change the IP addresses. I'll check if tunneling can help,
>>> > if not then I'll have to change iptables to inspect DNS answer and
>>> > replace the IP in the payload.
>>>
>>>No. Introducing a proxy at the right location, is much more than just
>>>caching web sites. It means significant changes to at least to the IP
>>>headers.
>>>
>>>Wether a proxy helps you or not depends totally on where you place the
>>>proxy. If you place it on the nat box (like primero said) or between
>>>this nasty dropping box and the nat box, everything is probably fine.
>>>The requests will then go to 10.x.x.x and the answers will originate
>>>from 10.x.x.x. The e.g. google address of 216.239.39.99 is within the
>>>*data* part of the 4th packet - not in the headers (headers are
>>>src=10.y.y.y dst=10.x.x.x). As long as the nasty dropping box doesn't
>>>scan the packets payload for proxy requests and the like and drops them,
>>>everything should work.
>>
>>
>>I can put the proxy on the NAT machine.
>>As I said, right now just with the NAT, if I send a DNS request for the 
>>google.com from the client 10.0.0.1 behind the nasty dropping box, it will 
>>go out through the nasty dropping box and the NAT gateway. NAT will change 
>>its 10.x.x.x source and destination from 10.x.x.x to some outside 
>>addresses e.g. 150.x.x.x. The DNS answer comes back to NAT, it's source 
>>and destination gets translated back to 10.x.x.x and 10.0.0.1 destination, 
>>and the google address 216.239.39.99 is within the *data* part. This goes 
>>fine through the nasty dropping box back to the client 10.0.0.1. Client 
>>then takes the answer from the data part of the message, which is 
>>216.239.39.99 and tries to contact it. It sends an HTTP message to 
>>destination 216.239.39.99. This gets dropped on the nasty dropping box 
>>since it is not 10.x.x.x (This is what's happening when you type in 
>>www.google.com in the browser on the client 10.0.0.1).
>>So the DNS request and answer can get through the internal network, but 
>>what I need is to somehow replace the 216.239.39.99 that is embedded in 
>>the DNS *data* with 10.z.z.z. Also my NAT needs to know that 10.z.z.z is 
>>actually 216.239.39.99. to be able to translate it for outside.
>>
>>Do you still think proxy can help?
>>
>with a *standard proxy* configured on the browser of client 10.0.0.1 your 
>request for 216.239.39.99 will be in the payload of the proxy request that 
>has the IP address of your proxy machine in the destination address field 
>of the network layer ... it should be good for your nasty dropping box.
From there the HTTP request will be managed from your proxy wich will 
>answer to your client with a connection completely inside the 10.x.x.x 
>network.
>
>
>bye
><f>
>

_________________________________________________________________
Take advantage of powerful junk e-mail filters built on patented Microsoft® 
SmartScreen Technology. 
http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines 
  Start enjoying all the benefits of MSN® Premium right now and get the 
first two months FREE*.

Re: DNS and NAT

[Suzana Lojic-Skoric]

>From: Francesco Ciocchetti <primero@fastwebnet.it>
>To: netfilter@lists.netfilter.org
>Subject: Re: DNS and NAT
>Date: Fri, 15 Jul 2005 20:52:18 +0200
>
>Suzana Lojic-Skoric wrote:
>
>>
>>
>>>From: Jörg Harmuth <harmuth@mnemon.de>
>>>To: netfilter@lists.netfilter.org
>>>Subject: Re: DNS and NAT
>>>Date: Fri, 15 Jul 2005 10:53:17 +0200
>>>
>>>Suzana Lojic-Skoric schrieb:
>>>
>>> > I don't think proxy can help because it is just caching the web pages,
>>> > it does not change the IP addresses. I'll check if tunneling can help,
>>> > if not then I'll have to change iptables to inspect DNS answer and
>>> > replace the IP in the payload.
>>>
>>>No. Introducing a proxy at the right location, is much more than just
>>>caching web sites. It means significant changes to at least to the IP
>>>headers.
>>>
>>>Wether a proxy helps you or not depends totally on where you place the
>>>proxy. If you place it on the nat box (like primero said) or between
>>>this nasty dropping box and the nat box, everything is probably fine.
>>>The requests will then go to 10.x.x.x and the answers will originate
>>>from 10.x.x.x. The e.g. google address of 216.239.39.99 is within the
>>>*data* part of the 4th packet - not in the headers (headers are
>>>src=10.y.y.y dst=10.x.x.x). As long as the nasty dropping box doesn't
>>>scan the packets payload for proxy requests and the like and drops them,
>>>everything should work.
>>
>>
>>I can put the proxy on the NAT machine.
>>As I said, right now just with the NAT, if I send a DNS request for the 
>>google.com from the client 10.0.0.1 behind the nasty dropping box, it will 
>>go out through the nasty dropping box and the NAT gateway. NAT will change 
>>its 10.x.x.x source and destination from 10.x.x.x to some outside 
>>addresses e.g. 150.x.x.x. The DNS answer comes back to NAT, it's source 
>>and destination gets translated back to 10.x.x.x and 10.0.0.1 destination, 
>>and the google address 216.239.39.99 is within the *data* part. This goes 
>>fine through the nasty dropping box back to the client 10.0.0.1. Client 
>>then takes the answer from the data part of the message, which is 
>>216.239.39.99 and tries to contact it. It sends an HTTP message to 
>>destination 216.239.39.99. This gets dropped on the nasty dropping box 
>>since it is not 10.x.x.x (This is what's happening when you type in 
>>www.google.com in the browser on the client 10.0.0.1).
>>So the DNS request and answer can get through the internal network, but 
>>what I need is to somehow replace the 216.239.39.99 that is embedded in 
>>the DNS *data* with 10.z.z.z. Also my NAT needs to know that 10.z.z.z is 
>>actually 216.239.39.99. to be able to translate it for outside.
>>
>>Do you still think proxy can help?
>>
>with a *standard proxy* configured on the browser of client 10.0.0.1 your 
>request for 216.239.39.99 will be in the payload of the proxy request that 
>has the IP address of your proxy machine in the destination address field 
>of the network layer ... it should be good for your nasty dropping box.
From there the HTTP request will be managed from your proxy wich will 
>answer to your client with a connection completely inside the 10.x.x.x 
>network.
>
>
>bye
><f>

Do you know if split DNS installed on the NAT gateway would do the trick 
too?

Thanks,
Suzana


>

_________________________________________________________________
Take charge with a pop-up guard built on patented Microsoft® SmartScreen 
Technology. 
http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines 
  Start enjoying all the benefits of MSN® Premium right now and get the 
first two months FREE*.