* Nat OUTPUT chain
@ 2002-06-02 13:42 gvt_lnx
2002-06-02 14:05 ` Antony Stone
0 siblings, 1 reply; 6+ messages in thread
From: gvt_lnx @ 2002-06-02 13:42 UTC (permalink / raw)
To: netfilter, netfilter
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Nat OUTPUT chain
2002-06-02 13:42 Nat OUTPUT chain gvt_lnx
@ 2002-06-02 14:05 ` Antony Stone
0 siblings, 0 replies; 6+ messages in thread
From: Antony Stone @ 2002-06-02 14:05 UTC (permalink / raw)
To: netfilter@lists.samba.org
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Nat OUTPUT chain
@ 2002-06-15 23:57 hard__ware
2002-06-15 23:59 ` Antony Stone
0 siblings, 1 reply; 6+ messages in thread
From: hard__ware @ 2002-06-15 23:57 UTC (permalink / raw)
To: netfilter
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 .. :-)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Nat OUTPUT chain
2002-06-15 23:57 hard__ware
@ 2002-06-15 23:59 ` Antony Stone
2002-06-16 7:43 ` Patrick Schaaf
0 siblings, 1 reply; 6+ messages in thread
From: Antony Stone @ 2002-06-15 23:59 UTC (permalink / raw)
To: netfilter
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Nat OUTPUT chain
2002-06-15 23:59 ` Antony Stone
@ 2002-06-16 7:43 ` Patrick Schaaf
0 siblings, 0 replies; 6+ messages in thread
From: Patrick Schaaf @ 2002-06-16 7:43 UTC (permalink / raw)
To: Antony Stone; +Cc: netfilter
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Nat OUTPUT chain
@ 2002-06-16 2:30 Hard__warE
0 siblings, 0 replies; 6+ messages in thread
From: Hard__warE @ 2002-06-16 2:30 UTC (permalink / raw)
To: netfilter
>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 ?? )
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2002-06-16 7:43 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-06-02 13:42 Nat OUTPUT chain gvt_lnx
2002-06-02 14:05 ` Antony Stone
-- strict thread matches above, loose matches on Subject: below --
2002-06-15 23:57 hard__ware
2002-06-15 23:59 ` Antony Stone
2002-06-16 7:43 ` Patrick Schaaf
2002-06-16 2:30 Hard__warE
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.