Validate IP addresses and the systems are reachable on the network

From Secure Web Gateway
Jump to: navigation, search

Getting Started - The Preparatory Steps

To keep the discussion easy to understand and replicate, we will use an example, and set out the process in ordered sequence of steps. We will also include steps for validating to ensure if any of the steps may not have been correctly taken.

In our example

We are using a Linux based host for deploying our Kerberos based SafeSquid

  1. FQDN of our Linux host: sabproxy.safesquid.test
  2. IP address of our Linux host:

We have a Microsoft Windows AD setup

  1. FQDN of Microsoft AD Domain: safesquid.test
  2. FQDN of Domain Controller: ad.safesquid.test
  3. IP address of our Domain Controller:

We will use additionally use a Windows Desktop, just for the purpose of validating our efforts.

  1. FQDN of our Windows Test Desktop: windows7.safesquid.test
  2. IP address of our Windows Test Desktop:
Linux machine sabproxy.safesquid.test
Windows Active Directory ad.safesquid.test
Windows Test machine windows7.safesquid.test

Network Connectivity

On EACH of the 3 above computers do the following

  1. ping the Linux host IP address
  2. ping the Domain Controller IP address
  3. ping the Windows Test Desktop IP address

Run below commands on console(putty)


If any of the above seems to be unsatisfactory, fix the TCP/IP network configurations, before proceeding.

Validate that all our systems are using the same DNS provider

In a Microsoft AD based network, it is highly recommended to use the DNS provider that usually defaults to the Domain Controller itself.

On the Windows Systems these are specified in the TCP/IP configuration

On the Linux host view and confirem /etc/resolv.conf
Confirm that it reads as follows:

Run below command on console (putty)

vim  /etc/resolv.conf

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
search safesquid.test

On EACH of 3 systems use nslookup as follows to confirm that DNS is effectively serving our requirements.

Run below command

nslookup sabproxy.safesquid.test
nslookup ad.safesquid.test
nslookup windows7.safesquid.test 

root@sabproxy:~# nslookup sabproxy.safesquid.test

Non-authoritative answer:
Name:   sabproxy.safesquid.test

root@sabproxy:~# nslookup ad.safesquid.test

Non-authoritative answer:
Name:   ad.safesquid.test

If any of the above seems to be unsatisfactory, fix the DNS server configuration, by restarting the service or re-booting the Domain Controller host, before proceeding.

root@sabproxy:~# nslookup ad.safesquid.test

    • server can't find ad.safesquid.test: NXDOMAIN

If you face any issue as shown above, check monit service and verify

While doing configuration for SSO authentication if you give FQDN\IP in this format and select Bind method as "Negotiate" 

SafeSquid will create the stub zone for DNS resolution of your Active Directory server.

After completing the entire configuration when you save the entry, the file with stub zone will create with the name : safesquid.dns.conf (automatically)

An given path :(verify it)


Also it will automatically copy at given path:(verify it)


(Note: Monit service must be up)

root@sabproxy:/usr/local/safesquid/security/dns# cat safesquid.dns.conf

zone safesquid.test {
 type stub;
 masters {;};

root@sabproxy:/etc/bind# cat safesquid.dns.conf

zone safesquid.test {
 type stub;
 masters {;};

If safesquid.dns.conf  is empty, configure LDAP  for SSO authentication from SafeSquid Web GUI LINK  properly and then do above steps again to verify.

Note: Monit service should be UP.

Validate each of the systems has same time and preferably timezone

Ensure that the time synchronization remains same across all the 3 system

Confirm time synchronization using below command ( use the IP address or the FQDN )

root@sabproxy:~# ntpdate sabproxy.safesquid.test
17 Apr 11:31:44 ntpdate[20275]: the NTP socket is in use, exiting

root@sabproxy:~# ntpdate
17 Apr 11:32:20 ntpdate[20276]: the NTP socket is in use, exiting