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" <(E-Mail Removed)> wrote in message
news:c4d2l0$nik$(E-Mail Removed)...
> 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...
>
>
|
Similar Threads
