[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Phase 2 ID's for different VPN's with different Address Space
Dan,
Thanks for the reply.
I think amending my architecture to include the subnets will clarify things.
VPN 1, site A VPN 1, site B
---------+ +------+ +------+ +---------
10.1/16 | | | | | | 10.2/16
+--------+ | | +--------+
| GW A +----------+ GW B |
+--------+ | | +--------+
10.1/16 | | | | | | 10.2/16
---------+ +------+ +------+ +---------
VPN 2, site A VPN 2, site B
Each VPN has its own address space which may or may not overlap. In the above
example, VPN 1 has two sites with 10.1/16 subnet and 10.2/16 subnet. VPN 2 also
has two sites, one with a 10.1/16 subnet, and the other a 10.2/16 subnet. (This
is a requirement as we don't want to mandate which addresses each VPN chooses to
use).
The first packet arrives from VPN1, site A (and I know this from the L2 interface
it uses), destined for VPN1, site B.
GWA initiates phase 1 with GWB. They use DN ID's (because each has a certificate)
for this phase.
Then GWA initiates phase 2 with GWB. Let's say they use ID_IPV4_ADDR_SUBNET for
both IDci and IDcr. Then IDci=10.1/16 and IDcr=10.2/16. When GWB sees the phase
2 ID's, GWB has no way of knowing whether the ID's correspond to the address space
of VPN1 or VPN2. Therefore, when GWB receives an ESP packet from GWA with the SPI
negotiated, GWB has no idea whether to forward the packet to VPN 1, site B or VPN
2, site B.
I hope this make it clearer. Dan, does this change your answer? Or did I
misunderstand your answer?
-Dan
Dan Harkins wrote:
> On Mon, 01 Nov 1999 11:14:24 EST you wrote
> >
> > I have an interesting problem, and I am hoping that someone on the list
> > can help with the solution.
> >
> > I am implementing a sgw that has many physical interfaces (T1, T3, etc.)
> > to different private networks. Each private network has its own address
> > space. A very simple architecture looks like this:
> >
> > VPN 1, site A VPN 1, site B
> > -------+ +------+ +------+ +-------
> > | | | | | |
> > +--------+ | | +--------+
> > | GW A +----------+ GW B |
> > +--------+ | | +--------+
> > | | | | | |
> > -------+ +------+ +------+ +-------
> > VPN 2, site A VPN 2, site B
> >
> > My thinking is, I do a phase 1 IKE between GW A and GW B.
> >
> > To set up the ESP tunnel for VPN 1, I do a phase 2 IKE between GW A and
> > GW B, using PFS. I do another similar phase 2 exchange for VPN 2 to set
> > up the ESP tunnel for this VPN.
> >
> > Question: how do I identify that my clients are a particular VPN?
> >
> > I can't use ID_IPV4_ADDR_SUBNET, since each VPN has its own address
> > space.
>
> That should be fine. They're gonna be separate negotiations. Assuming that
> site A is initiating to site B, the first packet from VPN{1,2} will hit
> GWA who will queue it up and do a phase 1 IKE exchange with GWB. The ID
> used there depends on how you're authenticating. Then the phase 2 exchange
> happens. The IDs are constructed from the selector that the packet hit.
> So if your selector is from one subnet to another then they're both
> ID_IPV4_ADDR_SUBNET. If it's a subnet to a paricular host then the 1st
> is an ID_IPV4_ADDR_SUBNET and the 2nd one is a ID_IPV4_ADDR. When another
> packet for the other VPN hits the GWA it will do another phase 2 exchange
> and this one will be identified by the specifics of the particular selector
> that matched that packet which will necessarily be different than the
> specifics of the selector that matched the first packet.
>
> > I could use ID_FQDN, but then I couldn't specify the IP addresses (plus
> > it's ugly). What I'd really like is to specify a 32-bit VPN identifier,
> > along with the IP subnet and transport port. Can I do this without
> > defining new ID types?
>
> An ID_FQDN can't be used because it doesn't convey any addressing information,
> as you noted. ID_FQDN is intended for phase 1 exchanges.
>
> What is this VPN identifier? Where is that defined? IKE doesn't define
> VPNs so you can't specify that somebody is "in a VPN" using IKE.
>
> > I could use ID_KEYID, but it really doesn't identify a key, and, of
> > course, it wouldn't be interoperable. However, I will use this if this
> > seems to be the preferred method.
>
> ID_KEYID does identify a key but it too is for phase 1 exchanges.
>
> Whatever the parameters of an RFC2401 selector there are corresponding
> RFC2407/RFC2408 identities to use with RFC2409. In fact, it was limitations
> of the ID payload that caused the port range to be removed as an RFC2401
> selector parameter. Hopefully the next rev of the documents will allow
> that to be added back.
>
> Dan.
begin:vcard
n:Fox;Daniel
tel;fax:978-263-1099
tel;work:978-795-5405
x-mozilla-html:FALSE
url:http://www.ennovatenetworks.com
org:Ennovate Networks
adr:;;60 Codman Hill Road;Boxborough;MA;01719;USA
version:2.1
email;internet:dfox@ennovatenetworks.com
title:Senior Software Engineer
fn:Daniel Fox
end:vcard
Follow-Ups:
References: