BlackHole IPs and NXDOMAIN

[James M. Dunn]

I have a scenario where our company allows users to VPN into our local network via Checkpoint's Basic Secure remote Application. I have noticed that when the users are logged into our network I see 192,168,x.x address in the HP's syslog.log -->>

inetd[15618]: telnet/tcp: Connection from unknown (192.168.1.3) at Thu Oct 26

This is what happens:
1: A telnet session is started from a client (192.168.x.x) to the HP Server.
2: Server does a {gethostbyname} on the 192.168.x.x Blackhole IP
3: Server gets a response from the blackhole servers outside the firewall and gets response back saying that its NXDOMAIN and then allows client to have a session.

The above telnet sessions works fine but in some cases it does not, for example if the route to the Blackhole Servers fails or is slow then the transversal of the query fails hence making the full cycle of the the telnet session to hang and the {gethostbyname} portion.

http://www.dnsstuff.com/tools/traversal.ch?domain=1.1.168.192.in-addr.arpa&type=PTR


My question to all is,

Is there a way to configure internal BIND to respond to all 192.168.x.x lookups internally, basically giving the receiving telnet server what it needs to complete the telnet cycle while disallowing external lookups to the Blackhole Servers and do this without having to create a bogus record for each potential IP address?

Thanks to all and I give lots of points!

JD

[Patrick Wallek · Accepted solution]

If they are just telnet'ing to a single HP-UX machine I would add the IP addresses to /etc/hosts and then modify /etc/nsswitch.conf to look at files first and then DNS.

hosts: files [NOTFOUND=continue UNAVAIL=continue] dns

This would entail adding a line for every 192.168.*.* address, but that could be scripted fairly easily.

[James M. Dunn]

This would entail adding a line for every 192.168.*.* address, but that could be scripted fairly easily.

I thought of this but man thats A lot O ip's dont you think?

I'd sure like to find a way for my internal BIND servers to handle this.

The Checkpoint's Enterprise Secure remote Application, the one you purchase gives all incoming users an real internal IP address and real hostname, this is the ideal way to do it, but I was hoping to find and temporary fix.

Points for you

JD

[Patrick Wallek]

I agree that that is a lot of IPs. But I'm not sure how your internal DNS could resolve those without adding them somehow.

[James M. Dunn]

Patrick,

You have a star now, I'd like to see an output of the script, just to see how long it really is.

JD

[Patrick Wallek]

Thanks for the points for the star!!! :)

Here's the script:

#!/usr/bin/sh

OCT3=1
OCT4=1

while ((${OCT3} < 255))
do
while ((${OCT4} < 255))
do
echo "192.168.${OCT3}.${OCT4} host${OCT3}${OCT4}" >> host_file
let OCT4=${OCT4}+1
done
let OCT3=${OCT3}+1
OCT4=1
done

I'm sure there are better ways to do this, but it's what I came up with in about 10 minutes.

Here's output statistics:
# wc -l host_file
64516 host_file

# ll host_file
-rw-r--r-- 1 root sys 1696720 Oct 26 10:59 host_file

[James M. Dunn]

eh gads the output file is LARGE!

Anyhow more points for you.

Congrats on the star.

JD

[James M. Dunn]

the script is missing a few, but I fixed it, thanks again

CIDR range 192.168.0/16 Netmask 255.255.0.0 Wildcard Bits 0.0.255.255 First IP in range 192.168.0.0 (network address) Last IP in range 192.168.255.255 (broadcast address) First useable IP in range 192.168.0.1 Last useable IP in range 192.168.255.254 Number of useable IPs in range 65534