SNAT and IPSEC

SNAT and IPSEC

[Eduardo Spremolla]

I have 2 local networks 10.2.2.0/24 and 10.37.130.0/24 interconnected by
a ipsec tunnel running on kernel 2.6 native ipsec. So far so good.

Now the admin of 10.37.130.0 wants me to NAT my network to 10.3.3.0
because he had a ip conflict. I cant SNAT because when the packet goes
to nat post it has been encapsulated in ESP and had the firewalls
address, as you can see in the bottom log snipe.I try to use NETMAP in
mangle PREROUTING, but it changes the dest ip , not the source.

Is this possible?

Thanks in advance for any clue.

LALO

55:55 mgl pre IN=eth0 OUT= SRC=10.2.2.3 DST=10.37.130.7 LEN=48 TTL=128
ID=644 DF PROTO=TCP SPT=1094 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0 
55:55 nat pre IN=eth0 OUT= SRC=10.2.2.3 DST=10.37.130.7 LEN=48 TTL=128
ID=644 DF PROTO=TCP SPT=1094 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0 
55:55 fwr IN=eth0 OUT=ppp0 SRC=10.2.2.3 DST=10.37.130.7 LEN=48 TTL=127
ID=644 DF PROTO=TCP SPT=1094 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0 
55:55 mgl post IN= OUT=ppp0 SRC=200.2.40.44 DST=200.40.244.6 LEN=104
TTL=64 ID=257 DF PROTO=ESP SPI=0x3368448 
55:55 nat post IN= OUT=ppp0 SRC=200.2.40.44 DST=200.40.244.6 LEN=104
TTL=64 ID=257 DF PROTO=ESP SPI=0x3368448 

55:56 mgl pre IN=ppp0 OUT= MAC= SRC=200.40.244.6 DST=200.2.40.44 LEN=104
TTL=58 ID=49185 DF PROTO=ESP SPI=0xb6601be 
55:56 inp IN=ppp0 OUT= MAC= SRC=200.40.244.6 DST=200.2.40.44 LEN=104
TTL=58 ID=49185 DF PROTO=ESP SPI=0xb6601be 
55:56 mgl pre IN=ppp0 OUT= MAC= SRC=10.37.130.7 DST=10.2.2.3 LEN=48
TTL=63 ID=0 DF PROTO=TCP SPT=80 DPT=1094 WINDOW=5840 RES=0x00 ACK SYN
URGP=0 
55:56 fwr IN=ppp0 OUT=eth0 SRC=10.37.130.7 DST=10.2.2.3 LEN=48 TTL=62
ID=0 DF PROTO=TCP SPT=80 DPT=1094 WINDOW=5840 RES=0x00 ACK SYN URGP=0 
55:56 mgl post IN= OUT=eth0 SRC=10.37.130.7 DST=10.2.2.3 LEN=48 TTL=62
ID=0 DF PROTO=TCP SPT=80 DPT=1094 WINDOW=5840 RES=0x00 ACK SYN URGP=0 

55:56 mgl pre IN=eth0 OUT= SRC=10.2.2.3 DST=10.37.130.7 LEN=40 TTL=128
ID=645 DF PROTO=TCP SPT=1094 DPT=80 WINDOW=65535 RES=0x00 ACK URGP=0 
55:56 fwr IN=eth0 OUT=ppp0 SRC=10.2.2.3 DST=10.37.130.7 LEN=40 TTL=127
ID=645 DF PROTO=TCP SPT=1094 DPT=80 WINDOW=65535 RES=0x00 ACK URGP=0 
55:56 mgl post IN= OUT=ppp0 SRC=200.2.40.44 DST=200.40.244.6 LEN=96
TTL=64 ID=257 DF PROTO=ESP SPI=0x3368448 

56:03 mgl pre IN=eth0 OUT= SRC=10.2.2.3 DST=10.37.130.7 LEN=41 TTL=128
ID=646 DF PROTO=TCP SPT=1094 DPT=80 WINDOW=65535 RES=0x00 ACK PSH
URGP=0 
56:03 fwr IN=eth0 OUT=ppp0 SRC=10.2.2.3 DST=10.37.130.7 LEN=41 TTL=127
ID=646 DF PROTO=TCP SPT=1094 DPT=80 WINDOW=65535 RES=0x00 ACK PSH
URGP=0 
56:03 mgl post IN= OUT=ppp0 SRC=200.2.40.44 DST=200.40.244.6 LEN=96
TTL=64 ID=3 DF PROTO=ESP SPI=0x3368448 

56:04 mgl pre IN=ppp0 OUT= MAC= SRC=200.40.244.6 DST=200.2.40.44 LEN=96
TTL=58 ID=49185 DF PROTO=ESP SPI=0xb6601be 
56:04 inp IN=ppp0 OUT= MAC= SRC=200.40.244.6 DST=200.2.40.44 LEN=96
TTL=58 ID=49185 DF PROTO=ESP SPI=0xb6601be 
56:04 mgl pre IN=ppp0 OUT= MAC= SRC=10.37.130.7 DST=10.2.2.3 LEN=40
TTL=63 ID=9879 DF PROTO=TCP SPT=80 DPT=1094 WINDOW=5840 RES=0x00 ACK
URGP=0 
56:04 fwr IN=ppp0 OUT=eth0 SRC=10.37.130.7 DST=10.2.2.3 LEN=40 TTL=62
ID=9879 DF PROTO=TCP SPT=80 DPT=1094 WINDOW=5840 RES=0x00 ACK URGP=0 
56:04 mgl post IN= OUT=eth0 SRC=10.37.130.7 DST=10.2.2.3 LEN=40 TTL=62
ID=9879 DF PROTO=TCP SPT=80 DPT=1094 WINDOW=5840 RES=0x00 ACK URGP=0 

56:04 mgl pre IN=eth0 OUT= SRC=10.2.2.3 DST=10.37.130.7 LEN=41 TTL=128
ID=647 DF PROTO=TCP SPT=1094 DPT=80 WINDOW=65535 RES=0x00 ACK PSH
URGP=0 
56:04 fwr IN=eth0 OUT=ppp0 SRC=10.2.2.3 DST=10.37.130.7 LEN=41 TTL=127
ID=647 DF PROTO=TCP SPT=1094 DPT=80 WINDOW=65535 RES=0x00 ACK PSH
URGP=0 
56:04 mgl post IN= OUT=ppp0 SRC=200.2.40.44 DST=200.40.244.6 LEN=96
TTL=64 ID=15414 DF PROTO=ESP SPI=0x3368448


Este e-mail y cualquier posible archivo adjunto está dirigido únicamente al destinatario del mensaje y contiene información que puede ser confidencial. Si Ud. no es el destinatario correcto por favor notifique al remitente respondiendo este mensaje y elimine inmediatamente el e-mail y los posibles archivos adjuntos al mismo de su sistema. Está prohibida cualquier utilización, difusión o copia de este e-mail por cualquier persona o entidad que no sean las específicas destinatarias del mensaje. ANTEL no acepta ninguna responsabilidad con respecto a cualquier comunicación que haya sido emitida incumpliendo nuestra Política de Seguridad de la Información.
. . . . . . . . .
This e-mail and any attachment is confidential and is intended solely for the addressee(s). If you are not intended recipient please inform the sender inmediately, answering this e-mail and delete it as well as the attached files. Any use, circulation or copy of this e-mail by any person or entity that not is the specific addressee(s) is prohibited. ANTEL is not responsible for any communication emitted without respecting our Information Security Policy.

Re: SNAT and IPSEC

[Daniel Lopes]

Eduardo Spremolla schrieb:
> I have 2 local networks 10.2.2.0/24 and 10.37.130.0/24 interconnected by
> a ipsec tunnel running on kernel 2.6 native ipsec. So far so good.
> 
> Now the admin of 10.37.130.0 wants me to NAT my network to 10.3.3.0
> because he had a ip conflict. I cant SNAT because when the packet goes
> to nat post it has been encapsulated in ESP and had the firewalls
> address, as you can see in the bottom log snipe.I try to use NETMAP in
> mangle PREROUTING, but it changes the dest ip , not the source.
> 
> Is this possible?
> 
> Thanks in advance for any clue.
> 
> LALO
> 
According to http://www.shorewall.net/netmap.html, besides I don´t 
really know how and when NETMAP interacts, it should work if you use an 
Interface for IPSec like the alternative IPSec stack implemented by 
FreeS/WAN. For the native stack I don´t know if it will work you will 
need to know when it exactly interacts. It will probably only work when 
implemented directly into the IPSec stack.

Re: SNAT and IPSEC

[Eduardo Spremolla]

Yes, the OpenSwan is mutch more clear, yuo have the packet with the
originals ip in the nat post chain to the tunn0 device. 

Is there any chance to aplay NETMAP to the source ip on PREROUTING ?

LALO 

On Tue, 2005-04-12 at 21:11 +0200, Daniel Lopes wrote:
> Eduardo Spremolla schrieb:
> > I have 2 local networks 10.2.2.0/24 and 10.37.130.0/24 interconnected by
> > a ipsec tunnel running on kernel 2.6 native ipsec. So far so good.
> > 
> > Now the admin of 10.37.130.0 wants me to NAT my network to 10.3.3.0
> > because he had a ip conflict. I cant SNAT because when the packet goes
> > to nat post it has been encapsulated in ESP and had the firewalls
> > address, as you can see in the bottom log snipe.I try to use NETMAP in
> > mangle PREROUTING, but it changes the dest ip , not the source.
> > 
> > Is this possible?
> > 
> > Thanks in advance for any clue.
> > 
> > LALO
> > 
> According to http://www.shorewall.net/netmap.html, besides I don´t 
> really know how and when NETMAP interacts, it should work if you use an 
> Interface for IPSec like the alternative IPSec stack implemented by 
> FreeS/WAN. For the native stack I don´t know if it will work you will 
> need to know when it exactly interacts. It will probably only work when 
> implemented directly into the IPSec stack.
> 


Este e-mail y cualquier posible archivo adjunto está dirigido únicamente al destinatario del mensaje y contiene información que puede ser confidencial. Si Ud. no es el destinatario correcto por favor notifique al remitente respondiendo este mensaje y elimine inmediatamente el e-mail y los posibles archivos adjuntos al mismo de su sistema. Está prohibida cualquier utilización, difusión o copia de este e-mail por cualquier persona o entidad que no sean las específicas destinatarias del mensaje. ANTEL no acepta ninguna responsabilidad con respecto a cualquier comunicación que haya sido emitida incumpliendo nuestra Política de Seguridad de la Información.
. . . . . . . . .
This e-mail and any attachment is confidential and is intended solely for the addressee(s). If you are not intended recipient please inform the sender inmediately, answering this e-mail and delete it as well as the attached files. Any use, circulation or copy of this e-mail by any person or entity that not is the specific addressee(s) is prohibited. ANTEL is not responsible for any communication emitted without respecting our Information Security Policy.

Re: SNAT and IPSEC

[Michael Muenz]

Hi,

> "Eduardo Spremolla" <edspremolla@antel.com.uy> schrieb im 
> Newsbeitragnews:1113393681.4244.3.camel@fly.in.iantel.com.uy...
> Yes, the OpenSwan is mutch more clear, yuo have the packet with the
> originals ip in the nat post chain to the tunn0 device. 

> Is there any chance to aplay NETMAP to the source 
> ip on PREROUTING ?

I never used NETMAP but this is from the description:
It can be applied to the PREROUTING chain to alter the destination of
incoming connections, to the POSTROUTING chain to alter the source 
of outgoing connections, or both (with separate rules).

You want to alter the source (10.2.2.0/24) and that's an outgoing conn.
(Of course vice versa) ..

So perhaps this will work:
iptables -t nat -A POSTROUTING -s 10.2.2.0/24 -d 10.37.130.0/24 \
   -j NETMAP --to 10.3.3.0/24
iptables -t nat -A PREROUTING -s 10.37.130.0/24 -d 10.3.3.0/24 \
   -j NETMAP --to 10.2.2.0/24

- Michael

Re: SNAT and IPSEC

[Daniel Lopes]

Michael Muenz schrieb:
> Hi,
> 
> 
>>"Eduardo Spremolla" <edspremolla@antel.com.uy> schrieb im 
>>Newsbeitragnews:1113393681.4244.3.camel@fly.in.iantel.com.uy...
>>Yes, the OpenSwan is mutch more clear, yuo have the packet with the
>>originals ip in the nat post chain to the tunn0 device. 
> 
> 
>>Is there any chance to aplay NETMAP to the source 
>>ip on PREROUTING ?
> 
> 
> I never used NETMAP but this is from the description:
> It can be applied to the PREROUTING chain to alter the destination of
> incoming connections, to the POSTROUTING chain to alter the source 
> of outgoing connections, or both (with separate rules).
> 
> You want to alter the source (10.2.2.0/24) and that's an outgoing conn.
> (Of course vice versa) ..
> 
> So perhaps this will work:
> iptables -t nat -A POSTROUTING -s 10.2.2.0/24 -d 10.37.130.0/24 \
>    -j NETMAP --to 10.3.3.0/24
> iptables -t nat -A PREROUTING -s 10.37.130.0/24 -d 10.3.3.0/24 \
>    -j NETMAP --to 10.2.2.0/24
> 
> - Michael
> 
> 
> 
> 
No it won´t that´s the problem because with native IPSec the packets 
only pass the chains once (without the patches). So they arrive tunnel 
encapsulated at the POSTROUTING chain. But with the patches it would 
probably work.

Re: SNAT and IPSEC

[Eduardo Spremolla]

Are these patches incorporated in some iptables version so far?

I'm running 1.2.9-2.3.1 now. and do not have development environment in
that box, as a secure measure.

Thanks to every body who replayed so far.

LALO

On Thu, 2005-04-14 at 16:03 +0200, Daniel Lopes wrote:
> Michael Muenz schrieb:
> > Hi,
> > 
> > 
> >>"Eduardo Spremolla" <edspremolla@antel.com.uy> schrieb im 
> >>Newsbeitragnews:1113393681.4244.3.camel@fly.in.iantel.com.uy...
> >>Yes, the OpenSwan is mutch more clear, yuo have the packet with the
> >>originals ip in the nat post chain to the tunn0 device. 
> > 
> > 
> >>Is there any chance to aplay NETMAP to the source 
> >>ip on PREROUTING ?
> > 
> > 
> > I never used NETMAP but this is from the description:
> > It can be applied to the PREROUTING chain to alter the destination of
> > incoming connections, to the POSTROUTING chain to alter the source 
> > of outgoing connections, or both (with separate rules).
> > 
> > You want to alter the source (10.2.2.0/24) and that's an outgoing conn.
> > (Of course vice versa) ..
> > 
> > So perhaps this will work:
> > iptables -t nat -A POSTROUTING -s 10.2.2.0/24 -d 10.37.130.0/24 \
> >    -j NETMAP --to 10.3.3.0/24
> > iptables -t nat -A PREROUTING -s 10.37.130.0/24 -d 10.3.3.0/24 \
> >    -j NETMAP --to 10.2.2.0/24
> > 
> > - Michael
> > 
> > 
> > 
> > 
> No it won´t that´s the problem because with native IPSec the packets 
> only pass the chains once (without the patches). So they arrive tunnel 
> encapsulated at the POSTROUTING chain. But with the patches it would 
> probably work.
> 


Este e-mail y cualquier posible archivo adjunto está dirigido únicamente al destinatario del mensaje y contiene información que puede ser confidencial. Si Ud. no es el destinatario correcto por favor notifique al remitente respondiendo este mensaje y elimine inmediatamente el e-mail y los posibles archivos adjuntos al mismo de su sistema. Está prohibida cualquier utilización, difusión o copia de este e-mail por cualquier persona o entidad que no sean las específicas destinatarias del mensaje. ANTEL no acepta ninguna responsabilidad con respecto a cualquier comunicación que haya sido emitida incumpliendo nuestra Política de Seguridad de la Información.
. . . . . . . . .
This e-mail and any attachment is confidential and is intended solely for the addressee(s). If you are not intended recipient please inform the sender inmediately, answering this e-mail and delete it as well as the attached files. Any use, circulation or copy of this e-mail by any person or entity that not is the specific addressee(s) is prohibited. ANTEL is not responsible for any communication emitted without respecting our Information Security Policy.

Re: SNAT and IPSEC

[Jason Opperisano]

On Thu, Apr 14, 2005 at 12:19:18PM -0300, Eduardo Spremolla wrote:
> Are these patches incorporated in some iptables version so far?
> 
> I'm running 1.2.9-2.3.1 now. and do not have development environment in
> that box, as a secure measure.
> 
> Thanks to every body who replayed so far.

the patches in question:

  ipsec-01-output-hooks
  ipsec-02-input-hooks
  ipsec-03-policy-lookup
  ipsec-04-policy-checks

are kernel patches, not iptables userspace patches.

-j

--
"Carter Pewterschmidt: Oh my god. He's violating Sea Breeze.
 Peter: No, he's just awkwardly positioning himself... OK, NOW he's
 violating Sea Breeze."
        --Family Guy

Re: SNAT and IPSEC

[Jason Opperisano]

On Tue, Apr 12, 2005 at 03:08:12PM -0300, Eduardo Spremolla wrote:
> I have 2 local networks 10.2.2.0/24 and 10.37.130.0/24 interconnected by
> a ipsec tunnel running on kernel 2.6 native ipsec. So far so good.
> 
> Now the admin of 10.37.130.0 wants me to NAT my network to 10.3.3.0
> because he had a ip conflict. I cant SNAT because when the packet goes
> to nat post it has been encapsulated in ESP and had the firewalls
> address, as you can see in the bottom log snipe.I try to use NETMAP in
> mangle PREROUTING, but it changes the dest ip , not the source.
> 
> Is this possible?
> 
> Thanks in advance for any clue.

dunno if this will help or not; as i have lost my test lab, but have you
applied the ipsec patches from PoM:

  ipsec-01-output-hooks
  ipsec-02-input-hooks
  ipsec-03-policy-lookup
  ipsec-04-policy-checks

it is my understanding that these patches make packets traverse the
netfilter hooks twice:  once clear, and again encrypted.

-j

--
"Peter: I call it... Petoria. I was going to call it Peterland,
 but that gay bar by the airport took it."
        --Family Guy

Re: SNAT and IPSEC

[Eduardo Spremolla]

How can I know if the patches are in my version:

kernel 		2.6.10-1.771_FC2
iptables 	1.2.9-2.3.1
ipsec-tools 	0.5-2.fc2

I will test it. I did not set the POSTROUTING SNAT rule, since I
understand make no sense in the ESP packet.

Thanks for the clue.

LALO

On Wed, 2005-04-13 at 10:58 -0400, Jason Opperisano wrote:
> On Tue, Apr 12, 2005 at 03:08:12PM -0300, Eduardo Spremolla wrote:
> > I have 2 local networks 10.2.2.0/24 and 10.37.130.0/24 interconnected by
> > a ipsec tunnel running on kernel 2.6 native ipsec. So far so good.
> > 
> > Now the admin of 10.37.130.0 wants me to NAT my network to 10.3.3.0
> > because he had a ip conflict. I cant SNAT because when the packet goes
> > to nat post it has been encapsulated in ESP and had the firewalls
> > address, as you can see in the bottom log snipe.I try to use NETMAP in
> > mangle PREROUTING, but it changes the dest ip , not the source.
> > 
> > Is this possible?
> > 
> > Thanks in advance for any clue.
> 
> dunno if this will help or not; as i have lost my test lab, but have you
> applied the ipsec patches from PoM:
> 
>   ipsec-01-output-hooks
>   ipsec-02-input-hooks
>   ipsec-03-policy-lookup
>   ipsec-04-policy-checks
> 
> it is my understanding that these patches make packets traverse the
> netfilter hooks twice:  once clear, and again encrypted.
> 
> -j
> 
> --
> "Peter: I call it... Petoria. I was going to call it Peterland,
>  but that gay bar by the airport took it."
>         --Family Guy
> 


Este e-mail y cualquier posible archivo adjunto está dirigido únicamente al destinatario del mensaje y contiene información que puede ser confidencial. Si Ud. no es el destinatario correcto por favor notifique al remitente respondiendo este mensaje y elimine inmediatamente el e-mail y los posibles archivos adjuntos al mismo de su sistema. Está prohibida cualquier utilización, difusión o copia de este e-mail por cualquier persona o entidad que no sean las específicas destinatarias del mensaje. ANTEL no acepta ninguna responsabilidad con respecto a cualquier comunicación que haya sido emitida incumpliendo nuestra Política de Seguridad de la Información.
. . . . . . . . .
This e-mail and any attachment is confidential and is intended solely for the addressee(s). If you are not intended recipient please inform the sender inmediately, answering this e-mail and delete it as well as the attached files. Any use, circulation or copy of this e-mail by any person or entity that not is the specific addressee(s) is prohibited. ANTEL is not responsible for any communication emitted without respecting our Information Security Policy.

Re: SNAT and IPSEC

[Daniel Lopes]

Eduardo Spremolla schrieb:
> How can I know if the patches are in my version:
> 
> kernel 		2.6.10-1.771_FC2
> iptables 	1.2.9-2.3.1
> ipsec-tools 	0.5-2.fc2
> 
> I will test it. I did not set the POSTROUTING SNAT rule, since I
> understand make no sense in the ESP packet.
> 
> Thanks for the clue.
> 
> LALO
> 
> On Wed, 2005-04-13 at 10:58 -0400, Jason Opperisano wrote:
> 
>>On Tue, Apr 12, 2005 at 03:08:12PM -0300, Eduardo Spremolla wrote:
>>
>>>I have 2 local networks 10.2.2.0/24 and 10.37.130.0/24 interconnected by
>>>a ipsec tunnel running on kernel 2.6 native ipsec. So far so good.
>>>
>>>Now the admin of 10.37.130.0 wants me to NAT my network to 10.3.3.0
>>>because he had a ip conflict. I cant SNAT because when the packet goes
>>>to nat post it has been encapsulated in ESP and had the firewalls
>>>address, as you can see in the bottom log snipe.I try to use NETMAP in
>>>mangle PREROUTING, but it changes the dest ip , not the source.
>>>
>>>Is this possible?
>>>
>>>Thanks in advance for any clue.
>>
>>dunno if this will help or not; as i have lost my test lab, but have you
>>applied the ipsec patches from PoM:
>>
>>  ipsec-01-output-hooks
>>  ipsec-02-input-hooks
>>  ipsec-03-policy-lookup
>>  ipsec-04-policy-checks
>>
>>it is my understanding that these patches make packets traverse the
>>netfilter hooks twice:  once clear, and again encrypted.
>>
>>-j
>>
>>--
>>"Peter: I call it... Petoria. I was going to call it Peterland,
>> but that gay bar by the airport took it."
>>        --Family Guy
>>
> 
> 
> 
> Este e-mail y cualquier posible archivo adjunto está dirigido únicamente al destinatario del mensaje y contiene información que puede ser confidencial. Si Ud. no es el destinatario correcto por favor notifique al remitente respondiendo este mensaje y elimine inmediatamente el e-mail y los posibles archivos adjuntos al mismo de su sistema. Está prohibida cualquier utilización, difusión o copia de este e-mail por cualquier persona o entidad que no sean las específicas destinatarias del mensaje. ANTEL no acepta ninguna responsabilidad con respecto a cualquier comunicación que haya sido emitida incumpliendo nuestra Política de Seguridad de la Información.
> . . . . . . . . .
> This e-mail and any attachment is confidential and is intended solely for the addressee(s). If you are not intended recipient please inform the sender inmediately, answering this e-mail and delete it as well as the attached files. Any use, circulation or copy of this e-mail by any person or entity that not is the specific addressee(s) is prohibited. ANTEL is not responsible for any communication emitted without respecting our Information Security Policy.
> 
> 

Yes try the patches that should. Because in my understandig normally the 
  packets pass a chain only once encrypted or plain. This is so because 
of the IPSec hooks within the Netfilter hooks and how they work. So 
patching could also it complicates the IPSec handling for the kernel but 
as long as it is transparent to the user ;).

Re: SNAT and IPSEC

[Daniel Wittenberg]

Couldn't he just SNAT the packets on his side when they become un-
encapsulated?  I'm doing this on a couple of my vpn links.

Dan

On Tue, 2005-04-12 at 15:08 -0300, Eduardo Spremolla wrote:
> I have 2 local networks 10.2.2.0/24 and 10.37.130.0/24 interconnected by
> a ipsec tunnel running on kernel 2.6 native ipsec. So far so good.
> 
> Now the admin of 10.37.130.0 wants me to NAT my network to 10.3.3.0
> because he had a ip conflict. I cant SNAT because when the packet goes
> to nat post it has been encapsulated in ESP and had the firewalls
> address, as you can see in the bottom log snipe.I try to use NETMAP in
> mangle PREROUTING, but it changes the dest ip , not the source.
> 
> Is this possible?
> 
> Thanks in advance for any clue.
> 
> LALO

Re: SNAT and IPSEC

[Eduardo Spremolla]

That could be the easy way ;-)

LALO

On Wed, 2005-04-13 at 11:08 -0500, Daniel Wittenberg wrote:
> Couldn't he just SNAT the packets on his side when they become un-
> encapsulated?  I'm doing this on a couple of my vpn links.
> 
> Dan
> 
> On Tue, 2005-04-12 at 15:08 -0300, Eduardo Spremolla wrote:
> > I have 2 local networks 10.2.2.0/24 and 10.37.130.0/24 interconnected by
> > a ipsec tunnel running on kernel 2.6 native ipsec. So far so good.
> > 
> > Now the admin of 10.37.130.0 wants me to NAT my network to 10.3.3.0
> > because he had a ip conflict. I cant SNAT because when the packet goes
> > to nat post it has been encapsulated in ESP and had the firewalls
> > address, as you can see in the bottom log snipe.I try to use NETMAP in
> > mangle PREROUTING, but it changes the dest ip , not the source.
> > 
> > Is this possible?
> > 
> > Thanks in advance for any clue.
> > 
> > LALO
> 
> 


Este e-mail y cualquier posible archivo adjunto está dirigido únicamente al destinatario del mensaje y contiene información que puede ser confidencial. Si Ud. no es el destinatario correcto por favor notifique al remitente respondiendo este mensaje y elimine inmediatamente el e-mail y los posibles archivos adjuntos al mismo de su sistema. Está prohibida cualquier utilización, difusión o copia de este e-mail por cualquier persona o entidad que no sean las específicas destinatarias del mensaje. ANTEL no acepta ninguna responsabilidad con respecto a cualquier comunicación que haya sido emitida incumpliendo nuestra Política de Seguridad de la Información.
. . . . . . . . .
This e-mail and any attachment is confidential and is intended solely for the addressee(s). If you are not intended recipient please inform the sender inmediately, answering this e-mail and delete it as well as the attached files. Any use, circulation or copy of this e-mail by any person or entity that not is the specific addressee(s) is prohibited. ANTEL is not responsible for any communication emitted without respecting our Information Security Policy.

Re: SNAT and IPSEC

[Taylor Grant]

> Couldn't he just SNAT the packets on his side when they become un-
> encapsulated?  I'm doing this on a couple of my vpn links.

I don't think that you could just SNAT the packets that are on the way out because as I understand it SNAT happens in nat:POSTROUTING *after* the routing decision has been made.  I had originally thought that the IPSec traffic did pass through IPTables a couple of times, once unencrypted and then again encrypted.  But based on the LOG entries that he has presented the traffic only passes through IPTables one time on it's way out, and a couple of times on it's way in.  Seeing as how the traffic is only passing through IPTables one time on it's way out, it is coming in to the system from the LAN and immediately going in to the IPSec stack and being encrypted and then sent out directly, leaving no chance for it to be SNATed before it enters the IPSec stack.  Reportedly there are some kernel patches to fix this issues thus causing the packets to traverse IPTables twice, once unencrypted and 
 once encrypted.  If the packets did indeed pass through IPTables twice they could be SNATe
d before they did enter the IPSec VPN.  The only caveat would be that the IPSec VPN would have to be configured to allow traffic from the 10.3.3.x/24 network vs his 10.2.2.x/24 network, this would have to be done on both ends too.



Grant. . . .

Re: SNAT and IPSEC

[Alexander Samad]

[-- Attachment #1: Type: text/plain, Size: 1648 bytes --]

On Wed, Apr 13, 2005 at 06:50:37PM -0500, Taylor Grant wrote:
> >Couldn't he just SNAT the packets on his side when they become un-
> >encapsulated?  I'm doing this on a couple of my vpn links.
> 
> I don't think that you could just SNAT the packets that are on the way out 
> because as I understand it SNAT happens in nat:POSTROUTING *after* the 
> routing decision has been made.  I had originally thought that the IPSec 
> traffic did pass through IPTables a couple of times, once unencrypted and 
> then again encrypted.  But based on the LOG entries that he has presented 
> the traffic only passes through IPTables one time on it's way out, and a 
> couple of times on it's way in.  Seeing as how the traffic is only passing 
> through IPTables one time on it's way out, it is coming in to the system 
> from the LAN and immediately going in to the IPSec stack and being 
> encrypted and then sent out directly, leaving no chance for it to be SNATed 
> before it enters the IPSec stack.  Reportedly there are some kernel patches 
> to fix this issues thus causing the packets to traverse IPTables twice, 
> once unencrypted and once encrypted.  If the packets did indeed pass 
> through IPTables twice they could be SNATe
> d before they did enter the IPSec VPN.  The only caveat would be that the 
> IPSec VPN would have to be configured to allow traffic from the 10.3.3.x/24 
> network vs his 10.2.2.x/24 network, this would have to be done on both ends 
> too.

these pacthes exist in pom-ng and I believe have made it into 2.6.8 and
above (not sure about the entry version)

> 
> 
> 
> Grant. . . .
> 
> 

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: SNAT and IPSEC

[Trevor Cordes]

NAT works great over IPSEC with the patches mentioned in previous replies.  
However, the patches only apply (AFAIK) to 2.6.10 or below.  See my 
RH bugzilla entry and make some noise:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=143374

I've been using NAT over IPSEC with those patches with 2.6.10 for ages now
and it works great, mostly.

I sure wish a solution would be found to get this functionality in the 
mainstream netfilter/kernel code!

Everyone who needs this should CC themselves to that bugzilla so we can 
get enough voices behind the effort.