IPSEC and NAT

IPSEC and NAT

[Emiel Mols]

Hi,

 

I've managed to setup a host-to-net ipsec connection with a remote network
on a linux router using (ported) isakmpd and kernel 2.6.8.1. However, I want
to be able to 'share' this ipsec connection with the rest of the network,
but since no ipsecn virtual interface is created in the 2.6 kernels I can't
use ordinary SNAT/MASQUERADE targets in iptables: ipsec packets get
encrypted before entering the POSTROUTING table :(, so the source address of
the encapsulated packet can't be changed anymore. I've read
http://lists.netfilter.org/pipermail/netfilter-devel/2004-January/thread.htm
l#13879, but the supplied patch doesn't work very well.

 

Does anyone have any suggestions on how to get this working?

 

Thanks in advance,

 

Emiel

Re: IPSEC and NAT

[John A. Sullivan III]

On Fri, 2004-10-15 at 14:00, Emiel Mols wrote:
> Hi,
> 
>  
> 
> I've managed to setup a host-to-net ipsec connection with a remote network
> on a linux router using (ported) isakmpd and kernel 2.6.8.1. However, I want
> to be able to 'share' this ipsec connection with the rest of the network,
> but since no ipsecn virtual interface is created in the 2.6 kernels I can't
> use ordinary SNAT/MASQUERADE targets in iptables: ipsec packets get
> encrypted before entering the POSTROUTING table :(, so the source address of
> the encapsulated packet can't be changed anymore. I've read
> http://lists.netfilter.org/pipermail/netfilter-devel/2004-January/thread.htm
> l#13879, but the supplied patch doesn't work very well.
> 
>  
> 
> Does anyone have any suggestions on how to get this working?
<snip>
I may be a bit tired at the end of a long week and have thus missed your
point . . . but why not set it up as a net-to-net connection? - John
-- 
John A. Sullivan III
Chief Technology Officer
Nexus Management
+1 207-985-7880
john.sullivan@nexusmgmt.com
---
If you are interested in helping to develop a GPL enterprise class
VPN/Firewall/Security device management console, please visit
http://iscs.sourceforge.net 

RE: IPSEC and NAT

[Emiel Mols]

Well, I only control one end of the link :). This one ip address is assigned
to me and I have to find a way to NAT it :(.

netfilter-devel@lists.netfilter.org
-----Original Message-----
From: John A. Sullivan III [mailto:john.sullivan@nexusmgmt.com] 
Sent: zaterdag 16 oktober 2004 0:02
To: Emiel Mols
Cc: netfilter-devel@lists.netfilter.org
Subject: Re: IPSEC and NAT

On Fri, 2004-10-15 at 14:00, Emiel Mols wrote:
> Hi,
> 
>  
> 
> I've managed to setup a host-to-net ipsec connection with a remote network
> on a linux router using (ported) isakmpd and kernel 2.6.8.1. However, I
want
> to be able to 'share' this ipsec connection with the rest of the network,
> but since no ipsecn virtual interface is created in the 2.6 kernels I
can't
> use ordinary SNAT/MASQUERADE targets in iptables: ipsec packets get
> encrypted before entering the POSTROUTING table :(, so the source address
of
> the encapsulated packet can't be changed anymore. I've read
>
http://lists.netfilter.org/pipermail/netfilter-devel/2004-January/thread.htm
> l#13879, but the supplied patch doesn't work very well.
> 
>  
> 
> Does anyone have any suggestions on how to get this working?
<snip>
I may be a bit tired at the end of a long week and have thus missed your
point . . . but why not set it up as a net-to-net connection? - John
-- 
John A. Sullivan III
Chief Technology Officer
Nexus Management
+1 207-985-7880
john.sullivan@nexusmgmt.com
---
If you are interested in helping to develop a GPL enterprise class
VPN/Firewall/Security device management console, please visit
http://iscs.sourceforge.net 

Re: IPSEC and NAT

[Alexander Samad]

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

On Sat, Oct 16, 2004 at 12:03:44AM +0200, Emiel Mols wrote:
> Well, I only control one end of the link :). This one ip address is assigned
> to me and I have to find a way to NAT it :(.

if you know the IP address why not use snat, this is how I used to do it
?

Alex

> 
> netfilter-devel@lists.netfilter.org
> -----Original Message-----
> From: John A. Sullivan III [mailto:john.sullivan@nexusmgmt.com] 
> Sent: zaterdag 16 oktober 2004 0:02
> To: Emiel Mols
> Cc: netfilter-devel@lists.netfilter.org
> Subject: Re: IPSEC and NAT
> 
> On Fri, 2004-10-15 at 14:00, Emiel Mols wrote:
> > Hi,
> > 
> >  
> > 
> > I've managed to setup a host-to-net ipsec connection with a remote network
> > on a linux router using (ported) isakmpd and kernel 2.6.8.1. However, I
> want
> > to be able to 'share' this ipsec connection with the rest of the network,
> > but since no ipsecn virtual interface is created in the 2.6 kernels I
> can't
> > use ordinary SNAT/MASQUERADE targets in iptables: ipsec packets get
> > encrypted before entering the POSTROUTING table :(, so the source address
> of
> > the encapsulated packet can't be changed anymore. I've read
> >
> http://lists.netfilter.org/pipermail/netfilter-devel/2004-January/thread.htm
> > l#13879, but the supplied patch doesn't work very well.
> > 
> >  
> > 
> > Does anyone have any suggestions on how to get this working?
> <snip>
> I may be a bit tired at the end of a long week and have thus missed your
> point . . . but why not set it up as a net-to-net connection? - John
> -- 
> John A. Sullivan III
> Chief Technology Officer
> Nexus Management
> +1 207-985-7880
> john.sullivan@nexusmgmt.com
> ---
> If you are interested in helping to develop a GPL enterprise class
> VPN/Firewall/Security device management console, please visit
> http://iscs.sourceforge.net 
> 
> 
> 
> 

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

RE: IPSEC and NAT

[John A. Sullivan III]

Well, then I suppose it would depend on exactly what the problem is. 
I'm quite new to the 2.6 IPSec implementation so I might be quite wrong
but I will share my thoughts.

If the problem is just that the ESP packets (I assume that's what you
are using) need to be from the one address, I would think the solution
is quite simple.  The SA and SP will define the end points just as they
are - using your assigned address.  The SP would change the inside
source to your subnet rather than your external IP address.

If the problem is that the SP on the other side will only allow the
decrypted packet to be from the one assigned IP, then, I would think,
you have some limitations.  I would think that you could initiate
traffic into the tunnel from your side.  I would not think that you
could initiate traffic from the other side.

I had briefly looked into this for my work on the ISCS network security
management project (http://iscs.sourceforge.net) because we use the
*swan virtual interfaces to implement the technology that allows us to
use out-of-band forms of user authentication throughout the entire VPN
WAN.  I recall that the initial implementation of the 2.6 IPSec only
passed through the netfilter hooks once.  Thus, by the time it hit the
POSTROUTING chain of the nat table, it was already encrypted and that
would break your scenario.  However, I think that has either been
changed, is in the process of being changed or is changed by a PoM
patch.  I'm sure someone on this list can clarify that.  The idea of the
change is that the packet would be processed completely once unencrypted
and then completely again encrypted.

If that is the case then you should be able to SNAT the packet and then
encrypt it.  The part where I'm a little hazy (I've never tried this) is
how to tell the kernel to encrypt the packet after SNAT.  I would think
one needs an SP which defines both internal addresses, i.e., the
internal addresses of both sides of the connection.  Here is where my
knowledge runs thin so I'll just spew ideas in the hope that someone
more knowledgeable will correct me and we'll all learn.

If your original address is a.a.a.a/n and the other side is z.z.z.z/n
and your assigned address is b.b.b.b, the other side will have a
Security Policy between b.b.b.b and z.z.z.z/n.  If you define an SP on
your side between a.a.a.a/n and z.z.z.z/n, I would think that sets the
stage for netfilter to pass the packet to IPSec for encryption and a
second pass through netfilter.  However, I think the phase II
negotiation will fail because your policy is a.a.a.a/n <-> z.z.z.z/n and
the other side is b.b.b.b <-> z.z.z.z/n.

If you create an SP of b.b.b.b <-> z.z.z.z/n on your side, since the
packet did not start processing as b.b.b.b until after its first pass
through netfilter, I do not know if netfilter would know that it has to
be passed to IPSec for encryption.

I wonder if you could create an SP of 0.0.0.0/0 <-> z.z.z.z/n.  I think
this would tell netfilter to send any packets for z.z.z.z/n to IPSec and
give you the chance to change the source address before it hits IPSec. 
My question would be what happens during phase II negotiation.  Do the
SPs have to match exactly in which case 0.0.0.0/0 <-> z.z.z.z/n does not
match b.b.b.b <-> z.z.z.z/n? Or does it just not need to conflict in
which case b.b.b.b <-> z.z.z.z/n is contained within 0.0.0.0/0
<->z.z.z.z/n, does not conflict and would thus result in a successful
phase II? I'd imagine if anyone in the world knows that answer, they are
on this mailing list :-)

I think you're out of luck for traffic initiated from the other side as
it would have no idea of where to send the decrypted packet.

This must surely be a case of the blind leading the sight impaired! I
hope it has at least sparked some useful thoughts in your mind - John

On Fri, 2004-10-15 at 18:03, Emiel Mols wrote:
> Well, I only control one end of the link :). This one ip address is assigned
> to me and I have to find a way to NAT it :(.
> 
> netfilter-devel@lists.netfilter.org
> -----Original Message-----
> From: John A. Sullivan III [mailto:john.sullivan@nexusmgmt.com] 
> Sent: zaterdag 16 oktober 2004 0:02
> To: Emiel Mols
> Cc: netfilter-devel@lists.netfilter.org
> Subject: Re: IPSEC and NAT
> 
> On Fri, 2004-10-15 at 14:00, Emiel Mols wrote:
> > Hi,
> > 
> >  
> > 
> > I've managed to setup a host-to-net ipsec connection with a remote network
> > on a linux router using (ported) isakmpd and kernel 2.6.8.1. However, I
> want
> > to be able to 'share' this ipsec connection with the rest of the network,
> > but since no ipsecn virtual interface is created in the 2.6 kernels I
> can't
> > use ordinary SNAT/MASQUERADE targets in iptables: ipsec packets get
> > encrypted before entering the POSTROUTING table :(, so the source address
> of
> > the encapsulated packet can't be changed anymore. I've read
> >
> http://lists.netfilter.org/pipermail/netfilter-devel/2004-January/thread.htm
> > l#13879, but the supplied patch doesn't work very well.
> > 
> >  
> > 
> > Does anyone have any suggestions on how to get this working?
> <snip>
> I may be a bit tired at the end of a long week and have thus missed your
> point . . . but why not set it up as a net-to-net connection? - John
-- 
John A. Sullivan III
Chief Technology Officer
Nexus Management
+1 207-985-7880
john.sullivan@nexusmgmt.com

RE: IPSEC and NAT

[Emiel Mols]

> Well, then I suppose it would depend on exactly what the problem is. 
> I'm quite new to the 2.6 IPSec implementation so I might be quite wrong
> but I will share my thoughts.
>
> If the problem is just that the ESP packets (I assume that's what you
> are using) need to be from the one address, I would think the solution
> is quite simple.  The SA and SP will define the end points just as they
> are - using your assigned address.  The SP would change the inside
> source to your subnet rather than your external IP address.
>
> If the problem is that the SP on the other side will only allow the
> decrypted packet to be from the one assigned IP, then, I would think,
> you have some limitations.  I would think that you could initiate
> traffic into the tunnel from your side.  I would not think that you
> could initiate traffic from the other side.

It is not necessary to initiate traffic from the other side, however, if
SNAT'ing in POSTROUTING works, I can also 'map' ports to internal ip
addresses, like in ordinary NAT'ing.

>
> I had briefly looked into this for my work on the ISCS network security
> management project (http://iscs.sourceforge.net) because we use the
> *swan virtual interfaces to implement the technology that allows us to
> use out-of-band forms of user authentication throughout the entire VPN
> WAN.  I recall that the initial implementation of the 2.6 IPSec only
> passed through the netfilter hooks once.  Thus, by the time it hit the
> POSTROUTING chain of the nat table, it was already encrypted and that
> would break your scenario.  However, I think that has either been
> changed, is in the process of being changed or is changed by a PoM
> patch.  I'm sure someone on this list can clarify that.  The idea of the
> change is that the packet would be processed completely once unencrypted
> and then completely again encrypted.

Indeed, the problem is that the packets get encrypted before reaching
POSTROUTING. I've managed the patch you're referring to:

router linux # cat ../patch-o-matic-ng-20040621/ipsec-01-output-hooks/help
[NETFILTER+IPSEC 1/4]

This patch adds new output hooks for IPsec. Packets traverse the hooks like
this:

1. -> (plain) FORWARD   -> POST_ROUTING -> (encrypted) LOCAL_OUT ->
POST_ROUTING
2. -> (plain) LOCAL_OUT -> POST_ROUTING -> (encrypted) LOCAL_OUT ->
POST_ROUTING

However, I can't get it patched on 2.6.8.1 (about 5 rejects) and 2.6.7 (1
reject). This patch is just what I need, but further downgrading isn't an
option. Has anyone succeeded with this patch in a recent 2.6 kernel?

>
> If that is the case then you should be able to SNAT the packet and then
> encrypt it.  The part where I'm a little hazy (I've never tried this) is
> how to tell the kernel to encrypt the packet after SNAT.  I would think
> one needs an SP which defines both internal addresses, i.e., the
> internal addresses of both sides of the connection.  Here is where my
> knowledge runs thin so I'll just spew ideas in the hope that someone
> more knowledgeable will correct me and we'll all learn.
>
> If your original address is a.a.a.a/n and the other side is z.z.z.z/n
> and your assigned address is b.b.b.b, the other side will have a
> Security Policy between b.b.b.b and z.z.z.z/n.  If you define an SP on
> your side between a.a.a.a/n and z.z.z.z/n, I would think that sets the
> stage for netfilter to pass the packet to IPSec for encryption and a
> second pass through netfilter.  However, I think the phase II
> negotiation will fail because your policy is a.a.a.a/n <-> z.z.z.z/n and
> the other side is b.b.b.b <-> z.z.z.z/n.

The Security policies are assigned by isakmpd and if I change the local and
remote address/netmask, negotiation fails.

>
> If you create an SP of b.b.b.b <-> z.z.z.z/n on your side, since the
> packet did not start processing as b.b.b.b until after its first pass
> through netfilter, I do not know if netfilter would know that it has to
> be passed to IPSec for encryption.
>
> I wonder if you could create an SP of 0.0.0.0/0 <-> z.z.z.z/n.  I think
> this would tell netfilter to send any packets for z.z.z.z/n to IPSec and
> give you the chance to change the source address before it hits IPSec. 
> My question would be what happens during phase II negotiation.  Do the
> SPs have to match exactly in which case 0.0.0.0/0 <-> z.z.z.z/n does not
> match b.b.b.b <-> z.z.z.z/n? Or does it just not need to conflict in
> which case b.b.b.b <-> z.z.z.z/n is contained within 0.0.0.0/0
> <->z.z.z.z/n, does not conflict and would thus result in a successful
> phase II? I'd imagine if anyone in the world knows that answer, they are
> on this mailing list :-)
>
> I think you're out of luck for traffic initiated from the other side as
> it would have no idea of where to send the decrypted packet.
>
> This must surely be a case of the blind leading the sight impaired! I
> hope it has at least sparked some useful thoughts in your mind - John
>

Thanks for your insights; it surely helped me get closer to a solution.

RE: IPSEC and NAT

[John A. Sullivan III]

On Sat, 2004-10-16 at 02:53, Emiel Mols wrote:
<snip>
> Indeed, the problem is that the packets get encrypted before reaching
> POSTROUTING. I've managed the patch you're referring to:
> 
> router linux # cat ../patch-o-matic-ng-20040621/ipsec-01-output-hooks/help
> [NETFILTER+IPSEC 1/4]
> 
> This patch adds new output hooks for IPsec. Packets traverse the hooks like
> this:
> 
> 1. -> (plain) FORWARD   -> POST_ROUTING -> (encrypted) LOCAL_OUT ->
> POST_ROUTING
> 2. -> (plain) LOCAL_OUT -> POST_ROUTING -> (encrypted) LOCAL_OUT ->
> POST_ROUTING
> 
> However, I can't get it patched on 2.6.8.1 (about 5 rejects) and 2.6.7 (1
> reject). This patch is just what I need, but further downgrading isn't an
> option. Has anyone succeeded with this patch in a recent 2.6 kernel?
I'd imagine you have but, just in case, have you applied any dependent
patches? For example, when I first applied the tcp window patch, I had
the same problem until I realized I had to apply all the pending patches
first.
> 
<snip>
-- 
John A. Sullivan III
Chief Technology Officer
Nexus Management
+1 207-985-7880
john.sullivan@nexusmgmt.com