XeroBank not encrypting MSN chats?

elumineX, using the technique outlined by Steve (XeroBank) in post #25, can you check and report whether or not OpenVPN is set to metric 1 on your PC. If it is already set to metric 1, then the locus the DNS problem must reside elsewhere. If it is not set to metric 1, then can you do so and repeat the DNS leak test to see if the problem is thereby corrected?

This thread is a great example of a “win-win” in which the collective community questioning and insight helps to drive a better anonymity service for all.

 

I'm really not sure where to do this. I did a "route print" in my VM and got the below result. I figured it must be inside the VM the metric could be wrong.

===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x2 ...00 0c 29 d3 92 61 ...... AMD PCNET Family PCI Ethernet Adapter - Packet Scheduler Miniport
0x10004 ...00 ff 97 83 b1 de ...... TAP-Win32 Adapter V9 - Packet Scheduler Miniport
===========================================================================
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 10.0.0.1 10.0.0.4 10
0.0.0.0 128.0.0.0 10.0.8.21 10.0.8.22 1
10.0.0.0 255.255.255.0 10.0.0.4 10.0.0.4 10
10.0.0.4 255.255.255.255 127.0.0.1 127.0.0.1 10
10.0.8.1 255.255.255.255 10.0.8.21 10.0.8.22 1
10.0.8.20 255.255.255.252 10.0.8.22 10.0.8.22 30
10.0.8.22 255.255.255.255 127.0.0.1 127.0.0.1 30
10.255.255.255 255.255.255.255 10.0.0.4 10.0.0.4 10
10.255.255.255 255.255.255.255 10.0.8.22 10.0.8.22 30
75.125.237.2 255.255.255.255 10.0.0.1 10.0.0.4 1
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
128.0.0.0 128.0.0.0 10.0.8.21 10.0.8.22 1
224.0.0.0 240.0.0.0 10.0.0.4 10.0.0.4 10
224.0.0.0 240.0.0.0 10.0.8.22 10.0.8.22 30
255.255.255.255 255.255.255.255 10.0.0.4 10.0.0.4 1
255.255.255.255 255.255.255.255 10.0.8.22 10.0.8.22 1
Default Gateway: 10.0.8.21
===========================================================================
Persistent Routes:
None

 

This will always be a game of catch up when you are using windows with VPNs. You can't set IP policies and route policies that just over-ride the whole thing, so it is possible to misconfigure your VPN to leak. Using bridging (I suspect this was the case) or Hamachi are great ways to make a VPN leak. Like JanusVM, it's just easier to say "not compatible with Hamachi". This is one advantage of the CryptoRouter. It can't leak, even if you do.

 

By the way, on my Windows Vista Business (32-bit) system, Automatic Metric was enabled for all Local Area connections, including the TAP-Win32 Adapter. My suspicion is that Automatic Metric is the default setting with Vista. If that is indeed the case, then does it mean that all users of xB VPN on Windows Vista are subject to DNS leaks (unless they change the Interface Metric from "Automatic Metric" to "1")?

With Windows Vista, the instructions for altering the Interface Metric are:

[1] Right click the TAP-Win32 Adapter in Control Panel | Network and Internet | Network Connections, choose Properties, select Internet Protocol Version 4 (TCP/IPv4), choose Properties, choose Advanced, disable Automatic Metric and set the Interface Metric to 1

[2] Repeat for Internet Protocol Version 6 (TCP/IPv6) with the TAP-Win32 Adapter

[3] Set the Interface Metric to Automatic Metric for all other Local Area connections for both Internet Protocol Version 4 (TCP/IPv4) and Internet Protocol Version 6 (TCP/IPv6)​

elumineX, do the above instructions help? If you can verify that the Interface Metric for your TAP-Win32 Adapter is set to "Automatic Metric" now, and show that the DNS leak disappears when the Interface Metric is changed to 1, then we will know for sure how to correct the problem.

Your assistance is most appreciated.

 

Automatic Metric won't apply to OpenVPN even if set on the adapter. When the OpenVPN process runs, it gets Metric 1 no matter what. The issue is for the adapters that *aren't* openvpn, they must always be lower. Naturally they will be unless you are bridging or have an ornery adapter competing for metric 1.

 

With the OpenVPN process running on my Windows Vista (32-bit) system, executing the “route print” command from a CMD window lists Interface = 10.0.24.26 (i.e., the “Canada.ovpn” connection) with Metric = 30 in the IPv4 Route Table. In fact, Interface = 192.168.0.2 has Metric = 20; but, all other listed in the Table have higher values. Is this an issue?

IPv4_Route_Table
===========================================================================
Active_Routes:
Network_Destination________Netmask__________Gateway_______Interface__Metric
__________0.0.0.0__________0.0.0.0______192.168.0.1______192.168.0.2_____20
__________0.0.0.0________128.0.0.0_______10.0.24.25_______10.0.24.26_____30
________10.0.24.1__255.255.255.255_______10.0.24.25_______10.0.24.26_____30
_______10.0.24.24__255.255.255.252_________On-link________10.0.24.26____286
_______10.0.24.26__255.255.255.255_________On-link________10.0.24.26____286
_______10.0.24.27__255.255.255.255_________On-link________10.0.24.26____286
________127.0.0.0________255.0.0.0_________On-link_________127.0.0.1____306
________127.0.0.1__255.255.255.255_________On-link_________127.0.0.1____306
__127.255.255.255__255.255.255.255_________On-link_________127.0.0.1____306
________128.0.0.0________128.0.0.0_______10.0.24.25_______10.0.24.26_____30
______192.168.0.0____255.255.255.0_________On-link_______192.168.0.2____276
______192.168.0.2__255.255.255.255_________On-link_______192.168.0.2____276
____192.168.0.255__255.255.255.255_________On-link_______192.168.0.2____276
_____192.168.13.0____255.255.255.0_________On-link______192.168.13.1____276
_____192.168.13.1__255.255.255.255_________On-link______192.168.13.1____276
___192.168.13.255__255.255.255.255_________On-link______192.168.13.1____276
____192.168.195.0____255.255.255.0_________On-link_____192.168.195.1____276
____192.168.195.1__255.255.255.255_________On-link_____192.168.195.1____276
__192.168.195.255__255.255.255.255_________On-link_____192.168.195.1____276
________224.0.0.0________240.0.0.0_________On-link_________127.0.0.1____306
________224.0.0.0________240.0.0.0_________On-link______192.168.13.1____276
________224.0.0.0________240.0.0.0_________On-link_____192.168.195.1____276
________224.0.0.0________240.0.0.0_________On-link________10.0.24.26____286
________224.0.0.0________240.0.0.0_________On-link_______192.168.0.2____276
__255.255.255.255__255.255.255.255_________On-link_________127.0.0.1____306
__255.255.255.255__255.255.255.255_________On-link______192.168.13.1____276
__255.255.255.255__255.255.255.255_________On-link_____192.168.195.1____276
__255.255.255.255__255.255.255.255_________On-link________10.0.24.26____286
__255.255.255.255__255.255.255.255_________On-link_______192.168.0.2____276​

​

So, to clarify, as long as all Local Area connections – including TAP-Win32 – are set to Automatic Metric, then there is no issue concerning DNS leaks with xB VPN / OpenVPN? Under this scenario, xB VPN / OpenVPN will get an Interface Metric value lower than all others – and, that is the ultimate desired outcome?

Thank you.

 

As long as you don't have any rogue adapters or bridged networks, you should be fine. We're writing some new code for xB VPN to help out with that by doing additional route checking.

 

I'm still confused about this. Steve, does it have anything to do with that I am running XB inside a VM? The VM has bridged networking to my host machine, but if that's the problem I can just make it share the host IP address through NAT, would that help?

What I am missing here is a thorough explanation of WHY bridged networking, and WHY metric 1, 2, 3 or whatever interferars with XB (or openVPN). I don't understand what Metric or bridged networking has to do with DNS leakage. I also do not understand if the DNS leak would apply to my host as well, if I was running openVPN in there and NOT inside the VM? My host has two VM cards (bridged networking again), but as I said before I can make it go through NAT as well in VMWare which you probably know already.

 

Should? How does one achieve a higher degree of certainity than “should” when using xB VPN / OpenVPN? Perhaps XeroBank will consider constructing a self-contained VMware appliance with a network protocol analyzer and a utility/script to test whether or not DNS leaks are occurring? This would be of benefit not only to users of xB VPN, but to users of all other anonymity solutions as well.

Yes, Steve, I second the request: can you kindly spend a few minutes and author a detailed note about this DNS leak problem with xB VPN / OpenVPN? I appreciate that doing so may be burdensome, but the issue discovered by elumineX is quite important.

Thank you.

 

This is probably best to be visualized. In lieu of awesome graphics, you'll get a quasi-difficult to understand explanation: Metrics are like driving lanes. Except instead of one lane being faster than others, they all go to a different place. The one that is metric 1 or closes to metric 1 is the route your likely going to take unless you have directions elsewhere through another metric to your local network. So unless you're looking for something on your network, you're traveling on the lowest metric. When you bridge, you just wiped all the lane lines off the road and any packet can go to any adapter. That's great for a failsafe of if you have to communicate and don't care where the packets are going. Yes, do NAT.

 

Hmmm. It may be possible. I'll need to think about it, there may be a better way.

The problem is the way the OS ip/routing policy is designed for Windows. If I was to have a birthday party, I would ask for a pinata of the windows ip policy so I could beat it silly. You definitely want to use xB Machine.


Yes, Steve, I second the request: can you kindly spend a few minutes and author a detailed note about this DNS leak problem with xB VPN / OpenVPN? I appreciate that doing so may be burdensome, but the issue discovered by elumineX is quite important.[/QUOTE]

Well, it's actually a known issue. That it was the problem for eluminex is incidental, we just don't often come across it.

 

I don't understand analogies very well. I'd rather have hard facts and hard to understand information presented, but thanks for the example it did shed some light on the subject.

For me, at least, I found a better description at the microsoft site. Perhaps you'd like to look at it too, Pleonasm. It's very informative. From http://support.microsoft.com/kb/299540:

 

elumineX, does this suggestion by Steve (post #35) in fact correct the DNS leak problem you have observed?

 

Apparently not. Using the NAT Ethernet setting in VMWare and listening to my physical network adapter on the host it still leaks DNS. However, the DNS requests look different in the either bridged or NAT mode. Hmm?

With NAT
Trying to reach www.aaak.dk (just a random address) gives me:
235 34.809431 10.0.0.2 212.242.40.3 DNS Standard query A www.aaak.dk
236 34.841049 212.242.40.3 10.0.0.2 DNS Standard query response, No such name
237 34.841457 10.0.0.2 212.242.40.3 DNS Standard query A www.aaak.dk.localdomain
238 34.892786 212.242.40.3 10.0.0.2 DNS Standard query response, No such name

With bridging
Trying to reach www.aaak.dk (just a random address) gives me:
42 17.315313 10.0.0.3 10.0.0.255 NBNS Name query NB WWW.AAAK.DK<00>
43 17.648840 10.0.0.3 74.55.55.162 UDP Source port: iad2 Destination port: openvpn
44 17.674753 74.55.55.162 10.0.0.3 UDP Source port: openvpn Destination port: iad2
45 17.675045 10.0.0.3 74.55.55.162 UDP Source port: iad2 Destination port: openvpn
46 18.059038 10.0.0.3 10.0.0.255 NBNS Name query NB WWW.AAAK.DK<00>
47 18.817631 10.0.0.3 10.0.0.255 NBNS Name query NB WWW.AAAK.DK<00>

 

elumineX, to summarize, the DNS leak occurs even when the XeroBank connection has the lowest Metric value; and, when there is no bridging. These are the two conditions discussed by Steve that might have been responsible for the problem.

Steve, your recommendations? While it is true that xB Machine or the Crypto Router might alleviate the difficulty, xB VPN itself still needs to be a viable solution.

 

I didn't play with metric yet, as I thought that was relevant only when bridging is activated?

 

Two problems can lead to the same conclusion. Yours isn't just bridging, it is the DNS settings in your OS. Your guest OS is performing forced DNS lookups outside the network. That means your guest OS is decidedly leaking, or not allowing DNS push from the VPN to be updated. Is your ISP in Denmark, because your DNS is being forced to look there and is routing DNS requests outside of the normal vpn network.

 

Yes it is in Denmark. Well my only concern is if this problem also persists if I am NOT running XB in VMWare, that is in a normal windows environment. We don't need to solve the VM problem right now since I bet most people doesn't see that as important. But it's very importnat that we can be absolutely sure that XB is anonymizing everything including DNS. If it doesn't then you are technically and law-wise providing a fake service. I don't want to pay for that, and I don't want others too either, which Im sure you can understand.

All this talikng, is something being done about this issue, and if it is when can we expect it to be fixed?

Thanks,
elumineX

 

Your Windows OS inside the VM is misconfigured, that is the reason why you're leaking DNS requests. It has only to do with the OS you installed and the software and settings you gave it, and has nothing to do with the service of course.

Let's forcibly update your DNS inside the OS:

1. Go into the OS
2. Open up a command prompt
3. Make sure you know your network Local Area Connection name in Network Properties.
4. netsh set address name="Local Area Connection" source=dhcp
5. netsh set dns name="Local Area Connection" source=static addr=4.2.2.2 register=NONE
6. netsh add dns name="Local Area Connection" addr=4.2.2.4 index=2
7. netsh set wins name="Local Area Connection" source=dhcp

This will statically force an update of the DNS server, assuming the name of your LAC is correct.

I think another way we would do it is go to the network properties, right click on the connection, go to TCP/IP, and turn off automatic DNS and specify 4.2.2.2 or some other static DNS. As long as the DNS isn't on your local network (denmark), it will get routed through the TAP adapter.

As to what is "being done" about this "problem"... well I agree it is certainly an issue, but it is a user misconfiguration issue that can be caused by any haywire problem that has access to machine because windows has no IP policy. Luckily most software doesn't try to mess with network settings. This is something you should call microsoft about and complain, as fruitless as it is. The alternative, and something we're considering, is writing some sort of process to monitor your DNS routing policies, because they are either ignored or over-written in your specific case. So it would require constant vigilance and rechecking all the time.

 

elumineX, the recommendations of XeroBank in post #43 are thematically similar to those documented in post #21. Will you kindly give these a try, and post your observations?

* * * * * * * * * * * * * * * * * * * *​

Steve, the objective of elumineX in this thread, as I understand it, is to assess whether or not xB VPN is encrypting all traffic. The process so far is complicated, and probably beyond the capabilities of most readers of this thread. Putting aside the approach that has been discussed to-date for the moment, is there an entirely different (and easier) way to independently verify the proper operation of the XeroBank service?

Thank you.

 

Well, in theory if the light is green, you're encrypting. The question is if the OS is messing up, as anything that hits xB VPN gets encrypted.

As to the question if there is a way to independently check from inside your natural OS, that is a circular logic. Your OS can't verify it's own operation is successful, only that it is unsuccessful. Verification of success requires an independent party outside the OS in question. That is true for all operating systems and all networks. For a user, they should use xB Machine to be "sure" as it won't leak and has IP policy and you can check it in accordance with the above principle. Does this mean windows users are out of luck? No. Of course not. Just run your OS virtually... how can we do that?... maybe there is a CD we could create that runs your native OS virtually mounted inside another OS of the boot. I'll see what can be done in theory.

 

We have way. What you can do is burn the xB Machine ISO, boot into xB Machine, and then mounting your normal operating system from inside xB Machine. Amazing, right? I need to test how well this will work with windows, as presenting it with different hardware could lock up your xp/vista OS as a piracy prevention measure. So that will have to be beaten, which can easily be done, but be safe, which is harder. Can it be done? We just did it. Needs a little more testing before I can feel comfortable passing the techniques into public knowledge.

 

Sorry, I can't do more testing atm. I'm on my Linux machine right now and don't have access to my VM's. I'm going on vacation soon too. Perhaps when I come back I can take a look if it is neccesary.

 

If I am using XB VPN, it *does* encrypt all outgoing traffic.....if I use it as is. Is this correct?

Is the crypto router you are talking about the "coming soon" product on the website? If it truly *cannot* leak, I would love to have one. I just hope that it is affordable.

 

Assuming you didn't already have a misconfigured network that was setup for leaking/bridging, yes, xB VPN will encrypt all your traffic. The cryptorouter beats all of that. All traffic is encrypted, regardless of misconfiguration.