I want to connect to a Cisco Anyconnect VPN (which I believe does NOT act as a proxy -- my IP address doesn't change when connecting to this VPN).
However I wish to hide my true IP to the Cisco Anyconnect server I'm connecting to.
Can I connect to another VPN service like TunnelBear first, then connect to the Cisco Anyconnect server, and be sure the Cisco Anyconnect server is seeing my TunnelBear proxy IP and not my real IP?
The scenario you are describing should be possible, using the technology you described. I would assume the sequence of events would follow:
Initiate OpenVPN connection
Initiate Cisco VPN connection
However, keep in mind that you may need to install a client to access the Cisco VPN. These clients tend to interact with and potentially manipulate your operating system's network configuration, this makes sense when you consider that these applications are built to re-route your network traffic. These clients would most likely have the ability to see your VPN configuration.
A possible workaround to the issues outlined above, regarding the local client being able to recognize your network configuration: one might configure their host's entire gateway (router or perhaps virtual machine host) to route traffic through the primary VPN.
You should keep in mind the resource usage and computation power required in order to maintain each VPN's security and (possibly) compression layers.
Even if the second VPN connection is established, I wouldn't expect quality performance, and multiple compression layers could be suboptimal.
Related
What I'm trying to achieve is:
Connect to a VPN as client and route all my internal network's traffic over the VPN.
Run a VPN server, so that people from outside can connect to my internal network and get routed over the a.m. VPN client.
I'm trying to achieve that with a router running dd-wrt (netgear D6200), and / or a raspberry pi.
Can someone tell me if this can be achieved, and if, direct me to what would be a possible solution?
(I'm not looking for a tutorial, just a direction)
Thanks!
This thread probably does not belong here.
Consider using OpenWRT instead of dd-wrt. OpenWRT gives you a usable build system and easier to customize and build. I am not advocating OpenWRT. This can be a stop gap measure.
You can setup a OpenVPN server and OpenVPN client using the standard
documentation available on OpenWRT Wiki and also OpenVPN site.
Add to OpenVPN server.conf the following directive redirect-gateway def1. This will push the default gateway to clients connecting to OpenVPN server. Further, make sure you are using a unique network IP pool for VPN clients and does not clash with the remove VPN server.
Make sure you are masquerading the VPN traffic (Clients of local VPN server) before forwarding to remove VPN server. This can be tricky as this interface does not exist at boot time. It needs to be configured using up and down scripts
Make sure you are allowing traffic (clients of local VPN Server) on VPN interface to be forwarded in your firewall rules
Before setting up the OpenVPN server, make sure
The remove VPN server is pushing the default gateway to your VPN
client
You have setup the firewall correctly
You are able to reach the cloud through the Remote VPN Server. Checking with some site like www.whatismyip.com will help
Yes this is possible with dd-wrt on Netgear.
There is no need of Raspberry (unless you meant to run the remote VPN server on it).
Configure and run VPN server on dd-wrt - and try connectivity by connecting clients. Both tun/tap should work in general (with VPN client running). I tested with tun.
Configure and run VPN client on dd-wrt and try connecting to your VPN server. By default, the router should start directing all traffic (for its own LAN clients) via the VPN server.
So far so good.
The problem comes when you want dd-wrt's VPN clients (and not just LAN clients) to take the same route. With a VPN client running on dd-wrt, dd-wrt's own VPN clients will not be able to connect to the VPN server running on dd-wrt as such. To make it work, see below.
This is only possible via PBR - i.e. you run VPN client on dd-wrt, but take the router itself off this client, and route only specific clients through this VPN client running on dd-wrt.
With some tweaks using subnet masks, it is possible to include all your LAN and VPN IPs in the PBR policy so that everything (except the router itself) routes through the remote VPN server.
The key is to include dd-wrt's VPN clients' virtual IPs in the PBR. While configuring VPN server on dd-wrt, there is a field for specifying the clients' network and netmask.
If you use this network IP and netmask in client process's PBR policy, your (dd-wrt's) VPN clients will be able to connect to the VPN server running on dd-wrt, and will in turn be routed through the remote VPN server to which dd-wrt is connected as a client.
Is it possible to be connected to more than one VPN connection? I tried it with a second operating system running on virtualbox, my host is connected to a VPN and my guest runs another connection. Which IP should am I be visible when I use the browser of my guest? Is it the IP of my host or my guest or do this connections run parallel because of the gateway and the routing table? Is a simpler solution without virtualbox possible?
At least in theory, you can have as many VPN connections as you want.
Sometimes there are some firewall / protocol limits, such that you cannot
start a new vpn connection through another. Latency also increases fast
when you stack too many VPN connections.
It depends on the configured routes when you connect to a new VPN,
whether the new VPN connection goes through existing ones or is completely
independent.
I found a tutorial that shows you how to create server and client programs, and make them communicate over a network.
http://www.win32developer.com/tutorial/winsock/winsock_tutorial_1.shtm
I can make a client program connect to, for example, 192.168.0.4 on my local network, and I can make it connect to 74.125.225.96. But what if I wanted to make it communicate with 192.168.0.4 on the network of 74.125.225.96, instead of just the default server on 74.125.225.96? I'm having a difficult time finding the answer with Google.
Is there even a way to do this? If not, then how are Gnutella and Bittorrent, able to connect computers directly together to share files?
To do what you are asking, 74.125.225.96 would have to be assigned to a router that is configured to forward inbound connections on the target server port to the machine that is running 192.168.0.4.
BitTorrent and other file sharing apps use various techniques, like NAT traversal, hole punching, etc to get connections through routers and firewalls. For example, if one party is behind a router/firewall and the other party is not, then the two apps first try to connect to each other in one direction, and if that fails then they reverse roles - client becomes server and server becomes client - and they try again. If that still fails, they could then connect to a middleman server that both parties have access to, and let it delegate the connections.
Some background first. I have a .net client agent installed on each of the machines in the lan. They are interacting with my central server [website] also on the same lan.
It is important for my website to figure out which of the machines can talk to each other. For example, machines of one subnet cannot directly talk to machines of another subnet without configuring the routers and such. But machines in the same subnet should be able to talk to each other directly.
The problem I am facing is when the lan setup is like in Figure 1.
Because Comp1, Comp2 and Comp3 are behind a router, they have got the ipaddress 192.168.1.2 till 192.168.1.4. My client agent on these machines report the same ipaddress back to the server. However, machines Comp4, Comp5 also have the same ipaddresses.
Thus, as far as my server is concerned, there are 2 machines with the same ipaddress. Not just that, because the subnet mask is 255.255.255.0 for all machines, my server is fooled into thinking that Comp1 can directly talk to Comp5, which is not possible.
So, how do I solve this? What do I need to change in my client or in my server, so that I can support this scenario. These two are the only things in my control.
EDIT: Seems that the network diagram
is over simplified and there could be
multiple router/subnet levels. My
original answer will not handle this
scenario. Also, with the restriction
of modifying only the client app or server
app and not tampering with the
routers and firewalls makes
it more difficult.
EDIT2: Using 'arp -a' you can extract
the MAC address of the router. If the
client apps can manage to do this then
the puzzle is solved!
The client app knows the local machine address and passes it to the server app.
The server app knows the remote address when a connection comes in. This would be machine address or a router address.
From these two values you can work out what you ask.
For example:
Server app receives connection from 10.10.10.2 with client supplying 192.168.1.2
Server app receives connection from 10.10.10.3 with client supplying 192.168.1.3
The 'remote address' distinguishes the subnets.
So, all you need to figure out is how to extract the remote address of a client connection. If you are using any of the popular web technologies for your server app then this is very easy.
One approach is for the individual client machines to determine who they can see using a broadcast message. Have each client listen on some particular UDP port, and each client broadcast its presence to whatever the local broadcast domain is. When clients can see each other in this way, they can probably also make TCP connections to each other.
If the server needs to know which clients can talk to each other, just have the clients tell the server.
If the network diagram is complicated enough I think if would be very difficuilt to find what you need.
You should also take into account that Comp1 can establish direct connection to Comp6.
The solution I can suggest is probing. Client receives list of all other clients from server and tries to establish connection to each of them. I think that would be the only way to know which clients are REALLY accessible assuming any number of routers/firewalls/NATs in the network. Doesn'r scale much for a big number of computers of course.
I was wondering that how application like skype ( a popular chat client ) works in local network with one router, How it can listen on particular port?
for example:=
In one network A and B are two machines running skype , gateway of both is G1,
now how A and B will have same IP on internet that is of G1, but how can they ensure that they are listening on different ports? How can they ask to router G1 for unique port.
I want to make a simple text chat server on linux. How can I have connections between two different computers in two different networks?
Solution to your problem is to have a forwarding server somewhere in the net.
Different programs use different means to connect to each other. But every chat server, including Skype, has a server, which forwards data or information about subnet IP/port availability.
There are two types of clients: "listening" clients and "passive" ones. Listening clients have direct access to Internet via router port forwarding, and "passive" ones have to use additional tricks to get their hands on external data, line external servers or additional ports to listen.
The point is, not clients connect to each other, but they connect to a server, which then connects back to them to verify they are available, and, if at least one of them is not firewalled, direct another on to connect to the first one, excludint itself from further communication. And if both are firewalled, then is has to forward their messages through itself.
Host Discovery
Manual discovery, client A knowns who client B is
Discovery through broadcast UDP which is used by lot of games for LAN play. A client sends out a packet to the broadcast address for their subnet. The peers can choose to pick up this broadcast and respond. The downside is that this is limited to the current subnet. The more general INADDR_BROADCAST (255.255.255.255) works for all subnets on the local-link, but it cannot be routed, so won't work over internet (this is what DHCP auto-configuration uses).
Discovery through a central (Rendezvous) server. Each individual client knows the address of the server, and the latter informs them about each other. This technique is used by IRC, Voip, IMs and by most 'peer-to-peer' networks.
Communication
After the initial discovery is done you want to be able to talk to eachother. On the internet this can get tricky. Most people nowadays have their own router and sit behind a NAT, so direct connections are impossible.
Using a Rendezvous server, you can possibly talk to each other using the server itself. client A tells the server what to say, and it in turn tells client B, since both clients have an outbound connection to the server.
It is possible for the clients to talk to each other without the server proxying. This requires either DMZ, port forwarding or UPnP. DMZ will basically forward all incoming connections on all the ports to a given local IP. Port forwarding only forwards certain ports to local IPs. UPnP is a bit more advanced, the client requests that the router temporarily forwards a port to it, and you tell the other client via the rendezvous server where to connect.
Chatting app implementation
The easiest solution to your problem is most likely to use a central server, which is known by all the clients, that proxies host discovery and possibly the communication between the clients. If you want the clients to communicate directly, you can just proxy host discovery, and then let either DMz, manual port forwarding or UPnP do the rest.
Another solution would be to just have direct communication through NAT traversal techniques discussed above, and do manual host discovery.
Yet another solution would be to use a public webserver and 'abuse' its ability to insert content to chat with each other.
You need a central UDP Rendezvous Server.
After the initial connection from the client to the server the UDP clients can be redirected to talk to eachother directly even if firewalled.
The trick is to open an UDP connection from the inside.
Check out Real-Time Media Flow Protocol and how they use it.
Check out UDP Hole Punching
alt text http://labs.adobe.com/technologies/stratus/images/p2pvideo_250x215.jpg
Traditional NAT servers replace the source address and port with the address and a random port number of the external interface of the NAT server. This works well for simple protocols such as HTTP and SMTP, but it can create problems for more complex protocols that require multiple response ports on the external interface of the NAT server. NAT servers also aren’t aware of information stored in the data portion of the application layer header without the help of NAT editors and similar software fixes.
Windows XP’s answer to these problems is NAT Traversal, which can automatically allow the UPnP-enabled NAT client application to communicate with a UPnP NAT device. NAT Traversal provides methods to allow the UPnP client to learn the public IP address of the NAT server and to negotiate dynamically assigned port mappings for UPnP NAT client applications.
NAT Traversal features can be built into any hardware device or software application. Applications that commonly cause troubles for NAT devices but work well when UPnP-enabled include the following:
Multiplayer Internet games
Audio and video communications
Terminal Services clients and servers
Peer-to-peer file sharing applications
When these applications are UPnP-enabled, access through the Windows XP ICS allows them to work seamlessly.
Unless A and B are actually "listening" to the responses to outgoing requests, your router will need to be cofigured to forward the relevant port numbers to the relevant hosts. This isn't something that you can request in the code, it's something you need to configure on the router itself.