Ah!!!!
Noa, in my humble opinion, you *must* assign new addresses to the internal
networks. You may will live a routing nightmare if you decides stay with
the
actual address assignment.
Best regards,
Jorge Davila.
On Wed, 6 Jun 2007 02:05:53 +0300
"noa levy" <noalevy@xxxxxxxxx> wrote:
> The situation here is that several geographically diverse parts of the
> network (several branches of the same company) use the same internal
> addressing space. This was done to make it easy to centrally configure
> the branches. As a result, however, when talking to the center via
> VPN, we have to map each branch's network to another network allocated
> by the center.
>
> Noa
>
> On 6/6/07, Jorge Davila <davila@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
>> Uhm ... well, may another approach works.
>>
>> But, why reports another source IP address to the remote internal
>>network???
>>
>> Jorge Davila.
>>
>> On Wed, 6 Jun 2007 01:40:34 +0300
>> "noa levy" <noalevy@xxxxxxxxx> wrote:
>> > Yes, I want to change the source IP address of the original IP packet
>> > before encryption.
>> >
>> > On 6/6/07, Jorge Davila <davila@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
>> >> OK - Let me now if I'm wrong ...
>> >>
>> >> Are you trying to modify the source address of the packet before the
>> >>packet
>> >> gets encryption?
>> >>
>> >> Jorge.
>> >>
>> >> On Wed, 6 Jun 2007 00:29:51 +0300
>> >> "noa levy" <noalevy@xxxxxxxxx> wrote:
>> >> > Thanks for all the help so far.
>> >> > Jorge - I'm actually using the native 2.6 kernel ipsec (netkey)
and
>> >> > not KLIPS, so I don't have the "ipsecN" virtual interfaces and
can't
>> >> > use that.
>> >> > In response to Grant's reply - I think I have a problem, since I'm
>> >> > using the 2.6.10 kernel (can't upgrade anytime soon). Can anyone
>>point
>> >> > me to where I can find the relevant ipsec patches that enable the
>> >> > double passage through netfilter hooks?
>> >> > Thanks,
>> >> > Noa
>> >> >
>> >> > On 6/5/07, Jorge Davila <davila@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
>> >> >> I'm guessing that you can use the "normal" approach and apply the
>>SNAT
>> >> >>rules
>> >> >> to the outgoing traffic flowing in the ipsec interfaces.
>> >> >>
>> >> >> The ipsec encryption algorithm is a kernel space tool and
iptables
>>is a
>> >> >>user
>> >> >> space tool to the netfilter kernel module.
>> >> >>
>> >> >> All traffic that pass the POSTROUTING chain in the NAT table is
>>leaving
>> >> >>the
>> >> >> firewall box (through a physical interface e.g.:eth0 or through a
>> >>virtual
>> >> >> interface e.g.:ipsec0).
>> >> >>
>> >> >> Jorge Davila..
>> >> >>
>> >> >> On Tue, 5 Jun 2007 15:29:47 +0300
>> >> >> "noa levy" <noalevy@xxxxxxxxx> wrote:
>> >> >> > Hi All,
>> >> >> >
>> >> >> > I have a setup where I need to SNAT traffic that will be going
out
>> >>via
>> >> >> > an IPSec tunnel. The NAT must take place before the IPSec
>> >> >> > encryption+encapsulation, so I need the packet to first go
through
>> >> >> > SNAT and then match an IPSec policy. After being IPSec-ified, I
>>need
>> >> >> > the packets to go through routing again.
>> >> >> > My question:
>> >> >> > SNAT takes place in POST_ROUTING. Can IPSec be applied after
that?
>>I
>> >> >> > have read that after IPSec the packet gets injected to
LOCAL_OUT
>> >> >> > again, but when does the actual IPSec policy decision take
place?
>> >> >> > Won't it happen *before* SNAT? Can I control it?
>> >> >> >
>> >> >> > Thanks,
>> >> >> > Noa
>> >> >> >
>> >> >> >
>> >> >>
>> >> >> Jorge Isaac Davila Lopez
>> >> >> Nicaragua Open Source
>> >> >> +505 430 5462
>> >> >> davila@xxxxxxxxxxxxxxxxxxxxxxx
>> >> >>
>> >> >
>> >>
>> >> Jorge Isaac Davila Lopez
>> >> Nicaragua Open Source
>> >> +505 430 5462
>> >> davila@xxxxxxxxxxxxxxxxxxxxxxx
>> >>
>> >
>>
>> Jorge Isaac Davila Lopez
>> Nicaragua Open Source
>> +505 430 5462
>> davila@xxxxxxxxxxxxxxxxxxxxxxx
>>
>
Jorge Isaac Davila Lopez
Nicaragua Open Source
+505 430 5462
davila@xxxxxxxxxxxxxxxxxxxxxxx
