ping broadcast into forward chain?? (IN=eth0 OUT=eth0)!!

ping broadcast into forward chain?? (IN=eth0 OUT=eth0)!!

[Julio A. Romero]

This is a real scenario:

My external eth0=10.6.100.109, eth0:0=10.6.100.104
My internal eth2=10.6.13.254
My internal networks=10.6.11.0/24,10.6.13.0/24,10.6.40.0/24

Why these packests appear into the forward chain?

My syslog:

...
Sep 19 10:44:32 firewall kernel: [316561.880144] FW:FWD:netfilter_fwd:? 
IN=eth0 OUT=eth0 SRC=10.28.1
0.76 DST=10.6.15.246 LEN=60 TOS=0x00 PREC=0x00 TTL=54 ID=17064 PROTO=ICMP 
TYPE=8 CODE=0 ID=512 SEQ=1
2558
Sep 19 10:44:32 firewall kernel: [316561.880273] FW:FWD:netfilter_fwd:? 
IN=eth0 OUT=eth0 SRC=10.28.1
0.76 DST=10.6.15.247 LEN=60 TOS=0x00 PREC=0x00 TTL=54 ID=17065 PROTO=ICMP 
TYPE=8 CODE=0 ID=512 SEQ=1
2814
Sep 19 10:44:32 firewall kernel: [316561.881250] FW:FWD:netfilter_fwd:? 
IN=eth0 OUT=eth0 SRC=10.28.1
0.76 DST=10.6.15.248 LEN=60 TOS=0x00 PREC=0x00 TTL=54 ID=17066 PROTO=ICMP 
TYPE=8 CODE=0 ID=512 SEQ=1
3070
Sep 19 10:44:32 firewall kernel: [316561.882040] FW:FWD:netfilter_fwd:? 
IN=eth0 OUT=eth0 SRC=10.28.1
0.76 DST=10.6.15.249 LEN=60 TOS=0x00 PREC=0x00 TTL=54 ID=17067 PROTO=ICMP 
TYPE=8 CODE=0 ID=512 SEQ=1
3326
Sep 19 10:44:32 firewall kernel: [316561.882793] FW:FWD:netfilter_fwd:? 
IN=eth0 OUT=eth0 SRC=10.28.1
0.76 DST=10.6.15.250 LEN=60 TOS=0x00 PREC=0x00 TTL=54 ID=17068 PROTO=ICMP 
TYPE=8 CODE=0 ID=512 SEQ=1
3582
Sep 19 10:44:32 firewall kernel: [316561.883546] FW:FWD:netfilter_fwd:? 
IN=eth0 OUT=eth0 SRC=10.28.1
0.76 DST=10.6.15.251 LEN=60 TOS=0x00 PREC=0x00 TTL=54 ID=17069 PROTO=ICMP 
TYPE=8 CODE=0 ID=512 SEQ=1
3838
Sep 19 10:44:32 firewall kernel: [316561.884549] FW:FWD:netfilter_fwd:? 
IN=eth0 OUT=eth0 SRC=10.28.1
0.76 DST=10.6.15.252 LEN=60 TOS=0x00 PREC=0x00 TTL=54 ID=17070 PROTO=ICMP 
TYPE=8 CODE=0 ID=512 SEQ=1
4094
Sep 19 10:44:32 firewall kernel: [316561.885317] FW:FWD:netfilter_fwd:? 
IN=eth0 OUT=eth0 SRC=10.28.1
0.76 DST=10.6.15.253 LEN=60 TOS=0x00 PREC=0x00 TTL=54 ID=17071 PROTO=ICMP 
TYPE=8 CODE=0 ID=512 SEQ=1
4350
Sep 19 10:44:32 firewall kernel: [316561.886557] FW:FWD:netfilter_fwd:? 
IN=eth0 OUT=eth0 SRC=10.28.1
0.76 DST=10.6.15.254 LEN=60 TOS=0x00 PREC=0x00 TTL=54 ID=17072 PROTO=ICMP 
TYPE=8 CODE=0 ID=512 SEQ=1
4606
Sep 19 10:44:32 firewall kernel: [316561.889452] FW:FWD:netfilter_fwd:? 
IN=eth0 OUT=eth0 SRC=10.28.1
0.76 DST=10.6.15.255 LEN=60 TOS=0x00 PREC=0x00 TTL=54 ID=17073 PROTO=ICMP 
TYPE=8 CODE=0 ID=512 SEQ=1
4862
...

the two involved chains:

###########################
# ipv4 - FILTER - FORWARD #
###########################
# FORWARD RULES
#
# Forward all traffic to netfilter_fwd
iptables -A FORWARD -j netfilter_fwd
# Allow (established|related) connections in returned traffic of 
netfilter_fwd
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
# Send all other ICMP returned packets to icmpfilter
iptables -A FORWARD -p icmp -g icmpfilter
# Send all other UDP returned packets to udpport
iptables -A FORWARD -p udp -g udpport
# Send all other TCP returned packets to tcpport
iptables -A FORWARD -p tcp -g tcpport
# Send all other returned fragmented packets to average
iptables -A FORWARD -f -j average
# Log for debugger
iptables -A FORWARD -j LOG --log-prefix "FW:FWD:? "
#######
# END #
#######

###########################
# ipv4 - FILTER - netfilter_fwd #
###########################
# NETFILTER_FWD RULES
#
# Create netfilter_fwd
iptables -N netfilter_fwd
# LOG and DROP untrue connections
iptables -A netfilter_fwd -s $GW_NETWORKS -j LOG --log-prefix "FW:FWD:BOX->* 
"
iptables -A netfilter_fwd -s $GW_NETWORKS -j DROP
iptables -A netfilter_fwd -d $GW_NETWORKS -j LOG --log-prefix "FW:FWD:*->BOX 
"
iptables -A netfilter_fwd -d $GW_NETWORKS -j DROP
iptables -A netfilter_fwd -i $INT_IFACEs -o $EXT_IFACEs -d $INT_NETWORKS -j 
LOG \
--log-prefix "FW:FWD:I->E:dst:INT_NET "
iptables -A netfilter_fwd -i $INT_IFACEs -o $EXT_IFACEs -d $INT_NETWORKS -j 
DROP
iptables -A netfilter_fwd -i $EXT_IFACEs -o $INT_IFACEs -s $INT_NETWORKS -j 
LOG \
--log-prefix "FW:FWD:E->I:src:INT_NET "
iptables -A netfilter_fwd -i $EXT_IFACEs -o $INT_IFACEs -s $INT_NETWORKS -j 
DROP
# Send outgoing traffic to dstnetfilter for validation of the destination
iptables -A netfilter_fwd -i $INT_IFACEs -o $EXT_IFACEs -s $INT_NETWORKS -g 
dstnetfilter
# Send incoming traffic to srcnetfilter for validation of the source
iptables -A netfilter_fwd -i $EXT_IFACEs -o $INT_IFACEs -d $INT_NETWORKS -g 
srcnetfilter
# LOG and DROP all other traffic
iptables -A netfilter_fwd -j LOG --log-prefix "FW:FWD:netfilter_fwd:? "
iptables -A netfilter_fwd -j DROP
#######
# END #
#######

thanks,
julio 

Re: ping broadcast into forward chain?? (IN=eth0 OUT=eth0)!!

[Jan Engelhardt]

On Monday 2011-09-19 17:29, Julio A. Romero wrote:

> This is a real scenario:
>
> My external eth0=10.6.100.109, eth0:0=10.6.100.104
> My internal eth2=10.6.13.254
> My internal networks=10.6.11.0/24,10.6.13.0/24,10.6.40.0/24
>
> Why these packests [below] appear into the forward chain?

Where else should they appear?

>Sep 19 10:44:32 firewall kernel: [316561.880144] FW:FWD:netfilter_fwd:? 
>IN=eth0 OUT=eth0 SRC=10.28.10.76 DST=10.6.15.246 LEN=60 TOS=0x00 
>PREC=0x00 TTL=54 ID=17064 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=12558

Re: ping broadcast into forward chain?? (IN=eth0 OUT=eth0)!!

[Jan Engelhardt]

Bah, don't strip the CC, and don't top-post.

On Monday 2011-09-19 17:43, Julio A. Romero wrote:

> In the INPUT chain!!??

No, why? It was not a broadcast packet. Your syslog itself says:
DST=10.6.15.246.

>
> ----- Original Message ----- From: "Jan Engelhardt" <jengelh@medozas.de>
> To: "Julio A. Romero" <julioarr@fisica.uh.cu>
> Cc: <netfilter@vger.kernel.org>
> Sent: Monday, September 19, 2011 11:38 AM
> Subject: Re: ping broadcast into forward chain?? (IN=eth0 OUT=eth0)!!
>
>
>> On Monday 2011-09-19 17:29, Julio A. Romero wrote:
>>
>>> This is a real scenario:
>>>
>>> My external eth0=10.6.100.109, eth0:0=10.6.100.104
>>> My internal eth2=10.6.13.254
>>> My internal networks=10.6.11.0/24,10.6.13.0/24,10.6.40.0/24
>>>
>>> Why these packests [below] appear into the forward chain?
>>
>> Where else should they appear?
>>
>>> Sep 19 10:44:32 firewall kernel: [316561.880144] FW:FWD:netfilter_fwd:?
>>> IN=eth0 OUT=eth0 SRC=10.28.10.76 DST=10.6.15.246 LEN=60 TOS=0x00
>>> PREC=0x00 TTL=54 ID=17064 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=12558
>> --
>> To unsubscribe from this list: send the line "unsubscribe netfilter" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
> --------------------------------------------------------------------------------
>
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 9.0.914 / Virus Database: 271.1.1/3906 - Release Date: 09/19/11
> 02:34:00
>
>

Re: ping broadcast into forward chain?? (IN=eth0 OUT=eth0)!!

[Julio A. Romero]

----- Original Message ----- 
From: "Jan Engelhardt" <jengelh@medozas.de>
To: "Julio A. Romero" <julioarr@fisica.uh.cu>
Cc: <netfilter@vger.kernel.org>
Sent: Monday, September 19, 2011 11:55 AM
Subject: Re: ping broadcast into forward chain?? (IN=eth0 OUT=eth0)!!


> Bah, don't strip the CC, and don't top-post.
>
> On Monday 2011-09-19 17:43, Julio A. Romero wrote:
>
>> In the INPUT chain!!??
>
> No, why? It was not a broadcast packet. Your syslog itself says:
> DST=10.6.15.246.

but 10.6.15.246 is outside of my internal networks ?? and the interfaces 
IN/OUT is the same external iface of the BOX;
the packets don't go through the box or yes?! what happen if I remove the 
rule to log?

>
>>
>> ----- Original Message ----- From: "Jan Engelhardt" <jengelh@medozas.de>
>> To: "Julio A. Romero" <julioarr@fisica.uh.cu>
>> Cc: <netfilter@vger.kernel.org>
>> Sent: Monday, September 19, 2011 11:38 AM
>> Subject: Re: ping broadcast into forward chain?? (IN=eth0 OUT=eth0)!!
>>
>>
>>> On Monday 2011-09-19 17:29, Julio A. Romero wrote:
>>>
>>>> This is a real scenario:
>>>>
>>>> My external eth0=10.6.100.109, eth0:0=10.6.100.104
>>>> My internal eth2=10.6.13.254
>>>> My internal networks=10.6.11.0/24,10.6.13.0/24,10.6.40.0/24
>>>>
>>>> Why these packests [below] appear into the forward chain?
>>>
>>> Where else should they appear?
>>>
>>>> Sep 19 10:44:32 firewall kernel: [316561.880144] FW:FWD:netfilter_fwd:?
>>>> IN=eth0 OUT=eth0 SRC=10.28.10.76 DST=10.6.15.246 LEN=60 TOS=0x00
>>>> PREC=0x00 TTL=54 ID=17064 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=12558
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe netfilter" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>
>> --------------------------------------------------------------------------------
>>
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com
>> Version: 9.0.914 / Virus Database: 271.1.1/3906 - Release Date: 09/19/11
>> 02:34:00
>>
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


--------------------------------------------------------------------------------



No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.914 / Virus Database: 271.1.1/3906 - Release Date: 09/19/11 
02:34:00

Re: ping broadcast into forward chain?? (IN=eth0 OUT=eth0)!!

[Jan Engelhardt]

On Monday 2011-09-19 18:10, Julio A. Romero wrote:

>
> ----- Original Message ----- From: "Jan Engelhardt" <jengelh@medozas.de>
> To: "Julio A. Romero" <julioarr@fisica.uh.cu>
> Cc: <netfilter@vger.kernel.org>
> Sent: Monday, September 19, 2011 11:55 AM
> Subject: Re: ping broadcast into forward chain?? (IN=eth0 OUT=eth0)!!
>
>
>> Bah, don't strip the CC, and don't top-post.
>>
>> On Monday 2011-09-19 17:43, Julio A. Romero wrote:
>>
>>> In the INPUT chain!!??
>>
>> No, why? It was not a broadcast packet. Your syslog itself says:
>> DST=10.6.15.246.
>
> but 10.6.15.246 is outside of my internal networks ??

Yes, which is why it goes to OUT=eth0.

> the packets don't go through the box or yes?!

Of course they do go through your box, otherwise it would not be able to 
log them.

> what happen if I remove the rule to log?

There would be no entry in syslog, obviously.

Re: ping broadcast into forward chain?? (IN=eth0 OUT=eth0)!!

[Julio A. Romero]

----- Original Message ----- 
From: "Jan Engelhardt" <jengelh@medozas.de>
To: "Julio A. Romero" <julioarr@fisica.uh.cu>
Cc: <netfilter@vger.kernel.org>
Sent: Monday, September 19, 2011 12:15 PM
Subject: Re: ping broadcast into forward chain?? (IN=eth0 OUT=eth0)!!


> On Monday 2011-09-19 18:10, Julio A. Romero wrote:
>
>>
>> ----- Original Message ----- From: "Jan Engelhardt" <jengelh@medozas.de>
>> To: "Julio A. Romero" <julioarr@fisica.uh.cu>
>> Cc: <netfilter@vger.kernel.org>
>> Sent: Monday, September 19, 2011 11:55 AM
>> Subject: Re: ping broadcast into forward chain?? (IN=eth0 OUT=eth0)!!
>>
>>
>>> Bah, don't strip the CC, and don't top-post.
>>>
>>> On Monday 2011-09-19 17:43, Julio A. Romero wrote:
>>>
>>>> In the INPUT chain!!??
>>>
>>> No, why? It was not a broadcast packet. Your syslog itself says:
>>> DST=10.6.15.246.
>>
>> but 10.6.15.246 is outside of my internal networks ??
>
> Yes, which is why it goes to OUT=eth0.

 ok, the packets are forwarding in eth0, so why?

the sources of the packets is outside of my networks and also the
destination:
SRC=10.28.10.76 DST=10.6.15.246

eth0=10.6.100.109 and eth0:0=10.6.100.104 and eth2=10.6.13.254

root@firewall:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use
Iface
10.6.13.0       10.6.13.253     255.255.255.252 UG    0      0        0 eth2
10.6.13.252     0.0.0.0         255.255.255.252 U     0      0        0 eth2
10.6.100.0      0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.6.12.0       10.6.100.113    255.255.255.0   UG    0      0        0 eth0
10.6.40.0       10.6.13.253     255.255.255.0   UG    0      0        0 eth2
10.6.11.0       10.6.13.253     255.255.255.0   UG    0      0        0 eth2
0.0.0.0         10.6.100.1      0.0.0.0         UG    0      0        0 eth0

>
>> the packets don't go through the box or yes?!
>
> Of course they do go through your box, otherwise it would not be able to
> log them.
>
>> what happen if I remove the rule to log?
>
> There would be no entry in syslog, obviously.
>
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


--------------------------------------------------------------------------------



No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.914 / Virus Database: 271.1.1/3906 - Release Date: 09/19/11
02:34:00

Re: ping broadcast into forward chain?? (IN=eth0 OUT=eth0)!!

[Jan Engelhardt]

On Monday 2011-09-19 18:38, Julio A. Romero wrote:
>>>>> In the INPUT chain!!??
>>>>
>>>> No, why? It was not a broadcast packet. Your syslog itself says:
>>>> DST=10.6.15.246.
>>>
>>> but 10.6.15.246 is outside of my internal networks ??
>>
>> Yes, which is why it goes to OUT=eth0.
>
> ok, the packets are forwarding in eth0, so why?

Because the packet was not destined for this host.

Re: ping broadcast into forward chain?? (IN=eth0 OUT=eth0)!!

[Julio A. Romero]

----- Original Message ----- 
From: "Jan Engelhardt" <jengelh@medozas.de>
To: "Julio A. Romero" <julioarr@fisica.uh.cu>
Cc: <netfilter@vger.kernel.org>
Sent: Monday, September 19, 2011 12:15 PM
Subject: Re: ping broadcast into forward chain?? (IN=eth0 OUT=eth0)!!


> On Monday 2011-09-19 18:10, Julio A. Romero wrote:
>
>>
>> ----- Original Message ----- From: "Jan Engelhardt" <jengelh@medozas.de>
>> To: "Julio A. Romero" <julioarr@fisica.uh.cu>
>> Cc: <netfilter@vger.kernel.org>
>> Sent: Monday, September 19, 2011 11:55 AM
>> Subject: Re: ping broadcast into forward chain?? (IN=eth0 OUT=eth0)!!
>>
>>
>>> Bah, don't strip the CC, and don't top-post.
>>>
>>> On Monday 2011-09-19 17:43, Julio A. Romero wrote:
>>>
>>>> In the INPUT chain!!??
>>>
>>> No, why? It was not a broadcast packet. Your syslog itself says:
>>> DST=10.6.15.246.
>>
>> but 10.6.15.246 is outside of my internal networks ??
>
> Yes, which is why it goes to OUT=eth0.
>
>> the packets don't go through the box or yes?!
>
> Of course they do go through your box, otherwise it would not be able to
> log them.
>
>> what happen if I remove the rule to log?
>
> There would be no entry in syslog, obviously.

now I know what happen!

anyone, I don't know who, he/she set a unassigned route pointing to my box. 
The packets arrived to my box through the external interface and then the 
destination is wrong, so, the packets go to the default gateway configured 
in my box, again through the external interface because the default gateway 
is outside of my network. When I set a rule in the FORWARD chain logging and 
dropping the packet whose source or destination don't match with my 
networks, I never thought in the above-mentioned situation.

thanks once again!
julio

>
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


--------------------------------------------------------------------------------



No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.914 / Virus Database: 271.1.1/3906 - Release Date: 09/19/11 
02:34:00

Help on outgoing packet (without NAT)

[Jorge Bastos]

Howdy,

I'd like some help on how can I redirect the outgoing packets without 
using NAT.

I have a machine, that when requests to IP 5.5.5.5 and port 80 are 
made, the request be redirected to 192.168.1.221:80
I'm trying this but no luck, maybe I'm close to it:

iptables -I FORWARD -d 5.5.5.5 -p tcp --dport 80 --to 192.168.1.221:80

What can I missing or what do I need to add?

Thanks in advanced,
Jorge Bastos,

Re: Help on outgoing packet (without NAT)

[Andrew Beverley]

On Wed, 2011-09-21 at 22:23 +0100, Jorge Bastos wrote:
> Howdy,
> 
> I'd like some help on how can I redirect the outgoing packets without 
> using NAT.
> 
> I have a machine, that when requests to IP 5.5.5.5 and port 80 are 
> made, the request be redirected to 192.168.1.221:80
> I'm trying this but no luck, maybe I'm close to it:
> 
> iptables -I FORWARD -d 5.5.5.5 -p tcp --dport 80 --to 192.168.1.221:80
> 
> What can I missing or what do I need to add?

Assuming that you are referring to packets generated on the local
machine (which is what is implied), then you need to use OUTPUT instead
of FORWARD.

FORWARD is only for packets that arrive from another machine. OUTPUT is
for locally generated packets.

Andy

Re: Help on outgoing packet (without NAT)

[Jan Engelhardt]

On Wednesday 2011-09-21 23:23, Jorge Bastos wrote:
>
> I have a machine, that when requests to IP 5.5.5.5 and port 80 are made, the
> request be redirected to 192.168.1.221:80
> I'm trying this but no luck, maybe I'm close to it:
>
> iptables -I FORWARD -d 5.5.5.5 -p tcp --dport 80 --to 192.168.1.221:80
>
> What can I missing or what do I need to add?

The error message you get, at least.

Re: Help on outgoing packet (without NAT)

[Jorge Bastos]

Hi Andy,

>> Howdy, I'd like some help on how can I redirect the outgoing packets
>> without using NAT. I have a machine, that when requests to IP 
>> 5.5.5.5
>> and port 80 are made, the request be redirected to 192.168.1.221:80 
>> I'm
>> trying this but no luck, maybe I'm close to it: iptables -I FORWARD 
>> -d
>> 5.5.5.5 -p tcp --dport 80 --to 192.168.1.221:80 What can I missing 
>> or
>> what do I need to add?
>
> Assuming that you are referring to packets generated on the local
> machine (which is what is implied), then you need to use OUTPUT 
> instead
> of FORWARD.
>
> FORWARD is only for packets that arrive from another machine. OUTPUT 
> is
> for locally generated packets.

Correct, local generated packets.
Tried:

iptables -I OUTPUT -d 5.5.5.5 -p tcp --dport 80 --redirect-to 
192.168.1.221:80

I'm missing something but not sure what, but it's on the redirect part.

Re: Help on outgoing packet (without NAT)

[Jan Engelhardt]

On Thursday 2011-09-22 17:58, Jorge Bastos wrote:

> Hi Andy,
>
>>> Howdy, I'd like some help on how can I redirect the outgoing packets
>>> without using NAT. I have a machine, that when requests to IP 5.5.5.5
>>> and port 80 are made, the request be redirected to 192.168.1.221:80 I'm
>>> trying this but no luck, maybe I'm close to it: iptables -I FORWARD -d
>>> 5.5.5.5 -p tcp --dport 80 --to 192.168.1.221:80 What can I missing or
>>> what do I need to add?
>>
>> Assuming that you are referring to packets generated on the local
>> machine (which is what is implied), then you need to use OUTPUT instead
>> of FORWARD.
>>
>> FORWARD is only for packets that arrive from another machine. OUTPUT is
>> for locally generated packets.
>
> Correct, local generated packets.
> Tried:
>
> iptables -I OUTPUT -d 5.5.5.5 -p tcp --dport 80 --redirect-to 192.168.1.221:80

What makes you think that there is an error in redirect?

Re: Help on outgoing packet (without NAT)

[Jorge Bastos]

>> Correct, local generated packets.
Tried:
iptables -I OUTPUT -d 5.5.5.5 -p tcp --dport 80 --redirect-to 
192.168.1.221:80

> What makes you think that there is an error in redirect?

iptables -I OUTPUT -d 5.5.5.5 -p tcp --dport 80 --redirect-to 
192.168.1.221:80
iptables v1.4.9.1: unknown option `--redirect-to'
Try `iptables -h' or 'iptables --help' for more information.

Re: Help on outgoing packet (without NAT)

[Leonardo Rodrigues]

Em 22/09/11 12:58, Jorge Bastos escreveu:
>
> Correct, local generated packets.
> Tried:
>
> iptables -I OUTPUT -d 5.5.5.5 -p tcp --dport 80 --redirect-to 
> 192.168.1.221:80
>
> I'm missing something but not sure what, but it's on the redirect part.

     Your rule is absolutely incomplete and nonsense

     packet redirections should be done on the NAT table. If no table is 
specified on the command, you'll work on the filter table, which is not 
the one you want here. So '-t nat' is needed.

     the '--redirect-to' is not an argument for any of the known targets 
i know .... but as it seems you want to redirect some packet to another 
machine, than you'll probably want the DNAT target. Anyway, you have not 
specified any target, so iptables simply doesnt know what to do.

     calling the correct target with correct argument, your rule should 
look something like:

iptables -t nat -I OUTPUT -d 5.5.5.5 -p tcp --dport 80 -j DNAT 
--to-destination 192.168.1.221

     no need to specify the :80 port to the destination target. If you 
want to redirect to the same port, you dont need to specify that. You 
would need to specify if you were changing ports.

-- 


	Atenciosamente / Sincerily,
	Leonardo Rodrigues
	Solutti Tecnologia
	http://www.solutti.com.br

	Minha armadilha de SPAM, NÃO mandem email
	gertrudes@solutti.com.br
	My SPAMTRAP, do not email it

Re: Help on outgoing packet (without NAT)

[Jorge Bastos]

Hi,

> Your rule is absolutely incomplete and nonsense
>
> packet redirections should be done on the NAT table. If no table is
> specified on the command, you'll work on the filter table, which is 
> not
> the one you want here. So '-t nat' is needed.
>
> the '--redirect-to' is not an argument for any of the known targets
> i know .... but as it seems you want to redirect some packet to 
> another
> machine, than you'll probably want the DNAT target. Anyway, you have 
> not
> specified any target, so iptables simply doesnt know what to do.
>
> calling the correct target with correct argument, your rule should
> look something like:
>
> iptables -t nat -I OUTPUT -d 5.5.5.5 -p tcp --dport 80 -j DNAT
> --to-destination 192.168.1.221
>
> no need to specify the :80 port to the destination target. If you
> want to redirect to the same port, you dont need to specify that. You
> would need to specify if you were changing ports.

Well I was convinced that, since I'm not using NAT on this machine, 
this couldn't be done on the NAT table.
Thanks, after all, it works.

Jorge,

Re: Help on outgoing packet (without NAT)

[Jan Engelhardt]

On Thursday 2011-09-22 18:44, Jorge Bastos wrote:

> Hi,
>
>> packet redirections should be done on the NAT table.
>> the '--redirect-to' is not an argument for any of the known targets
>
> Well I was convinced that, since I'm not using NAT on this machine, this
> couldn't be done on the NAT table.
> Thanks, after all, it works.

It can be done without NAT, but if you want to do it without NAT, don't 
use {a NAT target like REDIRECT}, use TPROXY.

Re: Help on outgoing packet (without NAT)

[Leonardo Rodrigues]

Em 22/09/11 13:44, Jorge Bastos escreveu:
>
> Well I was convinced that, since I'm not using NAT on this machine, 
> this couldn't be done on the NAT table.
> Thanks, after all, it works.

     Yes now you're using NAT .... we usually say NAT to some kind of 
SOURCE NAT, for example done on cable/DSL modens. but any kind of 
address translation is a NAT, including your case in which you want to 
change the destination of some packet, usually known as port forwarding. 
Yes it's a NAT, a Destination NAT.

     if i'm not mistaken, just pay attention that as you're using NAT 
and you'll have packets flowing 'through' your machine, you must have the

/proc/sys/net/ipv4/ip_forward

     set to 1

     you also need appropriate FORWARD rules to allow that packets to 
flow through your machine. If you're running with the default FORWARD 
ACCEPT default rule and no rules there, than you'll have no problem. But 
keep in mind that packets are going through filter table, FORWARD chain 
and ip_forward must be enabled for that to work.


-- 


	Atenciosamente / Sincerily,
	Leonardo Rodrigues
	Solutti Tecnologia
	http://www.solutti.com.br

	Minha armadilha de SPAM, NÃO mandem email
	gertrudes@solutti.com.br
	My SPAMTRAP, do not email it