dnat problem in transparent firewall

dnat problem in transparent firewall

[Raido Kurel]

Hello!

I want to change destination ip in incoming packets. If someone has time to 
answer, read on... In OpenBSD it worked automatically in same hardware 
configuration, just
rdr on xl0 from any to aaa.aaa.aaa.12 -> aaa.aaa.aaa.13
to /etc/pf.rules and thats all.

Configuration:
|LAN|---|ROUTER|---|TRANSPARENT FIREWALL|--|INTERNET GATEWAY|
LAN network: aaa.aaa.aaa.xxx/24
|ROUTER|: integrated into LAN switch
|TRANSPARENT FIREWALL|: a Linux 2.6.x box with iptables 1.2.9
ebtables 2.0.6. without IP's on traffic interfaces br0=eth1+eth2

router-internet gateway network: aaa.aaa.bbb.cdx/31

Needs:
To change destination IP of some packets coming from Internet. ie to change 
dastination IP from aaa.aaa.aaa.12 to aaa.aaa.aaa.13

What I have done:
iptables rule:

iptables -t nat -A PREROUTING -d aaa.aaa.aaa.12 -j DNAT --to-dest 
aaa.aaa.aaa.13

I thought, that this should do it, but it is not working. If I add this rule, 
the incoming packet is dropped in this rule.
For example:

if I log traffic and then change destination ip, I see traffic:

iptables -t nat -A PREROUTING -j LOG
iptables -t nat -A PREROUTING -d aaa.aaa.aaa.12 -j DNAT --to-dest 
aaa.aaa.aaa.13

If I try to change destination IP and then log, I do not see traffic:

iptables -t nat -A PREROUTING -d aaa.aaa.aaa.12 -j DNAT --to-dest 
aaa.aaa.aaa.13
iptables -t nat -A PREROUTING -j LOG

Seems like destination ip rule swollows packet. What could be wrong or is 
there other means to acomplish what I need?

Thanks,
Raido

Re: dnat problem in transparent firewall

[Antony Stone]

On Tuesday 03 August 2004 12:36 pm, Raido Kurel wrote:

> Hello!
>
> I want to change destination ip in incoming packets.
>
> Needs:
> To change destination IP of some packets coming from Internet. ie to change
> dastination IP from aaa.aaa.aaa.12 to aaa.aaa.aaa.13
>
> What I have done:
> iptables rule:
>
> iptables -t nat -A PREROUTING -d aaa.aaa.aaa.12 -j DNAT --to-dest
> aaa.aaa.aaa.13

Do you have a FORWARD rule allowing packets through to aaa.aaa.aaa.13 after 
they've been NATted?

Antony.

-- 
Normal people think "If it ain't broke, don't fix it".
Engineers think "If it ain't broke, it doesn't have enough features yet".

                                                     Please reply to the list;
                                                           please don't CC me.

dnat problem in transparent firewall

[Raido Kurel]

Sorry, about not beeing in the thread. I just subscribed and can see message 
just in archive...

> > Needs:
> > To change destination IP of some packets coming from Internet. ie to
> > change destination IP from aaa.aaa.aaa.12 to aaa.aaa.aaa.13
...
> > iptables -t nat -A PREROUTING -d aaa.aaa.aaa.12 -j DNAT --to-dest
> > aaa.aaa.aaa.13
>
> Do you have a FORWARD rule allowing packets through to aaa.aaa.aaa.13 after 
> they've been NATted?

Yes.
Also packets from Internet to aaa.aaa.aaa.13 reach destination.
I am more worried about fact, that 
-t nat -A PREROUTING -j DNAT ...
and then 
-t nat -A PREROUTING -j LOG ...
does not log anything. Without the first rule logging works. 
I thought, that -j DNAT should pass packet for next nat PREROUTING rule for 
logging. According to http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png 
packet should next go to ebtables filter table input or forward chains, but 
nothing reaches there in case of the iptables -t nat -A PREROUTING -j DNAT 
rule.

Raido

Re: dnat problem in transparent firewall

[Antony Stone]

On Wednesday 04 August 2004 8:10 am, Raido Kurel wrote:

> > Do you have a FORWARD rule allowing packets through to aaa.aaa.aaa.13
> > after they've been NATted?
>
> Yes.
> Also packets from Internet to aaa.aaa.aaa.13 reach destination.
> I am more worried about fact, that
> -t nat -A PREROUTING -j DNAT ...
> and then
> -t nat -A PREROUTING -j LOG ...
> does not log anything. Without the first rule logging works.

That's because the DNAT target does not return to the chain.   The LOG target 
is almost the only target I can think of which *does* return back to the 
chain for further processing - all other targets are the "final outcome" for 
the packet.

Put the two rules the other way round and you'll get both LOGging and 
DNATting.

Regards,

Antony.

-- 
Most people are aware that the Universe is big.

 - Paul Davies, Professor of Theoretical Physics

                                                     Please reply to the list;
                                                           please don't CC me.

Re: dnat problem in transparent firewall

[Raido Kurel]

> That's because the DNAT target does not return to the chain.   The LOG
> target is almost the only target I can think of which *does* return back to
> the chain for further processing - all other targets are the "final
> outcome" for the packet.
>
> Put the two rules the other way round and you'll get both LOGging and
> DNATting.

Thanks, I have been missed that. Now I can ask my question in other words:

I presume, that http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png is 
correct.

According to this picture, my packets should flow in lowest path.
To be sure it is so, I have made rules to log incoming packet in 3 points:
a)iptables nat table prerouting chain 
b)ebtables filter table forward chain
c)iptables mangle table forward chain 
d)ebtables filter table input chain

I try to connect fron Internet to aaa.aaa.aaa.12

In case of rule:
iptables -t nat -A PREROUTING -d aaa.aaa.aaa.12 -j DNAT --to-dest 
aaa.aaa.aaa.13

I see packet only in point a)

In case of no rule or rule
iptables -t nat -A PREROUTING -d aaa.aaa.aaa.12 -j DNAT --to-dest 
aaa.aaa.aaa.12

I see packet in a), b) and c) points.

I see also packet in a), b) and c) points if I connect from internet to 
aaa.aaa.aaa.13

It's just like DNAT rule drops packet, but it can't be, because DNAT to the 
same address works fine. I know I have missed something important, but what 
could it be?

Raido

Re: dnat problem in transparent firewall

[Antony Stone]

On Wednesday 04 August 2004 12:14 pm, Raido Kurel wrote:

> > That's because the DNAT target does not return to the chain.   The LOG
> > target is almost the only target I can think of which *does* return back
> > to the chain for further processing - all other targets are the "final
> > outcome" for the packet.
> >
> > Put the two rules the other way round and you'll get both LOGging and
> > DNATting.
>
> Thanks, I have been missed that. Now I can ask my question in other words:
>
> I presume, that http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png is
> correct.
>
> According to this picture, my packets should flow in lowest path.
> To be sure it is so, I have made rules to log incoming packet in 3 points:
> a)iptables nat table prerouting chain
> b)ebtables filter table forward chain
> c)iptables mangle table forward chain
> d)ebtables filter table input chain
>
> I try to connect fron Internet to aaa.aaa.aaa.12
>
> In case of rule:
> iptables -t nat -A PREROUTING -d aaa.aaa.aaa.12 -j DNAT --to-dest
> aaa.aaa.aaa.13
>
> I see packet only in point a)
>
> In case of no rule or rule
> iptables -t nat -A PREROUTING -d aaa.aaa.aaa.12 -j DNAT --to-dest
> aaa.aaa.aaa.12
>
> I see packet in a), b) and c) points.
>
> I see also packet in a), b) and c) points if I connect from internet to
> aaa.aaa.aaa.13
>
> It's just like DNAT rule drops packet, but it can't be, because DNAT to the
> same address works fine. I know I have missed something important, but what
> could it be?

What do your LOGging rules say?   Is it possible that you are trying to LOG 
packets addressed to aaa.aaa.aaa.12, and therefore the rules no longer see 
the packets once the address has been changed to aaa.aaa.aaa.13?

Regards,

Antony.

-- 
I don't know, maybe if we all waited then cosmic rays would write all our 
software for us. Of course it might take a while.

 - Ron Minnich, Los Alamos National Laboratory

                                                     Please reply to the list;
                                                           please don't CC me.

Re: dnat problem in transparent firewall

[Raido Kurel]

> What do your LOGging rules say?   Is it possible that you are trying to LOG
> packets addressed to aaa.aaa.aaa.12, and therefore the rules no longer see
> the packets once the address has been changed to aaa.aaa.aaa.13?

That's a good point. I checket it also over several times.
Thats why I also tested and wrote, that I see packets if I try to connect to 
aaa.aaa.aaa.13

I added 2 logging rules for every logging point from a) to d).
For example exact logging rules for a) are :
iptables -t nat -A PREROUTING -s nnn.nnn.nnn.nnn -d aaa.aaa.aaa.12 -j LOG 
--log-prefix " ipt nat pre "
iptables -t nat -A PREROUTING -s nnn.nnn.nnn.nnn -d aaa.aaa.aaa.13 -j LOG 
--log-prefix " ipt nat pre "

where nnn.nnn.nnn.nnn is a computer from where I connect behind other ISP.

It should not be relevant, but the port I try to connect for testing right now 
is ssh. I try to connect with telnet aaa.aaa.aaa.12 22.
both .12 and .13 have ssh servers up and running.

Raido