Address allocation query

[Pat Hurt]

A PPTP client comes in through a firewall and hits on a VPN server (W2k3
box), that allocates IP addresses to clients from a scope on an (internal
network) DHCP server (also W2k3).

No problems: On-net IP address is allocated to client, DNS & WINS correctly
set, things resolving nicely from the client end...

The client needs to run a front-end application talking to a back-end Ingres
DB server, and should the client want to print information from the
application, a request is queued (via a DB record) for the attention of a
process running on the DB server, which generates and routes the printout to
the required printer on the clients behalf, i.e. the client has no
involvement in producing the print output after issuing the request.

So the DB server needs to have defined in its printers how to talk to the
client printers; no problems - when the client first logs in, the client
(shared) printer is manually defined to the DB server as a network
accessible printer, and printing works fine.

The problems arise when the client logs out/in.

It seems from tracing whats happening that the Print Spooler service on the
DB server holds onto the IP address the client was allocated from the first
session, whilst the client is happily chatting on its new IP address - so
the client submits a (DB record) print request, and the server blindly tries
to talk back to the client's printer at the old address, not bothering to
re-resolve.

The only way to cure this appears to be to kill and recreate the printer
connection on the server, which forces the Print Spooler service to resolve
the client correctly *until* it logs off/on, at which point you start all
over again.

An ideal candidate for a DHCP reservation, I hear you cry - except the W2k3
VPN server does not appear to honour the DHCP discovery process. If you
look, the VPN server will grab a block of 10 IP addresses from the DHCP
server, and allocate these to a client directly, rather than do a
passthrough and allow the DHCP server to see the clients MAC address - check
in DHCP MMC once the client is on and you'll see the IP address allocated to
the client shows a MAC identity of "RAS", as opposed to the Ethernet MAC
address for a client coming across a piece of direct cabling.

So am I missing something obvious to either:
(a) Get the servers Print Spooler service *not* to hold the old IP,
(b) Get the VPN server to honour the DHCP discovery correctly, so
the DHCP server can allocate a reservation to the client,
(c) some other workaround or
(d) a note that states what is required will *never* work, and the
application developers should change this brain-dead printing
procedure

Thanks for any pointers...

 

[Bill Grant]

A PPTP client cannot get its IP and other settings directly from DHCP.
The allocation is part of the PPP/PPTP negotiation process between the
client and server. That is why the server leases a batch of IP addresses
from DHCP (unless you give it a static pool to use). As far as the DHCP
server is concerned, they are just assigned to RAS. It has to be done this
way because the IP is only assigned for the duration of the connection, not
for the DHCP lease time.So you cannot use DHCP reservations for remote
clients.

If the remote clients get IP addresses in the same subnet as the LAN
machines, they will use MAC addresses for communication on the LAN. The
server just puts the traffic on the wire. The LAN machine replies on the
wire. The server does proxy ARP for the remote client, gets the packet and
forwards it over the VPN link.

 

[Pat Hurt]

Gotcha - OK, makes more sense now as to the whys and wherefores. Many
thanks.

Having revisited for the Nth time, looks like the Print Spooler service on
the internal server has now also started to play by the rules, although I
can't recall changing anything from previous setup attempts - it still tries
to resolve the printer access using the old IP address if the client comes
straight back online under a new IP, but will eventually flush the old IP
from its cache and requery, whereupon everything starts working as
designed...