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
