Nat OUTPUT chain

Nat OUTPUT chain

[gvt_lnx]

Hi friends, I'am reading some howto and I found that OUTPUT chain in NAT
table is broken...? that's true?

Could I write a rule like this:

iptables -t nat -A OUTPUT -d x.x.x.x -j DNAT --to-destination y.y.y.y

Thanks in advance.
Geffrey

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net

Re: Nat OUTPUT chain

[Antony Stone]

On Sunday 02 June 2002 2:42 pm, gvt_lnx@gmx.net wrote:

> Hi friends, I'am reading some howto and I found that OUTPUT chain in NAT
> table is broken...? that's true?

I'm not sure about this one - I know it used to be broken; I don't know if it 
still is...

Why not just try it for yourself ?   A simple test will tell you if your 
version of netfilter can do it or not.

> Could I write a rule like this:
>
> iptables -t nat -A OUTPUT -d x.x.x.x -j DNAT --to-destination y.y.y.y

Looks okay according to the syntax in the iptables man page - try it and see. 
Put a rule like this on your machine, then telnet (or whatever) to x.x.x.x 
and see if you end up connecting to x.x.x.x or y.y.y.y


Antony.

Nat OUTPUT chain

[hard__ware]

this question is a bit old

but ive seen it asked many other places .. :D


the  -t nat OUTPUT  table seems to work fine for me

i have set up DNAT aswell as ACCEPT Rules

(as i have a Default Policy of DROP,  IPTABLES -P -t  nat OUTPUT DROP  )

and the packets Traverse Through the chain correctly .. :-)

i use two differnet versions of IPTables (i have 2 Firewall Boxes .. :-)

IPTables 1.2.5mdk-1
&
IPTables 1.2.6a

if your having problems with this chain try an upgrade if your not already
at these versions .. :-)

Re: Nat OUTPUT chain

[Antony Stone]

On Sunday 16 June 2002 12:57 am, hard__ware wrote:

> the  -t nat OUTPUT  table seems to work fine for me
>
> i have set up DNAT aswell as ACCEPT Rules
>
> (as i have a Default Policy of DROP,  IPTABLES -P -t  nat OUTPUT DROP  )

Why do you DROP in the nat table instead of the filter table ?

 

Antony.

Nat OUTPUT chain

[Hard__warE]

>Why do you DROP in the nat table instead of the filter table ?
>
>
>Antony.

Good Question ...

1. im very Young and i luv nat and seeing what it can do.. :-D , would also
eventually like to gain work in Internet Sercurity / Iptbales / Zebra /
Bridged / Gated / iproute2 / ipchains (yay) / TC  TBF , CBQ , ect ect .

.2 actually i have every single one Policy's set to DROP for all of the
filter & nat chains.. :-D
is there something wrong with that, ?  Yer but you have to check the logs
alot from the Drop & Log end of chain
per chain Rules i have (they all have a different prefix applies ie "Nat
Ouput")
so you can add more rules ...  {:?/]

P.s. and about the MIRROR converstation

i need to set a way so all data on a Given Proto / IP gets MIRRORed but some
how Dnat it
so it goes to a Honney Pot for Logging and decide to take Action or not ..
:-D

(this is nearlly all working except the fact that the Packet / Traffic
accounting is not being properly matched ?? )

Re: Nat OUTPUT chain

[Patrick Schaaf]

Hi all,

> Why do you DROP in the nat table instead of the filter table ?

Note that there are situations where this is advisable, and other
approaches result in more complex rulesets.

Imagine a situation where you want to REDIRECT certain incoming
connections, e.g.  everything to --dport 80, with the local service
running on port 3128. However, you DON'T want to have those redirected
clients access 3128 DIRECTLY. Using REDIRECT, both the direct and
redirected connections arrive in the filter table's INPUT chain,
and cannot be easily distinguished there, because the filter table
sees the rewritten destination IP and port.

My first solution involved the mangle table, tagging the different
incoming packets with an fwmark, and using that fwmark in both the
NAT and filter tables.

My current solution does the desired REDIRECTs in the NAT table,
and DROPs everything unwanted right there; the filter table just
permits the redirected port 3128 traffic. So that's where I found
good use for DROP in the NAT table.

An alternative, not doable with stock iptables (there's something
in p-o-m, I think), would be a filter table target which is capable
of matching the ORIGINAL_DESTINATION of the REDIRECTed connections.

best regards
  Patrick