# vpn, figuring out/confirming whose dns [solved]

## nordic bro

after tons of reading I'm confused as ever and wonder how to confirm things for myself?  this is all a big jumble in my head and know my post reflects that so sorry for not knowing what to include/exclude from it.

from my home computer I connect to my work through their vpn using openconnect.  I want only their specific web pages/work traffic using the vpn and everything else my non-vpn stuff.  last week I posted and it was confirmed that's more or less what I have now, but then it occurred to me later that non-vpn web page accesses would/could still be going to the vpn's dns IPs?  that isn't what I want.  

no vpn:

```
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0

127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo

192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
```

logged in to vpn:

```
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0

10.33.56.0      0.0.0.0         255.255.255.0   U     0      0        0 tun0

10.100.79.0     0.0.0.0         255.255.255.240 U     0      0        0 tun0

10.200.202.0    0.0.0.0         255.255.255.0   U     0      0        0 tun0

127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo

192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

192.168.196.0   0.0.0.0         255.255.255.0   U     0      0        0 tun0

192.168.197.0   0.0.0.0         255.255.255.0   U     0      0        0 tun0

192.168.197.3   0.0.0.0 *vpn dns 255.255.255.255 UH    0      0        0 tun0

192.168.197.4   0.0.0.0 *vpn dns 255.255.255.255 UH    0      0        0 tun0

192.168.198.0   0.0.0.0         255.255.255.0   U     0      0        0 tun0

209.work_IP     192.168.1.1     255.255.255.255 UGH   0      0        0 eth0
```

I got a lot of tools like tcpdump, traceroute and whatnot trying to see what happens when connected to vpn and loading something like slashdot in browser - if I never see either the work IP or any of the local vpn's IPs getting recorded that means I'm not accessing vpn stuff at all?  if I do "tcpdump -i tun0 -n" and get ~0 output for non-work browser page accesses that means they aren't going to any vpn IPs (dns or otherwise)?

I added dnsmasq only because it was in the gentoo vpnc how-to but aren't really sure I need it - it had me put 127.0.0.1 in /etc/resolv.conf:

nameserver 127.0.0.1

nameserver 192.168.1.1 (originally this was all that was there)

I edited openconnect.sh (vpnc-script basically) to prevent it from overwriting /etc/resolv.conf and if I didn't do that this is the resolv.conf the vpn would create:

nameserver 192.168.197.4

nameserver 192.168.197.3

search hostingcompany.com (different from work.com, my job)

since I don't let it put those in resolv.conf, might my machine not have any idea there even is a vpn dns to use?  or is there something in the 'vpn magic' that doesn't care its dns IPs aren't in my resolv.conf and somehow uses their own anyway?

the other thing is /etc/hosts:

```
127.0.0.1   localhost.localdomain localhost

#::1   localhost

192.168.198.21  www.work.com work.com
```

if I comment their 192* and load a work.com web page, it's completely blank; only if I uncomment it does the work.com page load.  does the vpn somehow know "if that IP isn't in /etc/hosts then don't let user access the page"?  why would this addr need to be in /etc/hosts?  ie what purpose does it serve by being there?

not knowing any better I added that to /etc/conf.d/dnsmasq hoping I could remove the work.com IP from /etc/hosts:

```
DNSMASQ_OPTS="-S /.machine-hostingcompany.com/192.168.198.21 \

         -S /.work.com/192.168.198.21"
```

but I'm still not able to remove it from hosts, so is the only thing I'd put in DNSMASQ_OPTS what the vpn would replace my /etc/resolv.conf with (but that I don't let it): 192.168.197.4 and 192.168.197.3?

so given the vpn dns IPs aren't in resolv.conf, aren't in DNSMASQ_OPTS, only the one unknown in hosts, and work/non-work stuff otherwise functions, does that mean I'm already not using any vpn dns?  or somehow the vpn doesn't care how things are configured on my side and will find its own way to vpn dns and I just won't know about it?

thanks for reading.Last edited by nordic bro on Fri Apr 19, 2013 1:10 am; edited 1 time in total

----------

## Hu

Most programs use the glibc resolver, which uses /etc/hosts and the nameservers in your /etc/resolv.conf.  It may use other things if so configured, but ignore those for now.  To resolve a name, those sources are consulted in order until a query is handled or all sources are exhausted.  If your /etc/resolv.conf specifies a nameserver that does not handle *.work.com specially (OpenDNS, your ISP's nameserver, etc.), then you will see the same IP addresses as the rest of us see.  If the resulting IP is on the VPN routes list, it will go over the VPN.  Otherwise, it will not.  These statements are applied separately, so it's possible, albeit unlikely, for your employer to run a configuration where they route slashdot.org connections over the VPN even when you get the correct address for slashdot.org from a neutral third party.  Similarly, and more probable, it's possible for your employer to resolve all DNS requests for you, but then have you use a non-VPN connection for addresses that resolve to the public Internet.  It appears this would have happened if you had not modified the openconnect.sh script.

The routing table you posted looks like only internal networks are routed over the VPN.  The blank webpage behavior is a bit odd, but could occur depending on what exactly you loaded, whether it is visible to the general public, and what exactly you meant by blank.  Does the connection fail?  Does it connect to a server which immediately disconnects?  Does it connect to a server which sends back a well-formed HTML page with no human readable content?

----------

## nordic bro

 *Hu wrote:*   

> If your /etc/resolv.conf specifies a nameserver that does not handle *.work.com specially (OpenDNS, your ISP's nameserver, etc.), then you will see the same IP addresses as the rest of us see.  If the resulting IP is on the VPN routes list, it will go over the VPN.  Otherwise, it will not.

 

ok thanks.  so since I don't let resolv.conf be changed, and the only IP of theirs in any of my known cfg files is the one in hosts I was wondering about, I would essentially know that those using routing tbl for vpn addrs are ones I don't care about (i.e., work.com stuff only)?

 *Quote:*   

> it's possible, albeit unlikely, for your employer to run a configuration where they route slashdot.org connections over the VPN even when you get the correct address for slashdot.org from a neutral third party.

 

presumably I could confirm if that was happening?  like using tcpdump or traceroute I would see it at some point using one of the vpn addrs from routing tbl?  or it could be completely hidden from me that vpn is handling traffic I didn't want it to?  

I noticed that when vpn is up and even if I'm not using any of the work.com browser pgs, 'tcpdump -ni eth0' shows small groups of these:

```
IP 192.168.1.254.45937 > 209.work_IP.443: UDP, length 14

IP 192.168.1.254.45937 > 209.work_IP.443: UDP, length 77

IP 192.168.1.254.43329 > 209.work_IP.443: P .... 
```

I did an lsof cmd and see this:

```
openconne  8322  ...  TCP 192.168.1.254:43329->209.work_IP:443 (ESTABLISHED)

openconne  8322  ...  UDP 192.168.1.254:45937->209.work_IP:443
```

the 192.168.1.254 ports (my computer's IP) are the same so I take it this is routine openconnect/vpn "are you there?" kinds of back/forth, and not that the work_IP is being accessed for resolving sites like slashdot?

 *Quote:*   

> The blank webpage behavior is a bit odd, but could occur depending on what exactly you loaded, whether it is visible to the general public, and what exactly you meant by blank.  Does the connection fail?  Does it connect to a server which immediately disconnects?  Does it connect to a server which sends back a well-formed HTML page with no human readable content?

 

I forgot to mention it but that blank pg I get when their IP is commented out in hosts file is an https pg that can only be reached by those permitted to log into that part of their site (e.g., me).  

what I see is the "https...work.com/something.php" I would normally see in browser location bar/tab, but the page itself is entirely empty.  I click the link a few times and keep getting the same thing.   I think what happens is that a short time after commenting out their hosts line (and restarting dnsmasq, aren't sure that's needed) their system has essentially logged me out (not of vpn session though) so I get the blank page and their login won't accept my credentials, login just keeps popping up over and over.  then shortly after uncommenting the hosts line (and restarting dnsmasq) it will allow me to log back in and the page will load fine and no longer be blank.

given the IP is in /etc/hosts and works from there, is that not the kind of thing I could use in DNSMASQ_OPTS instead?  as of now dnsmasq.conf is completely commented so it's all defaults - I tried using its "no-hosts" setting as an alternative to leaving the IP uncommented in hosts file but I'd just get the blank pg/no login I mentioned above.

I was hoping for a little more control over that since I'm guessing by having that IP in /etc/hosts who-knows-what could be accessing it, but if in dnsmasq I'd have more control over what gets to use the IP?

----------

## Hu

 *nordic bro wrote:*   

> 
> 
> ok thanks.  so since I don't let resolv.conf be changed, and the only IP of theirs in any of my known cfg files is the one in hosts I was wondering about, I would essentially know that those using routing tbl for vpn addrs are ones I don't care about (i.e., work.com stuff only)?
> 
> 

 Only addresses listed in the routing table as handled through tun0 will be sent over the VPN.  Yes, since you blocked the resolv.conf update, there should be no issues with them returning a VPN-routed address in response to a DNS query.

 *nordic bro wrote:*   

> 
> 
> presumably I could confirm if that was happening?  like using tcpdump or traceroute I would see it at some point using one of the vpn addrs from routing tbl?  or it could be completely hidden from me that vpn is handling traffic I didn't want it to?  
> 
> 

 You would see it in the routing table.  The routing table you showed is fine, but it could be changed by the VPN administrator later.

 *nordic bro wrote:*   

> 
> 
> I noticed that when vpn is up and even if I'm not using any of the work.com browser pgs, 'tcpdump -ni eth0' shows small groups of these:
> 
> the 192.168.1.254 ports (my computer's IP) are the same so I take it this is routine openconnect/vpn "are you there?" kinds of back/forth, and not that the work_IP is being accessed for resolving sites like slashdot?
> ...

 It is probably a keep-alive, yes.

 *nordic bro wrote:*   

> 
> 
> I was hoping for a little more control over that since I'm guessing by having that IP in /etc/hosts who-knows-what could be accessing it, but if in dnsmasq I'd have more control over what gets to use the IP?

 

Once the VPN is up, any program on your system can access that IP address.  The presence or absence of the entry in /etc/hosts only controls whether programs are able to resolve the name to that address.

----------

## nordic bro

I've been meaning to post a thank you for the help so "thanks!"  :Smile: 

you and depontius filled in lots of holes for me on this and after doing more reading following your last reply I feel like I have a pretty good handle on the topic now.  we'll see how long that lasts  :Laughing: 

----------

