Quantcast

IPSec, nat on enc device

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

IPSec, nat on enc device

Eric Masson-4
Hello,

OpenBSD has support for this kind of setup since last January :
http://undeadly.org/cgi?action=article&sid=20090127205841
The commit :
http://marc.info/?l=openbsd-cvs&m=123246256228242&w=2

>From what I've understood, pf, depending on version in FreeBSD, could
already support natting on enc interfaces.

The missing part seems to be laying at the IKE daemon level.

Need of ipsec vpns beetween RFC1918 colliding networks is pretty usual
these days, so has anyone considered working in this area ?

Regards

--
 je comprend pas ce a quoi sert ce site ou cette boite a lettre.J'y voit
 plein de messages et autres anneries alors si tu pouvais m'aider et me
 repondre pour m'expliquer a qui et a quoi servent toutes ses phrases
 -+- DD in http://www.le-gnu.net : Allo Huston, nous avons un neuneu. -+-

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: IPSec, nat on enc device

Ermal Luçi-3
On Mon, Oct 19, 2009 at 9:18 AM, Eric Masson <[hidden email]> wrote:

> Hello,
>
> OpenBSD has support for this kind of setup since last January :
> http://undeadly.org/cgi?action=article&sid=20090127205841
> The commit :
> http://marc.info/?l=openbsd-cvs&m=123246256228242&w=2
>
> >From what I've understood, pf, depending on version in FreeBSD, could
> already support natting on enc interfaces.
>
> The missing part seems to be laying at the IKE daemon level.
I think you should send this email to ipsec-tool mailing list!
Basically the daemon should be modified for this and FreeBSD
is not the owner of such code.


Just my 2c

>
> Need of ipsec vpns beetween RFC1918 colliding networks is pretty usual
> these days, so has anyone considered working in this area ?
>
> Regards
>
> --
>  je comprend pas ce a quoi sert ce site ou cette boite a lettre.J'y voit
>  plein de messages et autres anneries alors si tu pouvais m'aider et me
>  repondre pour m'expliquer a qui et a quoi servent toutes ses phrases
>  -+- DD in http://www.le-gnu.net : Allo Huston, nous avons un neuneu. -+-
>


--
Ermal
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: IPSec, nat on enc device

Eric Masson-4
Ermal Luçi <[hidden email]> writes:

Hello Ermal,

> I think you should send this email to ipsec-tool mailing list!
> Basically the daemon should be modified for this and FreeBSD
> is not the owner of such code.

I know ;) I'll bug them regarding ${suject} as well (some ipsec-tools
devs lurk there too)

I'm not sure that pf & ipsec stack already support this feature. Maybe
bz@ or vanhu@ will shed a light on this point.

--
 Je veux créer une troupe de danse érotique! Si vous ètes près à vivre
 des émotions fortes... si non, la vie continue et...
 Signature: Un Gros Garcon!
 -+- CL in GNU - Enlevez le «Gar» de ma signature pour me répondre -+-
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: IPSec, nat on enc device

Ermal Luçi-3
On Mon, Oct 19, 2009 at 5:32 PM, Eric Masson <[hidden email]> wrote:

> Ermal Luçi <[hidden email]> writes:
>
> Hello Ermal,
>
>> I think you should send this email to ipsec-tool mailing list!
>> Basically the daemon should be modified for this and FreeBSD
>> is not the owner of such code.
>
> I know ;) I'll bug them regarding ${suject} as well (some ipsec-tools
> devs lurk there too)
>
> I'm not sure that pf & ipsec stack already support this feature. Maybe
> bz@ or vanhu@ will shed a light on this point.
>
AFAIK, there is not limitation to allow this in the IPSec stack.
So it is purely a daemon perspective to instrument the stack for this.

--
Ermal
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: IPSec, nat on enc device

VANHULLEBUS Yvan-7
In reply to this post by Eric Masson-4
Hi all.


On Mon, Oct 19, 2009 at 05:32:14PM +0200, Eric Masson wrote:
[....]
> I know ;) I'll bug them regarding ${suject} as well (some ipsec-tools
> devs lurk there too)

Do you think so ? :-D


> I'm not sure that pf & ipsec stack already support this feature. Maybe
> bz@ or vanhu@ will shed a light on this point.

This is a way to do that, but it needs some stuff on both kernel and
userland to be implemented that way.


Another way to have this feature is to implement what we call "NAT
before VPN": you can configure your kernel (or do it for specific NAT
rules if you want to do a more flexible implementation) to do NAT
process before doing IPsec stuff.


Then, you just write your NAT rules to move local/remote traffic
endpoints to distinct networks, and IPsec (both in kernel and
userland) will just have to deal with those NATed networks.


OpenBSD's way of doing things seems interesting while reading very
quickly your link, I'll have to take some more time to really see
exactly what they are doing.....



Yvan.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: IPSec, nat on enc device

Ermal Luçi-3
>
> OpenBSD's way of doing things seems interesting while reading very
> quickly your link, I'll have to take some more time to really see
> exactly what they are doing.....
>
>
Basically they make aware the daemon and the firewall of the nat.

Actually it is more 'user-friendly' to configure though clamsy since you have
to do keep the same information in two places, firewall nat rules and the ipsec
daemon.

You just tell instrument the daemon to inject one 'normal'(out) SA's
match traffic
coming from your local network and one SA for incoming traffic from
remote network
with the natted network address.

This all is because pf(4) cannot do 'incoming nat' by default.

--
Ermal
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: IPSec, nat on enc device

Eric Masson-4
In reply to this post by VANHULLEBUS Yvan-7
vanhu <[hidden email]> writes:

'Lut Yvan,

> Another way to have this feature is to implement what we call "NAT
> before VPN": you can configure your kernel (or do it for specific NAT
> rules if you want to do a more flexible implementation) to do NAT
> process before doing IPsec stuff.

I've used it last week on a 8.0.2 F200. The major drawback is that an
existing nat ruleset must be adapted (nomap rules for vpn networks that
dont need nat) and that it can cause issues when activated
(a reverse proxy located on a machine behind a bidirectionnal map woes
when nat before vpn is activated, that's why I have to setup another box
for natted vpns...)

> OpenBSD's way of doing things seems interesting while reading very
> quickly your link, I'll have to take some more time to really see
> exactly what they are doing.....

I agree with Ermal that duplicating nat information in pf and isakmpd is
suboptimal and probably error-prone, but it seems to me that it's less
intrusive than altering the ip stack.

--
 Suffit d'être suffisamment nombreux et tu feras moins le malin.
 Voter con est une chose, s'en vanter en est une autre...
 Vous êtes grotesques et dangereux.
 -+- Rocou In GNU - Le quantitatif supléra-t-il le qualitatif ? -+-
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: IPSec, nat on enc device

Bjoern A. Zeeb-2
On Tue, 20 Oct 2009, Eric Masson wrote:

Good evening,

> vanhu <[hidden email]> writes:
>
> 'Lut Yvan,
>
>> Another way to have this feature is to implement what we call "NAT
>> before VPN": you can configure your kernel (or do it for specific NAT
>> rules if you want to do a more flexible implementation) to do NAT
>> process before doing IPsec stuff.
>
> I've used it last week on a 8.0.2 F200. The major drawback is that an
> existing nat ruleset must be adapted (nomap rules for vpn networks that
> dont need nat) and that it can cause issues when activated
> (a reverse proxy located on a machine behind a bidirectionnal map woes
> when nat before vpn is activated, that's why I have to setup another box
> for natted vpns...)
>
>> OpenBSD's way of doing things seems interesting while reading very
>> quickly your link, I'll have to take some more time to really see
>> exactly what they are doing.....
>
> I agree with Ermal that duplicating nat information in pf and isakmpd is
> suboptimal and probably error-prone, but it seems to me that it's less
> intrusive than altering the ip stack.

I only had a quick look at the commit message being on the road.

I think Open seems to move further and further in the direction to be
an operating system around pf, rather than pf being a firewall
implementation for the OS, in some areas.  That kind of worries me -
also for further code sharing wrt to pf(4).

What I said before and will repeat is that if you want to use NAT and
VPN you want to do inside NAT (addmittingly handling the local machine
is a different story). I have done that years ago with ipfw. Then your
SA works on the NAT IP. I used it to avoid formerly RFC1918 address
collisions by NATing to an unrouted public IP for just the VPNs.
THe NAT IP will not be bound to any interface at all.

There is a reason major vendors have been doing inside and outside NAT
for ages now.  That pf cannot do that is bad and a design problem there.
The "commit Theo calls me insane for"  moves into the direction of
fixing that but when I talked to OpenBSD people at EuroBSDCon they said
something along the lines of "it's not entirely there yet and still
disabled because there are a few things that would work entirely as
expected".

There is abosultely no need to change the IP stack to accomplish that.


If you want to do it with pf + enc + NAT you can actually do that even
without patches but a bad ugly not to publish hack, that you will most
likely only want to do if you control all endpoints:
you add two policies: one with your internal network and one with your
NAT IP on both sides. racoon , configured correctly, will negotiate the
SA and share it for the tunnel endpoints for both policies.
The remote destination will never see a packet with a src of your
internal IPs but it will have a policy for it - else negotiation would
fail.  You may need to assure that no packets travel your way with the
1st, internal, policy in the firewall.

What I see with the OpenBSD change is that their hack does nothing but
get rid of the 1st policy for the internal network on the peer. Not
sure if they still need it locally or if they hacked the stack for
that; from what I see FreeBSD would have to do that.

/bz

--
Bjoern A. Zeeb         It will not break if you know what you are doing.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: IPSec, nat on enc device

Eric Masson-3
"Bjoern A. Zeeb" <[hidden email]> writes:

Hi Bjoern,

> What I said before and will repeat is that if you want to use NAT and
> VPN you want to do inside NAT (addmittingly handling the local machine
> is a different story). I have done that years ago with ipfw. Then your
> SA works on the NAT IP. I used it to avoid formerly RFC1918 address
> collisions by NATing to an unrouted public IP for just the VPNs.
> THe NAT IP will not be bound to any interface at all.

Ok, I've never used ipfw so shot in the dark.

If I had to nat 192.168.85.0/24 to 10.0.0.1 to access 192.168.201.0/24,
I would have to setup the following :

ipfw add divert natd all from 192.168.85.0/24 to 192.168.201.0/24 in
natd -alias_address 10.0.0.1
setkey -c << EOD
spdadd 10.0.0.1/32 192.168.201.0/24 any -P out ipsec
        esp/tunnel/mygw-theirgw/require ;
spdadd 192.168.201.0/24 10.0.0.1/32 any -P in ipsec
        esp/tunnel/theirgw-mygw/require ;
EOD

Does it seem reasonable or do I miss something ?

> There is a reason major vendors have been doing inside and outside NAT
> for ages now.  That pf cannot do that is bad and a design problem there.

Ok, thanks for you explanations.

Regards

--
 Salut,
 Je ne reçoit plus de messages de la mailing-list des nordistes.
 -+- SG in: GNU - Un ch'ti coup d'fufe pour la route ? -+-
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: IPSec, nat on enc device

Eric Masson-3
Eric Masson <[hidden email]> writes:

Hi Bjoern,

> Ok, I've never used ipfw so shot in the dark.
>
> If I had to nat 192.168.85.0/24 to 10.0.0.1 to access 192.168.201.0/24,
> I would have to setup the following :
>
> ipfw add divert natd all from 192.168.85.0/24 to 192.168.201.0/24 in
> natd -alias_address 10.0.0.1
> setkey -c << EOD
> spdadd 10.0.0.1/32 192.168.201.0/24 any -P out ipsec
> esp/tunnel/mygw-theirgw/require ;
> spdadd 192.168.201.0/24 10.0.0.1/32 any -P in ipsec
> esp/tunnel/theirgw-mygw/require ;
> EOD
>
> Does it seem reasonable or do I miss something ?

Seems I miss something, as tests don't work at all.

Could you elaborate on incoming nat & ipsec please ?

Regards

--
 J'ai reçu un mail parlant d'un petit garçon malade. Je l'ai transféré à
 tous ceux que je connaissais. On me dit que c'est un attrape couillons.
 Est-ce vrai? Suis-je vraiment aussi con que le prétend ma femme?
 -+-C in GNU - Le plus dur dans le mariage, c'est d'en sortir vivant -+-
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[hidden email]"
Loading...