Using DHCP with a Cisco VPN concentrator

[Patrick Topping]

Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
I apologize for posting this to the list...  I mean to send it directly
to Karl.  My apologies.

-Patrick

On Mon, 2006-06-19 at 11:21 -0700, Patrick Topping wrote:

> Content-Type: text/plain
> Content-Transfer-Encoding: quoted-printable
> Karl,
>=20
> I appreciate your help on this.  The way Cisco is doing DHCP is a
> freakin' mess.  I cannot believe that the concentrator does not forward
> the client's MAC address to the DHCP server and that it does not set the
> relay agent IP address to its PRIVATE interface. =3D20
>=20
> Let me explain what I am trying to accomplish.  I would like to see if
> you are doing the same thing and what your working configuration may be.
> We would like to start setting up address ranges per group.  We would
> then like to start restricting network access based on those user
> groups' pre-assigned network ranges.  That would be step one.  The next
> step would most likely involve an application like Cisco ACS.  What we
> would then like to do is add on hosts based restriction per TCP/UDP
> port.  I am sure that Cisco ACS is capable of this but have not tested
> it to be sure.
>=20
> So that is the 50,000 foot view of what I am trying to accomplish.  Are
> you doing anything similar and if so, how are you accomplishing it?
> Thanks.
>=20
> -Patrick
>=20
> ----------------------
>=20
> On Sat, 2006-06-17 at 23:39 -0400, Karl Mueller wrote:
>=20
> > I agree, the (Altiga) is pretty clumsy at DHCP. The workaround I did wa=
s =3D
> to
> > put an IP, rather than a network address in the network scope address. =
In
> > your case, put 10.20.5.10 (or another unused IP in that range), then se=
t =3D
> a
> > host (/32) route in the router between the concentrator and DHCP server=
 f=3D
> or
> > that IP, pointing to the IP of the VPN concentrator's private interface=
 a=3D
> s
> > the next hop.
> > In this case,  you'd do something like "ip route 10.20.5.10 255.255.255=
.2=3D
> 55
> > 10.6.1.122" in the router that's directly connected to the concentrator=
's
> > private interface (doesn't work with an interface route, the concentrat=
or
> > doesn't actually answer arp queries for the IP, but for some reason it =
do=3D
> es
> > accept the packet). Also note that you need to use a diffent IP address
> > for each concentrator, so use 10.20.5.11 for your secondary conc and se=
t
> > another /32 route pointing to his private interface as the next hop.
> >=3D20
> > This works, but it's a terrible hack, but it does allow you to have one=
 p=3D
> ool
> > for both concentrators, assuming you're using reverse route injection (=
an=3D
> d
> > if you are, you could actually set a holddown route for the IP you put =
in
> > the network scope address and have the concentrator inject it for you,
> > rather than using a static route on the router)
> >=3D20
> > If you want to discuss further, we should probably take this off-list s=
in=3D
> ce
> > it's not technically ISC-dhcpd related :)
> >=3D20
> > -Karl
> >=3D20
> > On 6/17/06, Patrick Topping <patrick.topping at hypermediasystems.com> wro=
te=3D
> :
> > >
> > > Content-Type: text/plain
> > > Content-Transfer-Encoding: quoted-printable
> > > I have tried with and without the network scope in the concentrator.
> > > Without the network scope I see the relay agent IP address as 10.6.1.=
12=3D
> 2
> > > which is the PRIVATE interface on the concentrator.  With the network
> > > scope configured for the group in the concentrator the relay agent IP
> > > address changes to the network scope.  Snippets from the sniffer trac=
es
> > > below:
> > >
> > > Without network scope:
> > >
> > > Relay agent IP address: 10.6.1.122 (10.6.1.122)
> > > Option 53: DHCP Message Type =3D3D3D DHCP Discover
> > >
> > > With network scope:
> > >
> > > Relay agent IP address: 10.20.5.0 (10.20.5.0)
> > > Option 53: DHCP Message Type =3D3D3D DHCP Discover
> > >
> > > If I understand you correctly, the network scope should be a routable
> > > address back to the concentrator.  What I don't get is what the IP
> > > address should be.  I was testing with scope 10.20.5.0 and that is wh=
at
> > > the concentrator was sending to the DHCP server as a relay agent IP
> > > address.  The only other address on the concentrator that is on the
> > > internal network is the PRIVATE interface of 10.6.1.122.  The
> > > implementation of how Cisco does DHCP on their concentrator leaves a =
lo=3D
> t
> > > to be desired.  What have others used in the past besides DHCP? =3D3D=
20
> > >
> > > -Patrick
> > >
> > >
> > >
> > >
> > > On Sat, 2006-06-17 at 13:54 -0400, Karl Mueller wrote:
> > >
> > > > >From what I've seen the cisco/altiga vpn concentrator will use wha=
te=3D
> ver
> > > =3D3D
> > > you
> > > > fill-in for the DHCP Network Scope in the Group configuration, unde=
r =3D
> the
> > > > General tab for a proxy agent IP. If this isn't filled-in, the conc=
 w=3D
> ill
> > > =3D3D
> > > use
> > > > the IP of the inside interface, which may not be what you want.
> > > > If your concentrator's on a different subnet than the DHCP server, =
be
> > > sur=3D3D
> > > e
> > > > to fill-out the DHCP network scope with a different in the group's
> > > config=3D3D
> > > ,
> > > > routable IP address for each concentrator, since the DHCP server wi=
ll
> > > try=3D3D
> > > to
> > > > unicast a response back to the IP of the proxy agent (the IP you
> > > filled-i=3D3D
> > > n
> > > > under DHCP network scope) rather than the IP of the concentrator it=
se=3D
> lf
> > > (=3D3D
> > > I
> > > > think this is broken behavior on the concentrator's side, rather th=
an
> > > the
> > > > DHCP server's)
> > > >=3D3D20
> > > > These concentrators have lots of quirks like that (like a semi-brok=
en
> > > OSP=3D3D
> > > F
> > > > implementation).
> > > >=3D3D20
> > > > Cheers,
> > > >=3D3D20
> > > > Karl
> > > >=3D3D20
> > > >=3D3D20
> > > > On 6/17/06, John Hascall <john at iastate.edu> wrote:
> > > > >
> > > > >
> > > > > > I have been trying to get DHCP set up for (2) Cisco 3030 VPN
> > > > > > concentrators.  I have confirmed that the configuration on the
> > > device=3D3D
> > > s
> > > > > > is correct but I am still not able to get an address from the D=
HC=3D
> P
> > > > > > server.  I think the issue may be how the DHCP address is being
> > > > > > requested.  The VPN client are all on Windows XP and running th=
e
> > > Cisc=3D3D
> > > o
> > > > > > VPN client.  Below is what I am seeing on the DHCP server when =
th=3D
> e
> > > > > > request is being relayed via the VPN concentrator:
> > > > > >
> > > > > > Jun 16 19:03:05 scratchy dhcpd: DHCPDISCOVER from 00:03:a0:89:2=
2:=3D
> 43
> > > v=3D3D
> > > ia
> > > > > > 10.6.1.122: unknown network segment
> > > > >   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > > >
> > > > > > I think the problem is the multiple DHCPDISCOVER requests comin=
g
> > > from
> > > > > > the concentrator / VPN client.  Below is a section from a Micro=
so=3D
> ft
> > > > > > support site:   ...
> > > > >
> > > > >     I strongly doubt this has anything to do with you problem.
> > > > >
> > > > >     The error message you are getting says that your DHCP server
> > > > >     knows nothing about 10.6.1.122 -- the address the requests
> > > > >     are coming from (which is presumably your VPN Conc).
> > > > >
> > > > >     You need to have an appropriate subnet definition in
> > > > >     your dhcpd.conf file which includes that address.
> > > > >     I do not know what your subnet mask is, but perhaps
> > > > >     one of these:
> > > > >
> > > > >          subnet 10.6.1.0 netmask 255.255.255.0 {
> > > > >          }
> > > > >     or:
> > > > >          subnet 10.6.0.0 netmask 255.255.0.0 {
> > > > >          }
> > > > >     or:
> > > > >          subnet 10.0.0.0 netmask 255.0.0.0 {
> > > > >          }
> > > > >
> > > > > John
> > > > >
> > > > >
> > > >=3D3D20
> > > >=3D3D20
> > >
> > >
> > >
> > >
> > >
> >=3D20
> >=3D20
>=20
>=20
>=20
>=20