clone packet with new destination address

clone packet with new destination address

[Stephen Clark]

Hello,

Problem:
I have a two monitoring servers behind a a linux firewall, one is 
primary and one is backup.
In the field we have units sending udp informational packet to the 
primary server. On the
linux firewall I would like to copy this packet and change the 
destination address of the copied
packet to point to the backup server. Is there a way to do this without 
writing any code?

NOTE:
Currently the firewall is FreeBSD and we accomplish this rather easily using
ipfw along with natd, but we want to move to linux for our firewall.

Thanks for any ideas,
Steve

-- 

"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety."  (Ben Franklin)

"The course of history shows that as a government grows, liberty
decreases."  (Thomas Jefferson)

Re: clone packet with new destination address

[Changli Gao]

On Fri, Oct 22, 2010 at 8:31 PM, Stephen Clark <sclark46@earthlink.net> wrote:
> Hello,
>
> Problem:
> I have a two monitoring servers behind a a linux firewall, one is primary
> and one is backup.
> In the field we have units sending udp informational packet to the primary
> server. On the
> linux firewall I would like to copy this packet and change the destination
> address of the copied
> packet to point to the backup server. Is there a way to do this without
> writing any code?
>
> NOTE:
> Currently the firewall is FreeBSD and we accomplish this rather easily using
> ipfw along with natd, but we want to move to linux for our firewall.
>

I think you can use tc action mirred to mirror the packets to a fake
NIC device ifb, and use tc action nat to dnat the packets received
from ifb.

-- 
Regards,
Changli Gao(xiaosuo@gmail.com)

Re: clone packet with new destination address

[Changli Gao]

On Fri, Oct 22, 2010 at 9:24 PM, Changli Gao <xiaosuo@gmail.com> wrote:
> On Fri, Oct 22, 2010 at 8:31 PM, Stephen Clark <sclark46@earthlink.net> wrote:
>> Hello,
>>
>> Problem:
>> I have a two monitoring servers behind a a linux firewall, one is primary
>> and one is backup.
>> In the field we have units sending udp informational packet to the primary
>> server. On the
>> linux firewall I would like to copy this packet and change the destination
>> address of the copied
>> packet to point to the backup server. Is there a way to do this without
>> writing any code?
>>
>> NOTE:
>> Currently the firewall is FreeBSD and we accomplish this rather easily using
>> ipfw along with natd, but we want to move to linux for our firewall.
>>
>
> I think you can use tc action mirred to mirror the packets to a fake
> NIC device ifb, and use tc action nat to dnat the packets received
> from ifb.
>

Oh, iptables can also do it. Please see iptables target TEE and RAWNAT
in xtables-addons. http://xtables-addons.sourceforge.net/

-- 
Regards,
Changli Gao(xiaosuo@gmail.com)

Re: clone packet with new destination address

[Stephen Clark]

On 10/22/2010 09:36 AM, Changli Gao wrote:
> On Fri, Oct 22, 2010 at 9:24 PM, Changli Gao<xiaosuo@gmail.com>  wrote:
>    
>> On Fri, Oct 22, 2010 at 8:31 PM, Stephen Clark<sclark46@earthlink.net>  wrote:
>>      
>>> Hello,
>>>
>>> Problem:
>>> I have a two monitoring servers behind a a linux firewall, one is primary
>>> and one is backup.
>>> In the field we have units sending udp informational packet to the primary
>>> server. On the
>>> linux firewall I would like to copy this packet and change the destination
>>> address of the copied
>>> packet to point to the backup server. Is there a way to do this without
>>> writing any code?
>>>
>>> NOTE:
>>> Currently the firewall is FreeBSD and we accomplish this rather easily using
>>> ipfw along with natd, but we want to move to linux for our firewall.
>>>
>>>        
>> I think you can use tc action mirred to mirror the packets to a fake
>> NIC device ifb, and use tc action nat to dnat the packets received
>> from ifb.
>>
>>      
> Oh, iptables can also do it. Please see iptables target TEE and RAWNAT
> in xtables-addons. http://xtables-addons.sourceforge.net/
>
>    
Not to seem dumb - but I tried xtables TEE without any success. Could 
you provide a detailed
example?

Thanks,
Steve

-- 

"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety."  (Ben Franklin)

"The course of history shows that as a government grows, liberty
decreases."  (Thomas Jefferson)

Re: clone packet with new destination address

[Stephen Clark]

On 10/22/2010 09:36 AM, Changli Gao wrote:
> On Fri, Oct 22, 2010 at 9:24 PM, Changli Gao<xiaosuo@gmail.com>  wrote:
>    
>> On Fri, Oct 22, 2010 at 8:31 PM, Stephen Clark<sclark46@earthlink.net>  wrote:
>>      
>>> Hello,
>>>
>>> Problem:
>>> I have a two monitoring servers behind a a linux firewall, one is primary
>>> and one is backup.
>>> In the field we have units sending udp informational packet to the primary
>>> server. On the
>>> linux firewall I would like to copy this packet and change the destination
>>> address of the copied
>>> packet to point to the backup server. Is there a way to do this without
>>> writing any code?
>>>
>>> NOTE:
>>> Currently the firewall is FreeBSD and we accomplish this rather easily using
>>> ipfw along with natd, but we want to move to linux for our firewall.
>>>
>>>        
>> I think you can use tc action mirred to mirror the packets to a fake
>> NIC device ifb, and use tc action nat to dnat the packets received
>> from ifb.
>>
>>      
> Oh, iptables can also do it. Please see iptables target TEE and RAWNAT
> in xtables-addons. http://xtables-addons.sourceforge.net/
>
>    
In testing this it looks like, to me anyhow, that the cloned packet gets
sent to the new gw with the original destination address, so now the
destination address has to get fixed up on the gw, this seems pretty
kludgy to me. Why can't the cloned packet simply have its destination
address replaced with the new destination address? This seems to me
like it would make a lot more sense, instead of having to make changes to
the packet on two different systems.


-- 

"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety."  (Ben Franklin)

"The course of history shows that as a government grows, liberty
decreases."  (Thomas Jefferson)

Re: clone packet with new destination address

[Jan Engelhardt]

On Monday 2010-11-01 13:46, Stephen Clark wrote:
>>
>>Oh, iptables can also do it. Please see iptables target TEE and
>>RAWNAT in xtables-addons. http://xtables-addons.sourceforge.net/
>
>In testing this it looks like, to me anyhow, that the cloned packet
>gets sent to the new gw with the original destination address, so
>now the destination address has to get fixed up on the gw, this
>seems pretty kludgy to me. Why can't the cloned packet simply have
>its destination address replaced with the new destination address?

Because that would incur a loss of information (namely, the
destination address).

>This seems to me like it would make a lot more sense, instead of
>having to make changes to the packet on two different systems.

You can do the changes on a single machine if you want to.

Re: clone packet with new destination address

[Stephen Clark]

On 11/01/2010 09:09 AM, Jan Engelhardt wrote:
> On Monday 2010-11-01 13:46, Stephen Clark wrote:
>    
>>> Oh, iptables can also do it. Please see iptables target TEE and
>>> RAWNAT in xtables-addons. http://xtables-addons.sourceforge.net/
>>>        
>> In testing this it looks like, to me anyhow, that the cloned packet
>> gets sent to the new gw with the original destination address, so
>> now the destination address has to get fixed up on the gw, this
>> seems pretty kludgy to me. Why can't the cloned packet simply have
>> its destination address replaced with the new destination address?
>>      
> Because that would incur a loss of information (namely, the
> destination address).
>
>    
>> This seems to me like it would make a lot more sense, instead of
>> having to make changes to the packet on two different systems.
>>      
> You can do the changes on a single machine if you want to.
>
>    
I am not sure on how to go about doing that, looking at the code for TEE 
it looks
like the cloned packet bypasses any of the remaining iptables chains. So 
where
would I change the destination address? Also if I am mistaken and it 
does hit
one of the remaining iptables chains how do I tell it is not the 
original but the
cloned packet I want to change to the new destination address?

Anyway thanks for your response.

-- 

"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety."  (Ben Franklin)

"The course of history shows that as a government grows, liberty
decreases."  (Thomas Jefferson)

Re: clone packet with new destination address

[Changli Gao]

On Mon, Nov 1, 2010 at 10:29 PM, Stephen Clark <sclark46@earthlink.net> wrote:
>
> I am not sure on how to go about doing that, looking at the code for TEE it
> looks
> like the cloned packet bypasses any of the remaining iptables chains.

It isn't true. The cloned packet only bypasses the iptables rule where
it is generated.

> So
> where
> would I change the destination address? Also if I am mistaken and it does
> hit
> one of the remaining iptables chains how do I tell it is not the original
> but the
> cloned packet I want to change to the new destination address?
>

I think you can use the RAWSNAT xtables-addon to change the
destination address. Since the new skb is attached to untracked ct,
you can use match conntrack --ctstate UNTRACKED to filter it out.

-- 
Regards,
Changli Gao(xiaosuo@gmail.com)

Re: clone packet with new destination address

[Changli Gao]

On Mon, Nov 1, 2010 at 11:00 PM, Changli Gao <xiaosuo@gmail.com> wrote:
> On Mon, Nov 1, 2010 at 10:29 PM, Stephen Clark <sclark46@earthlink.net> wrote:
>>
>> I am not sure on how to go about doing that, looking at the code for TEE it
>> looks
>> like the cloned packet bypasses any of the remaining iptables chains.
>
> It isn't true. The cloned packet only bypasses the iptables rule where
> it is generated.
>
>> So
>> where
>> would I change the destination address? Also if I am mistaken and it does
>> hit
>> one of the remaining iptables chains how do I tell it is not the original
>> but the
>> cloned packet I want to change to the new destination address?
>>
>
> I think you can use the RAWSNAT xtables-addon to change the
> destination address. Since the new skb is attached to untracked ct,
> you can use match conntrack --ctstate UNTRACKED to filter it out.
>

s/SNAT/DNAT/g .

-- 
Regards,
Changli Gao(xiaosuo@gmail.com)

Re: clone packet with new destination address

[Stephen Clark]

On 11/01/2010 11:00 AM, Changli Gao wrote:
> On Mon, Nov 1, 2010 at 10:29 PM, Stephen Clark<sclark46@earthlink.net>  wrote:
>    
>> I am not sure on how to go about doing that, looking at the code for TEE it
>> looks
>> like the cloned packet bypasses any of the remaining iptables chains.
>>      
> It isn't true. The cloned packet only bypasses the iptables rule where
> it is generated.
>
>    
>> So
>> where
>> would I change the destination address? Also if I am mistaken and it does
>> hit
>> one of the remaining iptables chains how do I tell it is not the original
>> but the
>> cloned packet I want to change to the new destination address?
>>
>>      
> I think you can use the RAWSNAT xtables-addon to change the
> destination address. Since the new skb is attached to untracked ct,
> you can use match conntrack --ctstate UNTRACKED to filter it out.
>
>    
Hi Changli,

Thank you very much for the reply, But wouldn't it be RAWDNAT since  I 
want to
change the destination address?

Steve

-- 

"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety."  (Ben Franklin)

"The course of history shows that as a government grows, liberty
decreases."  (Thomas Jefferson)

Re: clone packet with new destination address

[Jan Engelhardt]

On Monday 2010-11-01 16:00, Changli Gao wrote:

>On Mon, Nov 1, 2010 at 10:29 PM, Stephen Clark <sclark46@earthlink.net> wrote:
>>
>> I am not sure on how to go about doing that, looking at the code for TEE it
>> looks
>> like the cloned packet bypasses any of the remaining iptables chains.
>
>It isn't true. The cloned packet only bypasses the iptables rule where
>it is generated.

That isn't true either. The cloned packet starts its travel in OUTPUT, 
not where it left off.

>I think you can use the RAWSNAT xtables-addon to change the
>destination address. Since the new skb is attached to untracked ct,
>you can use match conntrack --ctstate UNTRACKED to filter it out.

That may still give false positives if there is other NOTRACK traffic.

Re: clone packet with new destination address

[Jan Engelhardt]

On Monday 2010-11-01 15:29, Stephen Clark wrote:
> On 11/01/2010 09:09 AM, Jan Engelhardt wrote:
>>
>>> This seems to me like it would make a lot more sense, instead of
>>> having to make changes to the packet on two different systems.
>>
>> You can do the changes on a single machine if you want to.
>  
>I am not sure on how to go about doing that, looking at the code for
>TEE it looks like the cloned packet bypasses any of the remaining
>iptables chains. So where would I change the destination address?

Right. You need a kernel >= 2.6.35 (xt_TEE is included)
for cloned packets to go through the tables again.

>Also if I am mistaken and it does hit one of the remaining iptables
>chains how do I tell it is not the original but the cloned packet I
>want to change to the new destination address?

Good question. Given the possibilities I think an extra route towards
the logging server that specifies a realm value, that is then
matchable in -A OUTPUT -m realm, is in order.

Re: clone packet with new destination address

[Stephen Clark]

On 11/01/2010 03:29 PM, Jan Engelhardt wrote:
> On Monday 2010-11-01 15:29, Stephen Clark wrote:
>    
>> On 11/01/2010 09:09 AM, Jan Engelhardt wrote:
>>      
>>>        
>>>> This seems to me like it would make a lot more sense, instead of
>>>> having to make changes to the packet on two different systems.
>>>>          
>>> You can do the changes on a single machine if you want to.
>>>        
>>
>> I am not sure on how to go about doing that, looking at the code for
>> TEE it looks like the cloned packet bypasses any of the remaining
>> iptables chains. So where would I change the destination address?
>>      
> Right. You need a kernel>= 2.6.35 (xt_TEE is included)
> for cloned packets to go through the tables again.
>
>    
>> Also if I am mistaken and it does hit one of the remaining iptables
>> chains how do I tell it is not the original but the cloned packet I
>> want to change to the new destination address?
>>      
> Good question. Given the possibilities I think an extra route towards
> the logging server that specifies a realm value, that is then
> matchable in -A OUTPUT -m realm, is in order.
>
>    
Hmm...,

Sounds like maybe an easier way to do this is to use libipq and the 
QUEUE target to
select the packets of interest - then make a copy of the packet in 
userspace and
use a raw socket to send the copy with the new destination address on 
its way.

Does this sound reasonable?

-- 

"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety."  (Ben Franklin)

"The course of history shows that as a government grows, liberty
decreases."  (Thomas Jefferson)

Re: clone packet with new destination address

[Jan Engelhardt]

On Tuesday 2010-11-02 14:44, Stephen Clark wrote:
>>   
>>> Also if I am mistaken and it does hit one of the remaining iptables
>>> chains how do I tell it is not the original but the cloned packet I
>>> want to change to the new destination address?
>>>     
>> Good question. Given the possibilities I think an extra route towards
>> the logging server that specifies a realm value, that is then
>> matchable in -A OUTPUT -m realm, is in order.
>>   
> Hmm...,
>
> Sounds like maybe an easier way to do this is to use libipq and the
> QUEUE target to select the packets of interest - then make a copy
> of the packet in userspace and use a raw socket to send the copy
> with the new destination address on its way.
>
> Does this sound reasonable?

The roundtrip over userspace sounds unnecessarily imperformant.

Re: clone packet with new destination address

[Stephen Clark]

On 11/02/2010 09:46 AM, Jan Engelhardt wrote:
> On Tuesday 2010-11-02 14:44, Stephen Clark wrote:
>    
>>>
>>>        
>>>> Also if I am mistaken and it does hit one of the remaining iptables
>>>> chains how do I tell it is not the original but the cloned packet I
>>>> want to change to the new destination address?
>>>>
>>>>          
>>> Good question. Given the possibilities I think an extra route towards
>>> the logging server that specifies a realm value, that is then
>>> matchable in -A OUTPUT -m realm, is in order.
>>>
>>>        
>> Hmm...,
>>
>> Sounds like maybe an easier way to do this is to use libipq and the
>> QUEUE target to select the packets of interest - then make a copy
>> of the packet in userspace and use a raw socket to send the copy
>> with the new destination address on its way.
>>
>> Does this sound reasonable?
>>      
> The roundtrip over userspace sounds unnecessarily imperformant.
>
>    
I would agree but it keeps me from being dependent on a particular 
kernel version
and we are only concerned with less than 10 packets per second.

-- 

"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety."  (Ben Franklin)

"The course of history shows that as a government grows, liberty
decreases."  (Thomas Jefferson)

Re: clone packet with new destination address

[Changli Gao]

On Tue, Nov 2, 2010 at 9:44 PM, Stephen Clark <sclark46@earthlink.net> wrote:
>
> Hmm...,
>
> Sounds like maybe an easier way to do this is to use libipq and the QUEUE
> target to
> select the packets of interest - then make a copy of the packet in userspace
> and
> use a raw socket to send the copy with the new destination address on its
> way.
>
> Does this sound reasonable?

Oh, I think NFLOG will be better, or libpcap & libnet, if you want to
implement this function in user space, because it doesn't delay the
original packets as NFQUEUE does.

-- 
Regards,
Changli Gao(xiaosuo@gmail.com)