SNAT before IPSec

SNAT before IPSec

[noa levy]

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

Re: SNAT before IPSec

[Yasuyuki KOZAKAI]

From: "noa levy" <noalevy@gmail.com>
Date: Tue, 5 Jun 2007 15:29:47 +0300

> 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?

Yes. mangling addresses in packets at POST_ROUTING results in re-lookup
policy and re-routing. Then what you need is to configure policy with the
address mangled by SNAT.

>                                                                    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?

If you don't configure any policy matching packets before SNAT, no policy
is applied at the time, of cause.

-- Yasuyuki Kozakai

Re: SNAT before IPSec

[Grant Taylor]

On 06/05/07 07:29, noa levy wrote:
> 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?

Last I looked (it's been a while) the basic methodology at the time was 
that (unencrypted) traffic would pass through the kernel like regular 
traffic.  Then after everything else was done it would be encrypted and 
looped back through the system in its encrypted form.  So what you would 
do is selectively do what ever you wanted to do to the traffic before it 
was encrypted by matching that traffic with filters.  In short, do what 
ever you want to with the clear text traffic, then do what ever you want 
with cypher text traffic.

There use to be a series of patches that needed to be applied to the 
kernel to make this packet flow possible.  I do not know if these 
patches are still required or not, though I would expect it to be main 
line by now.

Can / will any one confirm / refute this please?



Grant. . . .

Re: SNAT before IPSec

[Jorge Davila]

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@gmail.com> 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@nicaraguaopensource.com

Re: SNAT before IPSec

[Grant Taylor]

On 06/05/07 15:15, Jorge Davila 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.

...

> 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).

Um, correct me if I'm wrong, but not all IPSec implementations create an 
interface any more.



Grant. . . .

Re: SNAT before IPSec

[Jorge Davila]

Well Grant, the IPSec standard [1] said:

For every IPsec implementation, there MUST be an administrative
    interface that allows a user or system administrator to manage the
    SPD.  Specifically, every inbound or outbound packet is subject to
    processing by IPsec and the SPD must specify what action will be
    taken in each case.  Thus the administrative interface must allow the
    user (or system administrator) to specify the security processing to
    be applied to any packet entering or exiting the system, on a packet
    by packet basis.

Best regards,

Jorge Davila.

[1] http://www.ietf.org/rfc/rfc2401.txt
On Tue, 05 Jun 2007 15:28:33 -0500
  Grant Taylor <gtaylor@riverviewtech.net> wrote:
> On 06/05/07 15:15, Jorge Davila 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.
> 
> ...
> 
>> 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).
> 
> Um, correct me if I'm wrong, but not all IPSec implementations create an 
>interface any more.
> 
> 
> 
> Grant. . . .
> 
> 

Jorge Isaac Davila Lopez
Nicaragua Open Source
+505 430 5462
davila@nicaraguaopensource.com

Re: SNAT before IPSec

[Grant Taylor]

On 6/5/2007 3:45 PM, Jorge Davila wrote:
> For every IPsec implementation, there MUST be an administrative 
> interface that allows a user or system administrator to manage the 
> SPD.  Specifically, every inbound or outbound packet is subject to 
> processing by IPsec and the SPD must specify what action will be 
> taken in each case.  Thus the administrative interface must allow the 
> user (or system administrator) to specify the security processing to 
> be applied to any packet entering or exiting the system, on a packet 
> by packet basis.

I take this to mean some sort of management point, not necissarily a 
network interface managed by ifconfig.  Or did I misunderstand your 
earlier comment to mean the management point?



Grant. . . .

Re: SNAT before IPSec

[Jorge Davila]

Grant,

to be honest, reading, re-reading before the rfc the same doubt come to my 
mind but now, my understanding is that the paragraph is really doing 
reference to an interface to manage the traffic according to the policies 
defined.

Jorge Davila.

On Tue, 05 Jun 2007 18:53:33 -0500
  Grant Taylor <gtaylor@riverviewtech.net> wrote:
> On 6/5/2007 3:45 PM, Jorge Davila wrote:
>> For every IPsec implementation, there MUST be an administrative 
>> interface that allows a user or system administrator to manage the 
>> SPD.  Specifically, every inbound or outbound packet is subject to 
>> processing by IPsec and the SPD must specify what action will be 
>> taken in each case.  Thus the administrative interface must allow the 
>> user (or system administrator) to specify the security processing to 
>> be applied to any packet entering or exiting the system, on a packet 
>> by packet basis.
> 
> I take this to mean some sort of management point, not necissarily a 
>network interface managed by ifconfig.  Or did I misunderstand your earlier 
>comment to mean the management point?
> 
> 
> 
> Grant. . . .
> 
> 

Jorge Isaac Davila Lopez
Nicaragua Open Source
+505 430 5462
davila@nicaraguaopensource.com

Re: SNAT before IPSec

[Grant Taylor]

On 06/06/07 10:39, Jorge Davila wrote:
> to be honest, reading, re-reading before the rfc the same doubt come 
> to my mind but now, my understanding is that the paragraph is really 
> doing reference to an interface to manage the traffic according to 
> the policies defined.

*nod*

I think the reason that network interfaces stopped being created was in 
preparation for MANY IPSec connections, enough so that creating network 
interfaces would just be a waste.  If I recall correctly the IPSec 
people were wanting and hoping to start seeing IPSec used arbitrarily 
any time that it could be used, including accessing web pages off of web 
servers.  In this case, creating and removing interfaces is just (IMHO) 
ridiculing.



Grant. . . .

Re: SNAT before IPSec

[noa levy]

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@nicaraguaopensource.com> 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@gmail.com> 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@nicaraguaopensource.com
>

Re: SNAT before IPSec

[Jorge Davila]

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@gmail.com> 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@nicaraguaopensource.com> 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@gmail.com> 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@nicaraguaopensource.com
>>
> 

Jorge Isaac Davila Lopez
Nicaragua Open Source
+505 430 5462
davila@nicaraguaopensource.com

Re: SNAT before IPSec

[noa levy]

Yes, I want to change the source IP address of the original IP packet
before encryption.

On 6/6/07, Jorge Davila <davila@nicaraguaopensource.com> 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@gmail.com> 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@nicaraguaopensource.com> 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@gmail.com> 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@nicaraguaopensource.com
> >>
> >
>
> Jorge Isaac Davila Lopez
> Nicaragua Open Source
> +505 430 5462
> davila@nicaraguaopensource.com
>

Re: SNAT before IPSec

[Jorge Davila]

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@gmail.com> wrote:
> Yes, I want to change the source IP address of the original IP packet
> before encryption.
> 
> On 6/6/07, Jorge Davila <davila@nicaraguaopensource.com> 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@gmail.com> 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@nicaraguaopensource.com> 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@gmail.com> 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@nicaraguaopensource.com
>> >>
>> >
>>
>> Jorge Isaac Davila Lopez
>> Nicaragua Open Source
>> +505 430 5462
>> davila@nicaraguaopensource.com
>>
> 

Jorge Isaac Davila Lopez
Nicaragua Open Source
+505 430 5462
davila@nicaraguaopensource.com

Re: SNAT before IPSec

[noa levy]

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@nicaraguaopensource.com> 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@gmail.com> wrote:
> > Yes, I want to change the source IP address of the original IP packet
> > before encryption.
> >
> > On 6/6/07, Jorge Davila <davila@nicaraguaopensource.com> 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@gmail.com> 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@nicaraguaopensource.com> 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@gmail.com> 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@nicaraguaopensource.com
> >> >>
> >> >
> >>
> >> Jorge Isaac Davila Lopez
> >> Nicaragua Open Source
> >> +505 430 5462
> >> davila@nicaraguaopensource.com
> >>
> >
>
> Jorge Isaac Davila Lopez
> Nicaragua Open Source
> +505 430 5462
> davila@nicaraguaopensource.com
>

Re: SNAT before IPSec

[Jorge Davila]

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@gmail.com> 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@nicaraguaopensource.com> 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@gmail.com> wrote:
>> > Yes, I want to change the source IP address of the original IP packet
>> > before encryption.
>> >
>> > On 6/6/07, Jorge Davila <davila@nicaraguaopensource.com> 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@gmail.com> 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@nicaraguaopensource.com> 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@gmail.com> 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@nicaraguaopensource.com
>> >> >>
>> >> >
>> >>
>> >> Jorge Isaac Davila Lopez
>> >> Nicaragua Open Source
>> >> +505 430 5462
>> >> davila@nicaraguaopensource.com
>> >>
>> >
>>
>> Jorge Isaac Davila Lopez
>> Nicaragua Open Source
>> +505 430 5462
>> davila@nicaraguaopensource.com
>>
> 

Jorge Isaac Davila Lopez
Nicaragua Open Source
+505 430 5462
davila@nicaraguaopensource.com

Re: SNAT before IPSec

[noa levy]

Well, I agree with you in principle, but it's been this way for years,
so routing practices are in place to handle it. I'm trying to recreate
the setup we have now, which is using commercial VPN gateways, with
Linux-based ones, but the addressing scheme is a given, I have no
control over it

On 6/6/07, Jorge Davila <davila@nicaraguaopensource.com> wrote:
> 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@gmail.com> 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@nicaraguaopensource.com> 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@gmail.com> wrote:
> >> > Yes, I want to change the source IP address of the original IP packet
> >> > before encryption.
> >> >
> >> > On 6/6/07, Jorge Davila <davila@nicaraguaopensource.com> 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@gmail.com> 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@nicaraguaopensource.com> 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@gmail.com> 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@nicaraguaopensource.com
> >> >> >>
> >> >> >
> >> >>
> >> >> Jorge Isaac Davila Lopez
> >> >> Nicaragua Open Source
> >> >> +505 430 5462
> >> >> davila@nicaraguaopensource.com
> >> >>
> >> >
> >>
> >> Jorge Isaac Davila Lopez
> >> Nicaragua Open Source
> >> +505 430 5462
> >> davila@nicaraguaopensource.com
> >>
> >
>
> Jorge Isaac Davila Lopez
> Nicaragua Open Source
> +505 430 5462
> davila@nicaraguaopensource.com
>

Re: SNAT before IPSec

[Jorge Davila]

Noa,

What can I tell you? You are on your own way ....

My last suggest is use OpenVPN and IPSec.

Best regards,

Jorge Davila.

On Thu, 7 Jun 2007 18:40:35 +0300
  "noa levy" <noalevy@gmail.com> wrote:
> Well, I agree with you in principle, but it's been this way for years,
> so routing practices are in place to handle it. I'm trying to recreate
> the setup we have now, which is using commercial VPN gateways, with
> Linux-based ones, but the addressing scheme is a given, I have no
> control over it
> 
> On 6/6/07, Jorge Davila <davila@nicaraguaopensource.com> wrote:
>> 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@gmail.com> 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@nicaraguaopensource.com> 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@gmail.com> wrote:
>> >> > Yes, I want to change the source IP address of the original IP packet
>> >> > before encryption.
>> >> >
>> >> > On 6/6/07, Jorge Davila <davila@nicaraguaopensource.com> 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@gmail.com> 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@nicaraguaopensource.com> 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@gmail.com> 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@nicaraguaopensource.com
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >> Jorge Isaac Davila Lopez
>> >> >> Nicaragua Open Source
>> >> >> +505 430 5462
>> >> >> davila@nicaraguaopensource.com
>> >> >>
>> >> >
>> >>
>> >> Jorge Isaac Davila Lopez
>> >> Nicaragua Open Source
>> >> +505 430 5462
>> >> davila@nicaraguaopensource.com
>> >>
>> >
>>
>> Jorge Isaac Davila Lopez
>> Nicaragua Open Source
>> +505 430 5462
>> davila@nicaraguaopensource.com
>>
> 

Jorge Isaac Davila Lopez
Nicaragua Open Source
+505 430 5462
davila@nicaraguaopensource.com

Re: SNAT before IPSec

[Grant Taylor]

On 06/07/07 10:40, noa levy wrote:
> Well, I agree with you in principle, but it's been this way for 
> years, so routing practices are in place to handle it. I'm trying to 
> recreate the setup we have now, which is using commercial VPN 
> gateways, with Linux-based ones, but the addressing scheme is a 
> given, I have no control over it.

Ah, you have a "Double NAT scenario".  What fun.

In short, you have two networks with the same subnet A.B.C.x/24 that 
need to talk to each other.  So, you make each network think that the 
other is D.E.F.x/24.  This way, either network can reach the other 
network by using the D.E.F.x/24 addresses.

Traditionally, double NAT is done on two different systems b/c of 
conflicts.  However I suspect that it could be done on one system with 
multiple routing tables.  I'll have to think on this as to how to 
possibly make this happen.  I'd need you to do some testing on your end 
to let me know if it would work or not as I don't have a test bed that 
will encompasses this at present.

With the traditional double nat, you have a fake subnet that is remapped 
in to the local network.  The routers know how to get between each other 
using the fake network.

A.B.C.x/24 <router A> --- (vpn) --- <router B> A.B.C.x/24

Router A thinks that D.E.F.x/24 is available via router B.
Router B thinks that D.E.F.x/24 is available via router A.

Both router A and router B do a network map to translate any incoming 
traffic destined to D.E.F.x/24 to A.B.C.x/24.  Thus when any traffic 
comes in to either router from A.B.C.9 destined to D.E.F.3, it DNATs the 
traffic down to A.B.C.3 AND SNATs the traffic up to D.E.F.9.  Thus the 
real receiving host will see traffic from D.E.F.9 to A.B.C.3.  With the 
real receiving host having what it thinks to be valid source and 
destination IPs, it can communicate just like normal.  When the real 
receiving host replies to the real sending host, the traffic goes out to 
D.E.F.9.  Then the other router will see traffic coming in from A.B.C.3 
to D.E.F.9 it will DNAT the traffic to be to A.B.C.9 and SNAT the 
traffic to be from D.E.F.3.  Notice how we now have a complete 
by-directional route between two very different subnets that share the 
same subnet address space?  Interesting isn't it?  Complex though as it 
is, it does work and is done a LOT.

See if this helps you at all.

Seeing as how your subnets were suppose to be set up identically I'm 
going to presume that servers and routers on the subnets have the same 
IP addresses.  Thus, you would probably be able to get away using NETMAP 
target.  I.e.

iptables -t nat -A PREROUTING -i $WAN -d D.E.F.x/24 -j NETMAP --to 
A.B.C.x/24
iptables -t nat -A POSTROUTING -o $LAN -s A.B.C.x/24 -j NETMAP --to 
D.E.F.x/24

This should cause the NETMAPing to happen at the remote end of the vpn 
link and (hopefully) not confuse the router at the local end of the vpn 
link.



Grant. . . .

P.S.  I said "fun right???".  :0

Re: SNAT before IPSec

[Grant Taylor]

On 06/07/07 12:07, Grant Taylor wrote:
> iptables -t nat -A PREROUTING -i $WAN -d D.E.F.x/24 -j NETMAP --to 
> A.B.C.x/24
> iptables -t nat -A POSTROUTING -o $LAN -s A.B.C.x/24 -j NETMAP --to 
> D.E.F.x/24
> 
> This should cause the NETMAPing to happen at the remote end of the vpn 
> link and (hopefully) not confuse the router at the local end of the vpn 
> link.

I've done some more thinking and I think it would be better to do the SNAT at the local end of the vpn link.  Doing the SNAT on the remote end will work, but it is not as scalable as doing it on the local end.

If you consider your situation where you have multiple networks (3 or more) that are all the same subnet that you want to tie together, you have to SNAT and DNAT for each network.  DNATing should be done at the remove end to change from the bogus address to the real address.  If SNATing is done at the remove end, the remote end will have to have rules for each and every other network to know what to SNAT to.  If SNATing is done at the local end, the local router knows what to SNAT to and the remote end will just DNAT and reply.  So a slightly modified version of the above rules would be:

iptables -t nat -A PREROUTING -i $WAN -d D.E.F.x/24 -j NETMAP --to A.B.C.x/24
iptables -t nat -A POSTROUTING -o $WAN -d D.E.N.x/16 -j NETMAP --to D.E.M.x/24

Where D.E.N.x/16 is the larger class B that encompasses all remote networks.  I.e. selectively SNAT only when you are going to a remote network.

Where D.E.M.x/24 is the local bogus network.

This *SHOULD* allow you to have two rules on each system to allow all of them to communicate with each other presuming that they have routes for the D.E.N.x/16 (sub)network(s), be it an ethernet link, IPSec VPN, ATM WAN, or what ever.



Grant. . . .

Re: SNAT before IPSec

[Jorge Davila]

Grant,

In your analysis you forget that the packet delivered by the Router A to 
Router B (or viceversa) is an encrypted packet. Once the packet in decrypted 
in the other end the headers are the headers of the original packets. Then, 
the scenary is more funny.

Jorge.

On Thu, 07 Jun 2007 13:03:54 -0500
  Grant Taylor <gtaylor@riverviewtech.net> wrote:
> On 06/07/07 12:07, Grant Taylor wrote:
>> iptables -t nat -A PREROUTING -i $WAN -d D.E.F.x/24 -j NETMAP --to 
>> A.B.C.x/24
>> iptables -t nat -A POSTROUTING -o $LAN -s A.B.C.x/24 -j NETMAP --to 
>> D.E.F.x/24
>> 
>> This should cause the NETMAPing to happen at the remote end of the vpn 
>> link and (hopefully) not confuse the router at the local end of the vpn 
>> link.
> 
> I've done some more thinking and I think it would be better to do the SNAT 
>at the local end of the vpn link.  Doing the SNAT on the remote end will 
>work, but it is not as scalable as doing it on the local end.
> 
> If you consider your situation where you have multiple networks (3 or 
>more) that are all the same subnet that you want to tie together, you have 
>to SNAT and DNAT for each network.  DNATing should be done at the remove 
>end to change from the bogus address to the real address.  If SNATing is 
>done at the remove end, the remote end will have to have rules for each and 
>every other network to know what to SNAT to.  If SNATing is done at the 
>local end, the local router knows what to SNAT to and the remote end will 
>just DNAT and reply.  So a slightly modified version of the above rules 
>would be:
> 
> iptables -t nat -A PREROUTING -i $WAN -d D.E.F.x/24 -j NETMAP --to 
>A.B.C.x/24
> iptables -t nat -A POSTROUTING -o $WAN -d D.E.N.x/16 -j NETMAP --to 
>D.E.M.x/24
> 
> Where D.E.N.x/16 is the larger class B that encompasses all remote 
>networks.  I.e. selectively SNAT only when you are going to a remote 
>network.
> 
> Where D.E.M.x/24 is the local bogus network.
> 
> This *SHOULD* allow you to have two rules on each system to allow all of 
>them to communicate with each other presuming that they have routes for the 
>D.E.N.x/16 (sub)network(s), be it an ethernet link, IPSec VPN, ATM WAN, or 
>what ever.
> 
> 
> 
> Grant. . . .
> 
> 

Jorge Isaac Davila Lopez
Nicaragua Open Source
+505 430 5462
davila@nicaraguaopensource.com

Re: SNAT before IPSec

[Grant Taylor]

On 06/07/07 15:57, Jorge Davila wrote:
> In your analysis you forget that the packet delivered by the Router A 
> to Router B (or viceversa) is an encrypted packet. Once the packet in 
> decrypted in the other end the headers are the headers of the 
> original packets. Then, the scenary is more funny.

I was aware that IPSec encryption / decryption was going to take place. 
  It is my experience that current IPSec implementations which tunnel 
traffic do so with the traffic looping through through the kernel twice, 
once unencrypted and once encrypted then on the receiving end once 
encrypted and then once decrypted.  I was talking about doing the NATing 
on the unencrypted / decrypted passes, not the encrypted pass.

You are right that including the encryption / decryption in the 
discussion would have made things much more complex and entertaining to 
look at.

Thankfully what I was trying to convey is done regardless of IPSec (the 
way that I have messed with it) so it did not need to come in to the 
discussion.

Thanks for the pointer.  ;)



Grant. . . .

Re: SNAT before IPSec

[Jorge Davila]

Let me know if I'm wrong... Are you trying to modify the source address of 
the packets before the packets get encryption?

Jorge.

On Wed, 6 Jun 2007 00:29:51 +0300
  "noa levy" <noalevy@gmail.com> 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@nicaraguaopensource.com> 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@gmail.com> 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@nicaraguaopensource.com
>>
> 

Jorge Isaac Davila Lopez
Nicaragua Open Source
+505 430 5462
davila@nicaraguaopensource.com

SNAT before IPSec

[noa levy]

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