NAP_VPN_stepbystep breaks in real world
so question... there documentation on setting vpn server protected firewall on dmz or isolated vlan vpn client connecting remotely via outside interface , having access internal devices?
preferrably cisco pix/asa due microsoft being such partners cisco.
the instructions nap_vpn_stepbystep works great in controlled lab environment described in document.
the network scenario designed have routing configured client has full ip connectivity internal network no limitations post nap enforcement.
when "vpn" interface configured , launched on client1, policies enforced via nps server , health checks run , golden.
did mention vpn server has software routing between internal , internet subnets because there interface in each network.... how conveniant...
*****this breaks down!!!
in real world, there no guaranteed physical connectivity vpn client home computer same subnet on vpn servers internet interface. in fact, interface should enabled on vpn server in real world should 1 interface either in dmz or isolated internal vlan.
also, in network infrastructures, there security boundry protecting internal network firewall.
i have cisco pix in lab , extended network scenario add pix device test mimic classic remote access solution.
with few modifications nap_vpn_stepbystep.doc place client outside pix vpn server on inside, vpn client computer registers , runs health checks , ok.
but.... devices on internal interface subnet ie.. file server, dc, nps absolutely inaccessible vpn client experience.
this not case in controlled vpn_nap_stepbystep instructions. reason why client1 able access internal devices after nap enforcement policies run on network outlined in stepbystep document, because client1 access servers due way network created.
in other words, network scenario stacked in favor of success
i dont know if has made vpn_nap_stepbystep solution work way configured in 99% of networks of today. think networks have cisco firewall or other third party firewall solution , microsoft have @ least documentation on type of scenario.
thanks,
preferrably cisco pix/asa due microsoft being such partners cisco.
the instructions nap_vpn_stepbystep works great in controlled lab environment described in document.
the network scenario designed have routing configured client has full ip connectivity internal network no limitations post nap enforcement.
when "vpn" interface configured , launched on client1, policies enforced via nps server , health checks run , golden.
did mention vpn server has software routing between internal , internet subnets because there interface in each network.... how conveniant...
*****this breaks down!!!
in real world, there no guaranteed physical connectivity vpn client home computer same subnet on vpn servers internet interface. in fact, interface should enabled on vpn server in real world should 1 interface either in dmz or isolated internal vlan.
also, in network infrastructures, there security boundry protecting internal network firewall.
i have cisco pix in lab , extended network scenario add pix device test mimic classic remote access solution.
with few modifications nap_vpn_stepbystep.doc place client outside pix vpn server on inside, vpn client computer registers , runs health checks , ok.
but.... devices on internal interface subnet ie.. file server, dc, nps absolutely inaccessible vpn client experience.
this not case in controlled vpn_nap_stepbystep instructions. reason why client1 able access internal devices after nap enforcement policies run on network outlined in stepbystep document, because client1 access servers due way network created.
in other words, network scenario stacked in favor of success
i dont know if has made vpn_nap_stepbystep solution work way configured in 99% of networks of today. think networks have cisco firewall or other third party firewall solution , microsoft have @ least documentation on type of scenario.
thanks,
hi,
i'm following on issue fyi forum. there static route missing 1 device. when added, vpn configuration works expected.
-greg
Windows Server > Network Access Protection
Comments
Post a Comment