I am running a VPN in windows 10 desktop (using OpenVPN) and the VPN is the default gateway, so that all traffic by default goes through the VPN tunnel.
However, I would like to exempt certain apps from the VPN, so that their traffic goes directly out the physical interface instead, by passing the VPN (so-called "split tunnelling")
I assume this solution would involve the WFP (Windows Filtering Platform) API, and perhaps the Windows equivalent of
setsockopt(sock, SOL_SOCKET, SO_BINDTODEVICE, device, sizeof(device))
I have this working in Linux currently via "cgroups" and policy-based routing/multiple routing tables.
But it is my understanding that Windows has neither policy based routing or multiple routing tables. But i can still think of a way of achieving this in Windows, but I cannot find the APIs to make it happen
One way is to hook the socket creation of a specific app and then use the windows equivalent of SO_BINDTO_DEVICE socket option (setsockopt()) to force the socket to be bound to the physical interface rather than the tap driver.
But, again, I cannot find the relevant APIs to make the above happen.
So I have a few questions:
(1) Is what i want to do possible within the given APIs of WFP (Windows Filtering Platform) or Windows APIs in genral? if so, which APIs do you advise i look at?
(2) Or, must i write a "WFP call-out driver" ? If so, would you be able to point me towards some resources for this, and possibility a good starting point for my particular problem? :)
(3) Is there anything else I might be missing? a simpler approach to achieve what i want? I know that it is possible in windows, as i have see the feature in some VPNs, but i would like to replicate it in my own personal VPN :)
Yes, you can force an app to use your VPN connection by copying and editing your (Windows) VPN connection.
Open the run prompt with: WIN+R
Type: ncpa.cpl
Copy your "old VPN" to APP_VPN (for example)
Open a Normal user Powershell
Change the new VPN connection with:
Add-VpnConnectionTriggerApplication -Name "APP_VPN" –ApplicationID "C:\path-to-your\game.exe" -Force
# Enable (Application) split-tunneling
Set-VpnConnection -Name "APP_VPN" -SplitTunneling $True
You can also check the VPN settings details in the phonebook in:
C:\Users\<User>\AppData\Roaming\Microsoft\Network\Connections\Pbk
Done!
Related
I am playing around with an application to do some remote connection and I am struggling with understanding the tun/tap. I have installed OpenVPN tuntap driver and can connect/configure it through my application but I need some clarification.
If I use it in TAP mode I need to bridge my network adapters correct??
How would a TUN interface be setup?? I know that I need to call DeviceIoControl with TAP_IOCTL_CONFIG_TUN and I think I understand how but my research leads me to think I also need to add into the windows routing tables??
Can someone layout what a typical TUN Layer3 VPN would look like
Thanks
Matt
I have to scan my Infrastructure and find it out the way I should use (WMI, SSH, SNMP, etc.) to discover the device details.
The approach I am following as of now is
Get the availability of device.
Query using WMI (If responding? use this protocol to discover this device)
If the above device does not respond to WMI use another protocol like SSH or SNMP (it's configurable) etc.
Is there any other way of discovery for a mixed environment? Please suggest.
The approach you are taking seems reasonable. Alternatively, you could have some existing software do this for you.
Are there any reasons for favoring named pipes over sockets for local IPC (both using win-api), effectiveness-wize, resource-wize or otherwise, since both behave very much alike (and likely to be abstracted by a similiar interface anyway), in an application that is likely to already use sockets for network purposes anyway?
I can name at least the addressing issue: port numbers for sockets against filenames for pipes. Also, named pipes (AFAIK) won't alert the firewall (block/unblock dialog), although blocked applications can still communicate via sockets locally. Anything else to take into account?
In the case of using sockets, are there any winsock settings/flags that are recomended when using sockets locally?
Some subtle differences:
Sockets won't work for local IPC if you don't have a functioning adapter. How common is it to have a PC without a functioning adapter? Well, I got bitten when somebody tried to demonstrate our software to a customer on a laptop that was not plugged in to a network or a power supply (so the OS disabled the network card to save power) and the wireless adapter was disabled (because the laptop user didn't use wireless). You can get around this by installing a loopback adapter but that's not ideal.
Firewall software can cause problems with establishing TCP/IP connections. It's not supposed to be an issue for local IPC, but I'm not convinced. Named pipes can have firewalls too.
You may have issues due to the privileges needed to create named pipes, or to create new instances of named pipes. For instance, I was running multiple servers using the same named pipe (probably not a good idea, but this was for testing) and some failed in CreateNamedPipe because the first server to create the pipe was running in Administrator mode (because it was launched from Visual Studio in Administrator mode) while the rest were launched from the command line with normal UAC level.
Although the article mentioned by Rubens is mostly about IPC over a network, it does make the point that "Local named pipes runs in kernel mode and is extremely fast".
Another solution you may want to consider is a named shared memory region. It is a little bit of work because you have to establish a flow control protocol yourself, but I have used this successfully in the past where speed was the most important thing.
The project I'm working on is to handle data capture from scan guns (Pocket PC 2003) and process this data on a host (Win XP) then into our inventory database on a separate server (Win 2000). This is all driven by the Remoting framework provided by MS and As Good As It Gets (http://gotcf.net). The application is complete enough for a general proof of concept with both the client and server working properly while in the emulator.
All is well until I began to test using actual scan guns. Due to security concerns, the scanners are on a separate network (for clarification the 10 network) than the server (the 15 network). My development machine has dual NIC connected to both networks and can communicate with both independently. However, I am having issues with my application receiving information from the 10 network using .Net Remoting, and then sending out information to the server on the 15 network via a third party app (Combination of ODBC, Btrieve, and OLE).
Is there anyway to process information from one network then update the server on another?
Any suggestions will be greatly appreciated!
Note: I'm not very familiar with networking, thus I may be calling it the wrong name but the gun IP's start with 10...* and the server IP's start with 15...*
So long as the computer's routing table is properly configured, you shouldn't have to worry about this from your application. So long as you're using the proper IP addresses, the networking stack should take care of delivering things to the right place.
You might want to check the output of "route print" (at least I think that was available on WinXp -- if not, someone else will likely post the correct command for XP soon). In any way, you should see what network destinations are configured for which interfaces. You'll need to make sure that the server's IP on the 15 network will properly route via the interface you want (ie. the lowest-cost matching destination/netmask lists your 15 interface).
The issue seems to stem from both the NIC cards not set up properly and a so far unresolved issue with the frameworks I've chosen.
To solve the NIC problem, the easiest solution I'd found had me clear the default gateway on the 10 network.
The other issue deals with recreating the remoting objects after they've been destroyed. I currently have to warm boot the scanner in order to re-connect to the host. In order to correct this issue I'm going to contact As Good As It Gets to see what their input is. Damn firewall
alt text http://img440.imageshack.us/img440/6950/problemyd1.png
(The curly lines with dots represent a network route.)
Having a process called "foo.exe", is there a way to forward everything it communicates over TCP/IP to a forwarding proxy located elsewhere? This forwarding should not reflect to other processes.
Another question: if there are multiple network adapters, is it possible to force a process to use one specific adapter.
Since in this example the targethost.com is known, I could just edit "system32\drivers\etc\hosts" to map targethost.com's IP to localhost, where on port 8765 would be the first forwarder waiting for an incoming connection and pass everything forward to proxy.foo.com. I was wondering if there's a more elegant way of doing this.
This is not for malware, I'm doing some network testing with my complex home network. Thank you for warning us.
Some free software for this would be perfect, alternatively a code idea (native or .net). Thank you very much.
It's not too hard if you make your own computer a firewall, then your app connects to a port on your own computer, and that port is forwarded to both the original destination and logged or forwarded on to your spying computer.
Alternatively you can make your other computer the firwall and have it log/forward the info.
Finally you could use a sniffer.
SocksCap will probably do the job (if you're OK with establishing a SOCKS proxy at proxy.foo.com).
You could hook into the TCP stack, for example, by using the Windows Filtering Platform or its predecessors, or you could substitute the network libraries/calls of that particular process.