RE: dnatting

RE: dnatting

[Gary W. Smith]

Payal, 

You need to add a second simple entry:

Look at the entries below.  I'm mapping an entire IP but this would be
simple to just to a single port.  The second POSTROUTING line is what
made everything work for my typical firewalls.

# Completed on Mon Jul 11 10:58:27 2005
# Generated by iptables-save v1.2.11 on Mon Jul 11 10:58:27 2005
*nat
:PREROUTING ACCEPT [2547:176804]
:POSTROUTING ACCEPT [633:40896]
:OUTPUT ACCEPT [40:4518]
-A PREROUTING -d 81.45.25.50 -j DNAT --to-destination 10.94.16.50 

-A POSTROUTING -s 10.94.16.50 -o eth0 -j SNAT --to-source 81.45.25.50 
-A POSTROUTING -s 10.94.16.50 -d 10.94.16.0/255.255.255.0 -j SNAT
--to-source 81.45.25.50 

-A POSTROUTING -o eth0 -p ! ipv6-crypt -j SNAT --to-source 81.45.25.50
-A OUTPUT -d 81.45.25.50 -j DNAT --to-destination 10.94.16.50 
COMMIT
# Completed on Mon Jul 11 10:58:27 2005


> -----Original Message-----
> From: netfilter-bounces@lists.netfilter.org [mailto:netfilter-
> bounces@lists.netfilter.org] On Behalf Of Payal Rathod
> Sent: Monday, July 11, 2005 8:19 AM
> To: Netfilter ML
> Subject: dnatting
> 
> Hi,
> I have a rule on my friend's broadband connection to redirect traffic
> from outside to an internal machine like,
> 
> iptables -A PREROUTING -d 1.2.3.4 -p tcp -m tcp --dport 80 -j DNAT  \
> --to-destination 192.168.10.10:80
> 
> But she complained that people from inside the network cannot do
> http://1.2.3.4 in their browser and see the site. Is she correct?
> What is wrong with my rule because I can see the site from outside?
> 
> Thanks in advance.
> With warm regards,
> -Payal
> 
> 

Re: dnatting

[Payal Rathod]

On Mon, Jul 11, 2005 at 12:09:44PM -0700, Gary W. Smith wrote:
> Payal, 
> 
> You need to add a second simple entry:
[...]

Thanks this solved it. Thanks again.
Now I am curious why Jason didn't suggest this.

With warm regards,
-Payal

> 
> Look at the entries below.  I'm mapping an entire IP but this would be
> simple to just to a single port.  The second POSTROUTING line is what
> made everything work for my typical firewalls.
> 
> # Completed on Mon Jul 11 10:58:27 2005
> # Generated by iptables-save v1.2.11 on Mon Jul 11 10:58:27 2005
> *nat
> :PREROUTING ACCEPT [2547:176804]
> :POSTROUTING ACCEPT [633:40896]
> :OUTPUT ACCEPT [40:4518]
> -A PREROUTING -d 81.45.25.50 -j DNAT --to-destination 10.94.16.50 
> 
> -A POSTROUTING -s 10.94.16.50 -o eth0 -j SNAT --to-source 81.45.25.50 
> -A POSTROUTING -s 10.94.16.50 -d 10.94.16.0/255.255.255.0 -j SNAT
> --to-source 81.45.25.50 
> 
> -A POSTROUTING -o eth0 -p ! ipv6-crypt -j SNAT --to-source 81.45.25.50
> -A OUTPUT -d 81.45.25.50 -j DNAT --to-destination 10.94.16.50 
> COMMIT
> # Completed on Mon Jul 11 10:58:27 2005
> 
> 
> > -----Original Message-----
> > From: netfilter-bounces@lists.netfilter.org [mailto:netfilter-
> > bounces@lists.netfilter.org] On Behalf Of Payal Rathod
> > Sent: Monday, July 11, 2005 8:19 AM
> > To: Netfilter ML
> > Subject: dnatting
> > 
> > Hi,
> > I have a rule on my friend's broadband connection to redirect traffic
> > from outside to an internal machine like,
> > 
> > iptables -A PREROUTING -d 1.2.3.4 -p tcp -m tcp --dport 80 -j DNAT  \
> > --to-destination 192.168.10.10:80
> > 
> > But she complained that people from inside the network cannot do
> > http://1.2.3.4 in their browser and see the site. Is she correct?
> > What is wrong with my rule because I can see the site from outside?
> > 
> > Thanks in advance.
> > With warm regards,
> > -Payal
> > 
> > 
> 

Re: dnatting

[Jason Opperisano]

On Tue, Jul 12, 2005 at 03:34:07AM -0400, Payal Rathod wrote:
> Thanks this solved it. Thanks again.
> Now I am curious why Jason didn't suggest this.

no need for curiosity--re-read the last sentence of my post.

-j

--
"Peter: At least they don't put their feminine ointments next to the
 mustard, Lois. That was the worst hot dog I ever ate."
        --Family Guy

Re: dnatting

[Payal Rathod]

On Tue, Jul 12, 2005 at 07:59:18AM -0400, Jason Opperisano wrote:
> On Tue, Jul 12, 2005 at 03:34:07AM -0400, Payal Rathod wrote:
> > Thanks this solved it. Thanks again.
> > Now I am curious why Jason didn't suggest this.
> 
> no need for curiosity--re-read the last sentence of my post.

I had already did that and was wondering why the solution posted is
not agreed upon by. Why do you call it half-baked?
Payal
> 
> -j
> 
> --
> "Peter: At least they don't put their feminine ointments next to the
>  mustard, Lois. That was the worst hot dog I ever ate."
>         --Family Guy
> 

Re: dnatting

[Steven M Campbell]

Payal Rathod wrote:
>On Tue, Jul 12, 2005 at 07:59:18AM -0400, Jason Opperisano wrote:
>  
>>On Tue, Jul 12, 2005 at 03:34:07AM -0400, Payal Rathod wrote:
>>    
>>>Thanks this solved it. Thanks again.
>>>Now I am curious why Jason didn't suggest this.
>>>      
>>no need for curiosity--re-read the last sentence of my post.
>>    
>
>I had already did that and was wondering why the solution posted is
>not agreed upon by. Why do you call it half-baked?
>Payal
>  

I'll jump in :)  What we have done here is natted the connections in 
both directions.  If you could imagine walking from your living room to 
your bedroom by going out the garage and coming back in the front door 
first you start to feel the sillyness of this datapath.  Here's a few 
issues this technique raises:

* Increased utilization of the firewall
The firewall has to handle all the traffic which would normally just be 
switched internally, this makes the connection slower for the user and 
may impact other users as it uses resources on the firewall.  This is 
also true of the network path in general, for instance:  Say you put a 
gigabit card into the server, if you firewall only has 100mb card then 
your server really cannot use the GB card to any capacity, in fact it is 
limited to whatever bandwidth is left on the firewall interface.   You 
spend good money on switches and network design, utilize them.

* Dependency on the firewall to reach local traffic
Turn off you firewall and your users can't reach this server!  
Maintenance becomes an issue.

* Masquerading of the source computer
If you have a problem with a user it will be more fun tracking it 
because the source IP address will now always appear to be the firewall 
and, if this is after the fact, the connection may be long gone from the 
connection table leaving you unable to trace the problem.  Also, you 
can't use and IP based permissions on the server as, again, everyone 
will appear to be from the firewall

* Increased firewall rule complexity
Everytime another server is added in this fashion you need to maintain 
firewall rules, add lots of servers and it becomes real messy really 
fast.  One of the keys to having a secure firewall is having clean 
rules, the more cruft that gets in there the more likely a mistake will 
be made creating a hole in your firewall system.


So, having put a few of these negative forth allow me to suggest an 
alternative.  Split DNS, with split dns you will create a name, for 
example theserver.myplace.com and have a split view of it, that is, 
folks on the inside will get the inside address and folks on the outside 
will get the outside address.  No special routing is then required and 
you can use the server internally without any of the above issues.   I 
totally agree with Jason in suggesting that you investigate your name 
server rather than doing this bi-directional NAT.

RE: dnatting

[Gary W. Smith]

I still don't agree with your statement.  For people who have single
IP's that need simple DNAT/SNAT'ing for the scenario provided (which was
a single port mapped) your process would be overkill and just as
cumbersome as adding an additional rule to iptables.

Gary

> -----Original Message-----
> From: netfilter-bounces@lists.netfilter.org [mailto:netfilter-
> bounces@lists.netfilter.org] On Behalf Of Steven M Campbell
> Sent: Wednesday, July 13, 2005 7:50 AM
> Cc: Netfilter ML
> Subject: Re: dnatting

> FWIW from me I would not accept the answer 'it works so it must be
> okay', that's been the downfall of soooo very many computer projects I
> cannot even begin to count them (a particularily bad attitude for
> programmers).    We'll certainly not argue (and we aren't), it's your
> network and your rules.  My advice is use split DNS from the
experience
> that I used to do the sort of thing that you are doing here and I
found
> out that it was a bad idea and only created trouble later and I don't
> like trouble, especially if it can be pinned on me!
> 

Re: dnatting

[Steven M Campbell]

Gary W. Smith wrote:
>I still don't agree with your statement.  For people who have single
>IP's that need simple DNAT/SNAT'ing for the scenario provided (which was
>a single port mapped) your process would be overkill and just as
>cumbersome as adding an additional rule to iptables.
>
>  
Okay, you have my advice, your network your rules.

RE: dnatting

[Gary W. Smith]

I agree with everything that has been said BUT I must also interject.  A
lot small business and many home users who get one or two IP's usually
don't have a second DNS floating around.  For larger organizations I
would definitely use the split DNS.  We do that at a couple locations
when we can.

As for this case, I think it's completely acceptable.  

Since this does indeed work I think it should be documented as a viable
solution (which I think it's in the fine print on one of the docs that I
read before).



> -----Original Message-----
> From: netfilter-bounces@lists.netfilter.org [mailto:netfilter-
> bounces@lists.netfilter.org] On Behalf Of Steven M Campbell
> Sent: Tuesday, July 12, 2005 2:03 PM
> To: Netfilter ML
> Subject: Re: dnatting
> 
> 
> So, having put a few of these negative forth allow me to suggest an
> alternative.  Split DNS, with split dns you will create a name, for
> example theserver.myplace.com and have a split view of it, that is,
> folks on the inside will get the inside address and folks on the
outside
> will get the outside address.  No special routing is then required and
> you can use the server internally without any of the above issues.   I
> totally agree with Jason in suggesting that you investigate your name
> server rather than doing this bi-directional NAT.
> 
> 

RE: dnatting

[Jan Engelhardt]

>I agree with everything that has been said BUT I must also interject.  A
>lot small business and many home users who get one or two IP's usually
>don't have a second DNS floating around.

It is required to have two [external] DNS servers.


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

RE: dnatting

[R. DuFresne]

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

On Wed, 13 Jul 2005, Jan Engelhardt wrote:

>
>> I agree with everything that has been said BUT I must also interject.  A
>> lot small business and many home users who get one or two IP's usually
>> don't have a second DNS floating around.
>
> It is required to have two [external] DNS servers.
>

Since when have requirements ever gotten in the way of *progress* or 
*production*? <gryn>

more like best practises, or recommendations, but, requirements?  on the 
internet?  One might have assumed there were requirements when the 
internet was closed and sightly controlled, but, not in the public openess 
of this day...


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)

iD4DBQFC1YVkst+vzJSwZikRAriTAKDViPU5Pbf7OVCzeTbTienNBIbawwCXbda7
U51eHzG9tnssqQptRxt+4w==
=G8vu
-----END PGP SIGNATURE-----

Re: dnatting

[Steven M Campbell]

Gary W. Smith wrote:
>I agree with everything that has been said BUT I must also interject.  A
>lot small business and many home users who get one or two IP's usually
>don't have a second DNS floating around.  For larger organizations I
>would definitely use the split DNS.  We do that at a couple locations
>when we can.
>  
Split DNS can be implemented on a single DNS server, check your DNS 
servers manual.  The basics are that you create views of your domain 
structure based on the ip address of the requester, if they are inside 
(for instance 10.0.0.0/8) you give them the inside answers, otherwise 
you give them the outside answers.   You should not need multiple DNS 
servers although you should have multiple servers for other reasons. 

>As for this case, I think it's completely acceptable.  
>
>Since this does indeed work I think it should be documented as a viable
>solution (which I think it's in the fine print on one of the docs that I
>read before).
>
>  
FWIW from me I would not accept the answer 'it works so it must be 
okay', that's been the downfall of soooo very many computer projects I 
cannot even begin to count them (a particularily bad attitude for 
programmers).    We'll certainly not argue (and we aren't), it's your 
network and your rules.  My advice is use split DNS from the experience 
that I used to do the sort of thing that you are doing here and I found 
out that it was a bad idea and only created trouble later and I don't 
like trouble, especially if it can be pinned on me!

Re: dnatting

[Donald Murray]

On 7/13/05, Steven M Campbell <Netfilter@scampbell.net> wrote:
> Gary W. Smith wrote:
> >I agree with everything that has been said BUT I must also interject.  A
> >lot small business and many home users who get one or two IP's usually
> >don't have a second DNS floating around.  For larger organizations I
> >would definitely use the split DNS.  We do that at a couple locations
> >when we can.
> >
> Split DNS can be implemented on a single DNS server, check your DNS
> servers manual.  The basics are that you create views of your domain
> structure based on the ip address of the requester, if they are inside
> (for instance 10.0.0.0/8) you give them the inside answers, otherwise
> you give them the outside answers.   You should not need multiple DNS
> servers although you should have multiple servers for other reasons.
> 
> >As for this case, I think it's completely acceptable.
> >
> >Since this does indeed work I think it should be documented as a viable
> >solution (which I think it's in the fine print on one of the docs that I
> >read before).
> >
> >
> FWIW from me I would not accept the answer 'it works so it must be
> okay', that's been the downfall of soooo very many computer projects I
> cannot even begin to count them (a particularily bad attitude for
> programmers).    We'll certainly not argue (and we aren't), it's your
> network and your rules.  My advice is use split DNS from the experience
> that I used to do the sort of thing that you are doing here and I found
> out that it was a bad idea and only created trouble later and I don't
> like trouble, especially if it can be pinned on me!
> 
> 
> 

Almost finished a piece of humble pie here. 

If the webserver is on the internal LAN, split DNS should resolve
differently for internal versus external users. Because the internal
users receive an IP for the internal LAN, the firewall is bypassed. No
DNAT or SNAT duct tape required.

If the webserver is in a DMZ... split DNS should again resolve
differently for internal vs external users. Because the internal users
receive an IP on a different subnet, their webserver traffic is routed
through the firewall. Again, no DNAT/SNAT duct tape required.

Does this sound correct?

Re: dnatting

[Steven M Campbell]

Donald Murray wrote:
>If the webserver is on the internal LAN, split DNS should resolve
>differently for internal versus external users. Because the internal
>users receive an IP for the internal LAN, the firewall is bypassed. No
>DNAT or SNAT duct tape required.
>
>If the webserver is in a DMZ... split DNS should again resolve
>differently for internal vs external users. Because the internal users
>receive an IP on a different subnet, their webserver traffic is routed
>through the firewall. Again, no DNAT/SNAT duct tape required.
>
>Does this sound correct?
>  
I concur.

RE: dnatting

[Gary W. Smith]

Not sure.  Multiple people keep telling me this isn't necessary but I
found that if I don't use these entries then accesses from other local
machines on the same network become unreliable.  Adding the extra line
solves that problem.



> -----Original Message-----
> From: Payal Rathod [mailto:payal-netfilter@scriptkitchen.com]
> Sent: Tuesday, July 12, 2005 12:34 AM
> To: Gary W. Smith
> Cc: Netfilter ML
> Subject: Re: dnatting
> 
> On Mon, Jul 11, 2005 at 12:09:44PM -0700, Gary W. Smith wrote:
> > Payal,
> >
> > You need to add a second simple entry:
> [...]
> 
> Thanks this solved it. Thanks again.
> Now I am curious why Jason didn't suggest this.
> 
> With warm regards,
> -Payal
> 
> >
> > Look at the entries below.  I'm mapping an entire IP but this would
be
> > simple to just to a single port.  The second POSTROUTING line is
what
> > made everything work for my typical firewalls.
> >
> > # Completed on Mon Jul 11 10:58:27 2005
> > # Generated by iptables-save v1.2.11 on Mon Jul 11 10:58:27 2005
> > *nat
> > :PREROUTING ACCEPT [2547:176804]
> > :POSTROUTING ACCEPT [633:40896]
> > :OUTPUT ACCEPT [40:4518]
> > -A PREROUTING -d 81.45.25.50 -j DNAT --to-destination 10.94.16.50
> >
> > -A POSTROUTING -s 10.94.16.50 -o eth0 -j SNAT --to-source
81.45.25.50
> > -A POSTROUTING -s 10.94.16.50 -d 10.94.16.0/255.255.255.0 -j SNAT
> > --to-source 81.45.25.50
> >
> > -A POSTROUTING -o eth0 -p ! ipv6-crypt -j SNAT --to-source
81.45.25.50
> > -A OUTPUT -d 81.45.25.50 -j DNAT --to-destination 10.94.16.50
> > COMMIT
> > # Completed on Mon Jul 11 10:58:27 2005
> >
> >
> > > -----Original Message-----
> > > From: netfilter-bounces@lists.netfilter.org [mailto:netfilter-
> > > bounces@lists.netfilter.org] On Behalf Of Payal Rathod
> > > Sent: Monday, July 11, 2005 8:19 AM
> > > To: Netfilter ML
> > > Subject: dnatting
> > >
> > > Hi,
> > > I have a rule on my friend's broadband connection to redirect
traffic
> > > from outside to an internal machine like,
> > >
> > > iptables -A PREROUTING -d 1.2.3.4 -p tcp -m tcp --dport 80 -j DNAT
\
> > > --to-destination 192.168.10.10:80
> > >
> > > But she complained that people from inside the network cannot do
> > > http://1.2.3.4 in their browser and see the site. Is she correct?
> > > What is wrong with my rule because I can see the site from
outside?
> > >
> > > Thanks in advance.
> > > With warm regards,
> > > -Payal
> > >
> > >
> >

dnatting

[Payal Rathod]

Hi,
I have a rule on my friend's broadband connection to redirect traffic 
from outside to an internal machine like,

iptables -A PREROUTING -d 1.2.3.4 -p tcp -m tcp --dport 80 -j DNAT  \
--to-destination 192.168.10.10:80

But she complained that people from inside the network cannot do
http://1.2.3.4 in their browser and see the site. Is she correct?
What is wrong with my rule because I can see the site from outside?

Thanks in advance.
With warm regards,
-Payal

Re: dnatting

[Jan Engelhardt]

>Hi,
>I have a rule on my friend's broadband connection to redirect traffic 
>from outside to an internal machine like,
>
>iptables -A PREROUTING -d 1.2.3.4 -p tcp -m tcp --dport 80 -j DNAT  \
>--to-destination 192.168.10.10:80
>
>But she complained that people from inside the network cannot do
>http://1.2.3.4 in their browser and see the site. Is she correct?
>What is wrong with my rule because I can see the site from outside?

The packet must pass the machine the DNAT rule is on to make the dnat 
effective.


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

Re: dnatting

[Payal Rathod]

On Mon, Jul 11, 2005 at 05:20:43PM +0200, Jan Engelhardt wrote:
> 
> >Hi,
> >I have a rule on my friend's broadband connection to redirect traffic 
> >from outside to an internal machine like,
> >
> >iptables -A PREROUTING -d 1.2.3.4 -p tcp -m tcp --dport 80 -j DNAT  \
> >--to-destination 192.168.10.10:80
> >
> >But she complained that people from inside the network cannot do
> >http://1.2.3.4 in their browser and see the site. Is she correct?
> >What is wrong with my rule because I can see the site from outside?
> 
> The packet must pass the machine the DNAT rule is on to make the dnat 
> effective.
> 

So what do I do exactly?

With warm regards,
-Payal

Re: dnatting

[/dev/rob0]

Jan Engelhardt wrote:
>>I have a rule on my friend's broadband connection to redirect traffic 
>>from outside to an internal machine like,
> 
>>iptables -A PREROUTING -d 1.2.3.4 -p tcp -m tcp --dport 80 -j DNAT  \
>>--to-destination 192.168.10.10:80
>>
>>But she complained that people from inside the network cannot do
>>http://1.2.3.4 in their browser and see the site. Is she correct?
>>What is wrong with my rule because I can see the site from outside?
> 
> The packet must pass the machine the DNAT rule is on to make the dnat 
> effective.

And then there should be a filter table rule to ACCEPT those packets, or 
at least nothing to DROP or otherwise not accept them.

With a typical (Packet-Filtering-HOWTO-inspired) firewall with default 
DROP policy in FORWARD, you need a corresponding ACCEPT rule in FORWARD 
for every DNAT. In crafting such rules remember that the destination has 
already been rewritten in nat/PREROUTING.

The Web proxy suggestion has me puzzled. :)
-- 
     mail to this address is discarded unless "/dev/rob0"
     or "not-spam" is in Subject: header

Re: dnatting

[Jan Engelhardt]

> The Web proxy suggestion has me puzzled. :)

"me2", because given that 1.2.3.4 is a valid internet-wide IP (e.g. ppp0), 
10.x.y.z is the local net (eth0) and a client is 10.0.0.1 on eth0, there 
should not be any problem to connect from 10.0.0.1 to 1.2.3.4:80 and get it 
DNAT'ed.

Or do you mean that `telnet 127.0.0.1 80` on the DNAT-rulebox itself does not 
work [anymore]?



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

Re: dnatting

[Scott]

You may need to install, additionally, a web proxy,
such as squid and tell iptables to use it as a
transparent proxy for all internal machines, like
this:

iptables -t nat -A POSTROUTING -s
192.168.10.0/255.255.255.0 -i ethX -p tcp -m tcp
--dport 80 -j DNAT --to-destination 192.168.10.1:3128

where ethX is the interface on the internal network.

-Scott

--- Payal Rathod <payal-netfilter@scriptkitchen.com>
wrote:

> Hi,
> I have a rule on my friend's broadband connection to
> redirect traffic 
> from outside to an internal machine like,
> 
> iptables -A PREROUTING -d 1.2.3.4 -p tcp -m tcp
> --dport 80 -j DNAT  \
> --to-destination 192.168.10.10:80
> 
> But she complained that people from inside the
> network cannot do
> http://1.2.3.4 in their browser and see the site. Is
> she correct?
> What is wrong with my rule because I can see the
> site from outside?
> 
> Thanks in advance.
> With warm regards,
> -Payal
> 
> 
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: dnatting

[Jason Opperisano]

On Mon, Jul 11, 2005 at 11:18:30AM -0400, Payal Rathod wrote:
> Hi,
> I have a rule on my friend's broadband connection to redirect traffic 
> from outside to an internal machine like,
> 
> iptables -A PREROUTING -d 1.2.3.4 -p tcp -m tcp --dport 80 -j DNAT  \
> --to-destination 192.168.10.10:80
> 
> But she complained that people from inside the network cannot do
> http://1.2.3.4 in their browser and see the site. Is she correct?
> What is wrong with my rule because I can see the site from outside?

1)  client; say 192.168.10.100, sends TCP SYN to 1.2.3.4

2)  iptables machine receives packet destined for 1.2.3.4, DNAT's it to
    192.168.10.10 and forwards the packet out the internal interface

3)  192.168.10.10 receives TCP SYN from 192.168.10.100 and replies
    directly to 192.168.10.100 with a SYN/ACK

4)  client; 192.168.10.100, receives SYN/ACK from 192.168.10.10 and
    discards it, as it matches no connection in the SYN_SENT state
    (recall that our SYN was sent to 1.2.3.4).

that the why.  the proper way to avoid this is to have people on the
inside connect to 192.168.10.10.  i will leave all the half-assed
work-arounds and kludges as an exercise for the reader and other
posters.

-j

--
"Peter: This party couldn't be better if Jesus was here.
 Jesus: For my next miracle, I will turn water... into FUNK."
        --Family Guy

Re: dnatting

[Jan Engelhardt]

>4)  client; 192.168.10.100, receives SYN/ACK from 192.168.10.10 and
>    discards it, as it matches no connection in the SYN_SENT state
>    (recall that our SYN was sent to 1.2.3.4).

Now I get the point of problem. Well, there was *once* implicit SNAT in 
netfilter (at least in conjunction with IP_NF_NAT_LOCAL)

>that the why.  the proper way to avoid this is to have people on the
>inside connect to 192.168.10.10.

Re: dnatting

[Donald Murray]

On 7/11/05, Jason Opperisano <opie@817west.com> wrote:
> On Mon, Jul 11, 2005 at 11:18:30AM -0400, Payal Rathod wrote:
> > Hi,
> > I have a rule on my friend's broadband connection to redirect traffic
> > from outside to an internal machine like,
> >
> > iptables -A PREROUTING -d 1.2.3.4 -p tcp -m tcp --dport 80 -j DNAT  \
> > --to-destination 192.168.10.10:80
> >
> > But she complained that people from inside the network cannot do
> > http://1.2.3.4 in their browser and see the site. Is she correct?
> > What is wrong with my rule because I can see the site from outside?
> 
> 1)  client; say 192.168.10.100, sends TCP SYN to 1.2.3.4
> 
> 2)  iptables machine receives packet destined for 1.2.3.4, DNAT's it to
>     192.168.10.10 and forwards the packet out the internal interface
> 
> 3)  192.168.10.10 receives TCP SYN from 192.168.10.100 and replies
>     directly to 192.168.10.100 with a SYN/ACK
> 
> 4)  client; 192.168.10.100, receives SYN/ACK from 192.168.10.10 and
>     discards it, as it matches no connection in the SYN_SENT state
>     (recall that our SYN was sent to 1.2.3.4).
> 
> that the why.  the proper way to avoid this is to have people on the
> inside connect to 192.168.10.10.  i will leave all the half-assed
> work-arounds and kludges as an exercise for the reader and other
> posters.
> 
> -j
> 
> --
> "Peter: This party couldn't be better if Jesus was here.
>  Jesus: For my next miracle, I will turn water... into FUNK."
>         --Family Guy
> 
> 

Because the destination server is on the same subnet, users on the inside
could indeed connect directly to that machine. Alternatively this could be
handled via DNS.


However, if the destination server is inside a DMZ, the firewall needs
to DNAT in
PREROUTING and SNAT in POSTROUTING. The DNAT gets traffic to
the DMZ, the SNAT allows it back. Something like:

    iptables --table nat -A PREROUTING -p tcp -i $LAN_INTERFACE --dport http \
        -d $INTERNET_IP -j DNAT --to-destination $DMZ_HTTP_IP

    iptables --table nat -A POSTROUTING -d $DMZ_HTTP_IP -s $LAN_IP_RANGE \
        -p tcp --dport http -j SNAT --to-source $LAN_IP

Re: dnatting

[Jason Opperisano]

On Tue, Jul 12, 2005 at 09:21:43PM -0600, Donald Murray wrote:
> Because the destination server is on the same subnet, users on the inside
> could indeed connect directly to that machine. Alternatively this could be
> handled via DNS.
> 
> 
> However, if the destination server is inside a DMZ, the firewall needs
> to DNAT in
> PREROUTING and SNAT in POSTROUTING. The DNAT gets traffic to
> the DMZ, the SNAT allows it back. Something like:

no--it doesn't.  if by "the destination server is inside a DMZ" you mean
the web server is on a different layer3 subnet than the client, routed
through the firewall.  you are applying the half-assed SNAT solution where
it's not even needed.  this is worse than the SNAT for the OP's scenario;
at least there the SNAT serves to create some semblance of functionality.

NAT is the duct tape of networking; if you can route, route.

-j

--
"Peter: I'm going to microwave a bagel and have sex with it.
 Quagmire: Butter's in the fridge."
        --Family Guy

Re: dnatting

[curby .]

On 7/11/05, Payal Rathod <payal-netfilter@scriptkitchen.com> wrote:
> Hi,
> I have a rule on my friend's broadband connection to redirect traffic
> from outside to an internal machine like,
> 
> iptables -A PREROUTING -d 1.2.3.4 -p tcp -m tcp --dport 80 -j DNAT  \
> --to-destination 192.168.10.10:80
> 
> But she complained that people from inside the network cannot do
> http://1.2.3.4 in their browser and see the site. Is she correct?
> What is wrong with my rule because I can see the site from outside?

The problem is only the initial SYN will go through the expected route.

1) Client 192.168.10.53 > Server 1.2.3.4
2) Router 192.168.10.1 DNATs packet to 192.168.10.10
3) Server 192.168.10.10 sees request from 192.168.10.53
4) Server sends response to 192.168.10.53
5) Client expects response from 1.2.3.4, receives from 192.168.10.10, drops it

Instead you want

1) Client 192.168.10.53 > Server 1.2.3.4
2) Router DNATs packet to 192.168.10.10, SNATs packet to 192.168.10.1
3) Server sees request from 192.168.10.1
4) Server sends response to 192.168.10.1
5) Router uses SNAT to relay response to 192.168.10.53
5) Client gets expected response from 1.2.3.4

See here for implementation details: 
http://netfilter.org/documentation/HOWTO//NAT-HOWTO-10.html

Re: dnatting

[curby .]

On 7/14/05, curby . <curby.public@gmail.com> wrote:
[snip]
> See here for implementation details:
> http://netfilter.org/documentation/HOWTO//NAT-HOWTO-10.html

Boy, how embarassing.  This has already been discussed to death. =P

Re: DNAT+SNAT vs DNS: depends on your network.  It's been mentioned
that some people don't even have a DNS server...