Configuring IAG Network Connector for Full SSL VPN Access – Part 2 of 2
1. Introduction
The first part of this article explained how to configure the IAG Server to allow full network access using the Network Connector. Now it comes the time to connect the external computers to the network. This second part will focus on what needs to be done on the client side to allow that to happen.
2. Evaluating your Needs
As I mention in all my blogs about IAG, the granularity for endpoint compliance is really a differential on IAG. At the same time that we can create tight and restrictive policies, we also can create more relaxed policies. One thing that you will notice when you try to access the SSL VPN for the first time on a computer that is not compliance with the policy is the window below:
Figure 1 – Warning about computer’s compliance.
This is due the tight default policy that we have for the Network Connector. The figure below shows the default policy and what we need to be compliant to be able to access the remote resource:
Figure 2 – Default Network Connector Policy.
For compliance configuration on the client side, the recommendation is to follow the instructions IAG User Guide, chapters 5 and 7. This document can be downloaded from Microsoft Download Center.
3. Client Connectivity
Once the endpoint compliance has been met, the client can finally get access to the resources. When this happen the following items will be notice in the client side:
|
- The Network Connector balloon will show up on the right corner of the. |
|
- If you double click on the icon that appears on the right corner of the task bar you will launch the portal activity that will show the Network Connector started. |
|
- If you open the command prompt and type ipconfig you will see that the client received the IP configured on the IAG server. |
At this point the client is already a node that belongs to the internal network and can access the resources where it has permissions to.
4. Troubleshooting Network Connector
The Network Connector troubleshooter is composed of two sides: client and server. You can enable logs on the client side as well as on the server side. To enable client logging add the following keys:
HKEY_LOCAL_MACHINE\SOFTWARE\WhaleCom\Client\NetworkConnector
"log"=dword:00000004
"log\sniff"=dword:00000001
To disable it, just change the log value to 00000000. It is important to emphasize that this is used only for troubleshooting purpose due the high intensive log creation. The file will be created at %programfiles%\Whale Communications\Client Components\3.1.0\whliocsv.log.
Here an example of a successfully connection:
Part 1 – Service starting up
19.05.08 04:42:30.254 ::_tWinMain enter
19.05.08 04:42:30.254 Create service sync event (0)
19.05.08 04:42:30.284 CNcDialer::CreateSession enter
19.05.08 04:42:30.284 CNcOS::CNcOS enter
19.05.08 04:42:30.284 mj = 5
19.05.08 04:42:30.284 mi = 2
19.05.08 04:42:30.284 build = 3790
19.05.08 04:42:30.284 platform = 2
19.05.08 04:42:30.284 cs ver = Service Pack 2
19.05.08 04:42:30.284 eType = 200302
19.05.08 04:42:30.284 CNcOS::CNcOS leave {}
19.05.08 04:42:30.284 CNcAdditionalRoutes::Cleanup enter
19.05.08 04:42:30.284 CNcAdditionalRoutes::Cleanup leave {}
19.05.08 04:42:30.284 CNcDialer::CreateSession leave {0}
19.05.08 04:42:30.294 CNcSession::Start enter
19.05.08 04:42:30.294 Validating IP address - 0XED00007F
19.05.08 04:42:30.294 Validating IP address - 0X4600A8C0
19.05.08 04:42:30.294 CNcSession::_Init enter
19.05.08 04:42:30.294 Create event {0}
19.05.08 04:42:30.294 ::WU_LoadCommonConfiguration enter
19.05.08 04:42:30.294 cfg.device_threads = 1 {0x2}
19.05.08 04:42:30.294 cfg.device_buffers_size = 0 {0x2}
19.05.08 04:42:30.294 cfg.device_buffers_size = 4 {0x2}
19.05.08 04:42:30.294 cfg.tunnel_threads = 1 {0x2}
19.05.08 04:42:30.294 cfg.tunnel_buffers_size = 64 {0x2}
19.05.08 04:42:30.294 cfg.timeouts.net = 20000 {0x2}
19.05.08 04:42:30.294 cfg.timeouts.reg = 5000 {0x2}
19.05.08 04:42:30.294 cfg.timeouts.dev = 20000 {0x2}
19.05.08 04:42:30.294 cfg.timeouts.route = 15000 {0x2}
19.05.08 04:42:30.294 cfg.timeouts.maintenance = 20000 {0x2}
19.05.08 04:42:30.294 ::WU_LoadCommonConfiguration leave {}
19.05.08 04:42:30.294 CWioSession::Init enter
19.05.08 04:42:30.294 check status {0}
19.05.08 04:42:30.294 check sanity {0}
19.05.08 04:42:30.294 input flags: 0
19.05.08 04:42:30.294 input tun cfg: 64 KB x 1 tunnel threads (per cpu)
19.05.08 04:42:30.294 input device cfg: 4 KB x 1 device threads
19.05.08 04:42:30.294 input timeouts: 20000 (dev) / 20000 (net) / 5000 (reg) / 15000 (route) / 20000 (maintenance)
19.05.08 04:42:30.294 check input {0}
19.05.08 04:42:30.294 CWioSession::_OpenDmEvent enter
19.05.08 04:42:30.294 CWioSession::_OpenDmEvent leave {0}
19.05.08 04:42:30.294 CWioSection::Open enter
19.05.08 04:42:30.294 pfExists = 0
19.05.08 04:42:30.294 CWioSection::Open leave {0}
Part 2 – Starting Network Connector and open the session with the server
19.05.08 04:42:30.304 CWioWinsock::Load enter
19.05.08 04:42:30.304 CWioWinsock::Load leave {0}
19.05.08 04:42:30.304 CWioNIC::Open enter
19.05.08 04:42:30.304 type = Virtual
19.05.08 04:42:30.304 get list size {0x6f: 1280 bytes}
19.05.08 04:42:30.304 allocate list {0}
19.05.08 04:42:30.304 enum (list) {0, 1280 bytes}
19.05.08 04:42:30.304 set name {{B6EB736A-A20B-4C52-A13F-0D10575C90A1}}
19.05.08 04:42:30.304 set index {0x2}
19.05.08 04:42:30.304 set mac {00-ff-08-01-19-47-}
19.05.08 04:42:30.304 open key System\ControlSet001\Services\TcpIp\Parameters\Interfaces\{B6EB736A-A20B-4C52-A13F-0D10575C90A1} {0}
19.05.08 04:42:30.304 control set = 1
19.05.08 04:42:30.304 open WINS key {0 for 6bf340}
19.05.08 04:42:30.304 open CPL key {0 for System\ControlSet001\Control\Network\{4D36E972-E325-11CE-BFC1-08002BE10318}\{B6EB736A-A20B-4C52-A13F-0D10575C90A1}\Connection}
19.05.08 04:42:30.304 open NET key {0 for System\ControlSet001\Control\class\{4D36E972-E325-11CE-BFC1-08002BE10318}}
19.05.08 04:42:30.304 enum NET loop starts:
19.05.08 04:42:30.304 -> open \0000 {0}
19.05.08 04:42:30.304 -> open \0001 {0}
19.05.08 04:42:30.304 -> open \0002 {0}
19.05.08 04:42:30.304 -> open \0003 {0}
19.05.08 04:42:30.304 -> open \0004 {0}
19.05.08 04:42:30.304 -> open \0005 {0}
19.05.08 04:42:30.304 -> open \0006 {0}
19.05.08 04:42:30.304 -> open \0007 {0}
19.05.08 04:42:30.304 -> open \0008 {0}
19.05.08 04:42:30.304 -> open \0009 {0}
19.05.08 04:42:30.304 -> -> matched id (9 iterations)
19.05.08 04:42:30.304 CWioNIC::QueryReg enter
19.05.08 04:42:30.304 name = EnableDhcp
19.05.08 04:42:30.304 DWORD data read {1}
19.05.08 04:42:30.304 CWioNIC::QueryReg leave {0}
19.05.08 04:42:30.304 -> -> setting member flags (enabled = 1 ; dhcp = 1}
19.05.08 04:42:30.304 <- enum NET loop exits
19.05.08 04:42:30.304 CWioNIC::Open leave {0}
The registry key emphasize in red on the log above is the Whale Network Connector NIC Driver that is created. Although this NIC doesn’t appear on the Control Panel/Network Connections, it will be available on the Device Manager. You just need to enable the Show Hidden Devices, as show in the figure below:
Figure 3 – Whale Network Connector NDIS Driver.
Continue the log reading, we have the sessions:
· open virtual device
· verify virtual device properties
· allocate thread pools
· open device control
· device thread starts
· check status
· check input
· init srv peer
· connect
Those sessions will show minor details since they are smaller process in the logging. The next verbose session will be following one:
Part 3 – Building routing table
19.05.08 04:42:30.835 input ip = 10.1.1.151
19.05.08 04:42:30.835 input class = 10.0.0.0 / 255.0.0.0
19.05.08 04:42:30.835 input policies (servers) = 0x1 (arps); 0xff (dhcps, with static fallback)
19.05.08 04:42:30.835 input policies (other) = 0x3 (nsplit); 1 (anti-spoof)
19.05.08 04:42:30.835 CNcRouteTable::Load enter
19.05.08 04:42:30.835 CNcRouteTable::_AllocArrays enter
19.05.08 04:42:30.835 ::WU_RouteLoadTable enter
19.05.08 04:42:30.845 get size {0x7a, 1524 bytes}
19.05.08 04:42:30.845 alloc {0}
19.05.08 04:42:30.845 get array {0}
19.05.08 04:42:30.845 log entries {7}
19.05.08 04:42:30.845 ..01 00000001> 127.0.0.0/255.0.0.0 <> 127.0.0.1 (1)
19.05.08 04:42:30.845 ..02 00010004> 192.168.0.0/255.255.255.0 <> 192.168.0.80 (20)
19.05.08 04:42:30.845 ..03 00000001> 192.168.0.80/255.255.255.255 <> 127.0.0.1 (20)
19.05.08 04:42:30.845 ..04 00010004> 192.168.0.255/255.255.255.255 <> 192.168.0.80 (20)
19.05.08 04:42:30.845 ..05 00010004> 224.0.0.0/240.0.0.0 <> 192.168.0.80 (20)
19.05.08 04:42:30.845 ..06 00000002> 255.255.255.255/255.255.255.255 <> 192.168.0.80 (1)
19.05.08 04:42:30.845 ..07 00010004> 255.255.255.255/255.255.255.255 <> 192.168.0.80 (1)
19.05.08 04:42:30.845 ::WU_RouteLoadTable leave {0}
19.05.08 04:42:30.845 set base len {7}
19.05.08 04:42:30.845 ..loop: add ip interface {192.168.0.80 / 255.255.255.0}
19.05.08 04:42:30.845 ..check entry 127.0.0.0 / 255.0.0.0 -> 127.0.0.1 | 0x1
19.05.08 04:42:30.845 -> IPlbk
19.05.08 04:42:30.845 ..check entry 192.168.0.0 / 255.255.255.0 -> 192.168.0.80 | 0x10004
19.05.08 04:42:30.845 -> LAN
19.05.08 04:42:30.845 ..check entry 192.168.0.80 / 255.255.255.255 -> 127.0.0.1 | 0x1
19.05.08 04:42:30.845 -> IP
19.05.08 04:42:30.845 ..check entry 192.168.0.255 / 255.255.255.255 -> 192.168.0.80 | 0x10004
19.05.08 04:42:30.845 -> BC1
19.05.08 04:42:30.845 ..check entry 224.0.0.0 / 240.0.0.0 -> 192.168.0.80 | 0x10004
19.05.08 04:42:30.845 -> MC
19.05.08 04:42:30.845 ..check entry 255.255.255.255 / 255.255.255.255 -> 192.168.0.80 | 0x2
19.05.08 04:42:30.845 -> BC
19.05.08 04:42:30.845 ..check entry 255.255.255.255 / 255.255.255.255 -> 192.168.0.80 | 0x10004
19.05.08 04:42:30.845 -> BC
19.05.08 04:42:30.845 CNcRouteTable::_AllocArrays leave {0}
19.05.08 04:42:30.845 CNcRouteTable::Load leave {0}
19.05.08 04:42:30.845 CWioClient::_CheckRoutingConflicts enter
19.05.08 04:42:30.845 check route: 10.0.0.0 / 255.0.0.0 {type = virtual interface}
19.05.08 04:42:30.855 CWioClient::_CheckRoutingConflicts leave {0}
Part 4 – Verifying RRAS status for potential collision
19.05.08 04:42:30.855 CWioService::QueryStatus enter
19.05.08 04:42:30.855 CWioService::_OpenService enter
19.05.08 04:42:30.855 open SCM {0}
19.05.08 04:42:30.855 CWioService::_OpenService leave {0}
19.05.08 04:42:30.855 control interrogate {0x426}
19.05.08 04:42:30.855 close handle {0}
19.05.08 04:42:30.855 close SCM handle {0}
19.05.08 04:42:30.855 CWioService::QueryStatus leave {0x426}
19.05.08 04:42:30.855 CWioSession::_ConnectVirtualDevice enter
19.05.08 04:42:30.855 IP / Mask = 10.1.1.151 / 255.0.0.0
19.05.08 04:42:30.855 DNS (Primary) = 10.1.1.6
19.05.08 04:42:30.855 DNS (2nd) = 0.0.0.0
19.05.08 04:42:30.855 Wins (Primary) = 0.0.0.0
19.05.08 04:42:30.855 Wins (2nd) = 0.0.0.0
19.05.08 04:42:30.855 GW = 0.0.0.0
19.05.08 04:42:30.855 DHCP (V) = 10.1.1.150
19.05.08 04:42:30.855 Alloc Type = dhcps = 0xff, sfallback = 1
19.05.08 04:42:30.855 CWioNIC::ReleaseDhcpAddress enter
19.05.08 04:42:30.855 CWioNIC::ReleaseDhcpAddress leave {0x2}
19.05.08 04:42:30.855 CWioService::QueryStatus enter
19.05.08 04:42:30.855 CWioService::_OpenService enter
19.05.08 04:42:30.855 open SCM {0}
19.05.08 04:42:30.855 CWioService::_OpenService leave {0}
19.05.08 04:42:30.855 control interrogate {0}
19.05.08 04:42:30.855 close handle {0}
19.05.08 04:42:30.855 close SCM handle {0}
19.05.08 04:42:30.855 CWioService::QueryStatus leave {0}
Now that we know how the good log looks like, let’s see where we can find errors in the log:
Fictitious Scenario – After launch the Network Connector, I see the balloon on the right corner, however after some seconds I receive an error message saying: Whale Network Connector session failed. Server not responding (0x80004005) .
In this case you can enable the tracing on the client side and track it up the error message. Open the Log and search for 0x80004005. After that, keep going up and see where we have the first failed during the connection.
The error was appearing on “device thread exits” session:
19.05.08 05:11:46.359 wait {0}
19.05.08 05:11:46.359 close {0}
19.05.08 05:11:46.359 CWioThread::Stop leave {0}
19.05.08 05:11:46.359 CWioNIC::Close enter
19.05.08 05:11:46.359 CWioNIC::Close leave {}
19.05.08 05:11:46.359 CWioIoBuffersPool::Term enter
19.05.08 05:11:46.359 CWioIoBuffersPool::Term leave {}
19.05.08 05:11:46.359 CWioSession::Term leave {0}
19.05.08 05:11:46.359 CNcSession::Start leave {0x80004005}
19.05.08 05:11:46.359 NcDialer::_StopService enter
19.05.08 05:11:46.359 OpenSCManager succeeded.
19.05.08 05:11:46.359 OpenService succeeded.
As we know, during the connection the client first starts Network Connector on its own side, and then tries to connect to the server. Therefore the initial parts of the logs will not tell too much about the issue. But, if you keep looking up in the log you will see the following on the “wait for reply” session:
19.05.08 05:11:45.357 CWioSession::_SetSessionError enter
19.05.08 05:11:45.357 input msg = 'Server not responding'
19.05.08 05:11:45.357 input code = 0xf0
19.05.08 05:11:45.357 inidicated = 0
19.05.08 05:11:45.357 CWioSession::_SetSessionError leave {0}
19.05.08 05:11:45.357 CWioSession::_SetSessionError enter
19.05.08 05:11:45.357 input msg = 'generic error'
19.05.08 05:11:45.357 input code = 0xf0
19.05.08 05:11:45.357 inidicated = 1
19.05.08 05:11:45.357 CWioSession::_SetSessionError leave {0xb7}
19.05.08 05:11:45.357 CWioClient::StopSession enter
19.05.08 05:11:45.357 sync = 0
19.05.08 05:11:45.357 CWioVaProxy::Set enter
19.05.08 05:11:45.357 CWioVaProxy::Set leave {0x40}
19.05.08 05:11:45.357 CWioPeer::Term enter
19.05.08 05:11:45.357 state = 2
19.05.08 05:11:45.357 reason = 2
19.05.08 05:11:45.357 CWioPeer::Term leave {0}
19.05.08 05:11:45.858 CWioPeer::Term enter
19.05.08 05:11:45.858 state = 1
19.05.08 05:11:45.858 reason = 2
19.05.08 05:11:45.858 CWioPeer::Term leave {0x6}
19.05.08 05:11:45.858 CWioClient::_FullTunnelingUNSET enter
19.05.08 05:11:45.858 nothing to undo..
19.05.08 05:11:45.858 CNcRouteTable::Export enter
19.05.08 05:11:45.858 data flag = 0
19.05.08 05:11:45.858 CNcRouteTable::Export leave {0}
19.05.08 05:11:45.858 CWioClient::_FullTunnelingUNSET leave {0}
19.05.08 05:11:45.858 CWioClient::StopSession leave {0}
19.05.08 05:11:45.858 CWioClient::StartSession leave {0xf0}
Well, looks like server is not responding. But, why it is not responding? Keep going up in the log and look into the “init srv peer” session:
19.05.08 05:11:44.356 CWioPeer0::Connect enter
19.05.08 05:11:44.356 check input: <0> / 127.0.0.233:6004 {0}
19.05.08 05:11:44.356 CWioDTunnel::Connect enter
19.05.08 05:11:44.356 h = 532
19.05.08 05:11:44.356 CWioDTunnel::Connect leave {0}
19.05.08 05:11:44.356 CWioPeer0::Connect leave {0}
Here we know that the client was trying to connect to the Network Connector on the server side using the port 6004. However, by default the port is 6003, therefore there is a mismatch in the port. You can ask now: how come there is a mismatch if it is the server who provides this port to the client? That’s true, but there are two places where this port is defined, on the Network Connector Server / Advanced Tab and on the Network Connector Application Publishing / Server Settings / Port. In this case, the application publishing is telling the client to use this port, so we can pretty much conclude that the mismatch is on the server side and most likely in the publishing rule.
5. Conclusion
The above troubleshooting scenario was really simplistic, but the main goal was to get you familiarized with the error messages and how to track it the root cause for a problem. If you still don’t have try IAG yet, go ahead and download the demos and play with it.