I am running an experiment and looking to block all VPN requests on my home network.
Current network:
Modem provides cable internet connection, port blocking, firewall & wifi.
PiHole provides DHCP & access to upstream DNS (cleanbrowsing).
Most modern VPNs appear to use port 443 to hide their tracks and this is what's creating the challenge. I've looked into both DPI and VPN lists and both have their flaws (DPI is resource intensive and seems to return numerous false positives, VPN lists appear exhaustive and seem to often lag behind VPN availability).
What's the best step forward here? I'm open to a solid list, but have yet to find one that works well, and open to DPI and other technologies but am trying to keep this cost-effective.
Related
I have a raspberry pi connected to my router with a local IP. I want to access the raspberry pi from outside (from another country) the local network via web browser. So, I have purchased a VPS which has its public IP.
Now how can I assign this VPS IP to the raspberry pi or any other local devices?
how can I assign this VPS IP to the raspberry pi or any other local devices?
That's not how the internet works.
In short, the VPS provider has a pool of IPs and it or its ISP is responsible for publishing routes to the rest of the internet, informing the rest of the internet how to route to those IPs.
You can't just "move" the public IP to your local network; the rest of the internet won't route traffic to it. It would be kind of like writing "1600 Pennsylvania avenue" on the front of your house - you wouldn't cause you to get White House mail, right? Because regardless of what you write there, the post office doesn't use it as a source of truth for mail routing.
There's a few of the options you have:
use ngrok to expose an endpoint to your local service. Ngrok's servers can proxy connections back to your local environment without it having to be online. This will be accessible by anyone on the internet, but is more obscure than an ipv4 address which can and will be easily found (see below). This is a quick and easy solution, and what I'd recommend in your case.
you already have the VPS. Run the code there instead of on the raspberry pi. It will almost certainly be more reliable and higher speed than your home internet.
you also already have a public IP, assuming your pi's local router has a route to the internet. the router is performing NAT so that devices "behind" it with only internal addresses can still communicate with the world. You can almost certainly configure your router to forward a certain port to your pi's internal IP address.
set up a VPN between the private networks, or between the individual hosts on the private networks. This is a lot of work and will require more knowledge of IP networking. If this interested you, I'd recommend looking at Wireguard (recommended) or OpenVPN.
Finally, keep in mind that unless you do something to make it not the case, your service, once on a public IP, will be accessible from the wide world. Since IPv4 space is pretty small by 2022 standards, and there are only 65000 some IP ports per address, it won't take nefarious parts of the internet long to find your service. You can't hide in the obscurity of an IPv4 network.
If your public address is ipv6 instead, those are essentially unguessable and much more likely to go unnoticed. Same thing is true of ngrok - since it has very large set of potential URLs, it's hard to guess. Still, I'd set up some sort of authentication in front of the service. It's just good practice, like locking your house.
Run this on vps:
echo "GatewayPorts yes" >> /etc/ssh/sshd_config
And this on your raspberry pi:
ssh -L remote-port:localhost:your-local-port your-vps.com
You will access server using: your-vps.com:remote-port
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.
This is more of a theory question for more understanding.
In order to do port forwarding we update sshd_config and provide the information of local port(a) and remote port(b) among which we need to perform forwarding. After this forwarding config is done, ssh tunnel will be used to forward packets between a <-> b.
But internally, how does this work? when I do https://localhost:a, how does packet move from port a to ssh tunnel port 22 and on the other side from port 22 to port b?
If you are interested about the internals, openssh is the most popular implementation of SSH protocol and it is open source with code available on GitHub.
To answer a bit your question, it works as every other network communication. If you are not familiar with it, check how network socket works. Port forwarding is doing just proxy between the ends and sends the data inside the encrypted channel, instead of outside as the direct socket would.
Anyway, it is easier to google a bit. Ubuntu has a nice explanation in their documentation:
To get the most out of port forwarding, it's helpful to know a bit about how the Internet works.
The Internet assigns computers virtual "ports", a bit like the USB ports on the back of your computer:
To let a digital camera share pictures with your PC, you connect the USB port on the camera to any USB port on the PC. The computer then talks to the camera about your photos, and shows you the result.
To let a web server share pages with your PC, you connect the web server port on the server to any Internet port on the PC. The computer then talks to the server about your page, and shows you the result.
Unlike a USB port, there is no physical component to an Internet port. There's no actual wire, or actual hole on the back of your computer. It's all just messages being sent over the Internet. Like other "virtual" computer concepts, Internet ports are just an analogy that help to explain what your computer is doing. Sometimes, that analogy breaks down:
There are two types of Internet port: normal "TCP" ports and strange "UDP" ports (which won't be covered here).
Unlike USB ports, every computer has exactly 65,535 numbered TCP ports, some of which have a special purpose. For example, port number 80 is your web server port, so your web browser knows it should connect to port number 80 in order to download a web page.
Connections between Internet ports can be patched together, so a connection from computer A to computer B on port 12,345 could be patched through to port number 80 on computer C. This is known as port forwarding.
I'm trying to develop an applicaton for p2p communication between two android devices. In order to punch a hole through my NAT(s), I'd need to know my external ip address and port.
To that end, I've developed a java server on GAE to report my "remote" ip address and port. The problem is that on GAE I can get my ip address, but not my port. Without it, I'm unable to successfully punch the hole.
So, my question is what's the best, free method to find out my external IP address and port?
That's a question that has no answer with TCP.
Here's the problem: your "port" is not a fixed value. You don't have "an" external port. You typically get one dynamically assigned for each outbound connection.
As answers you should see from the test sites posted in another answer clearly indicate, it's a moving target (though it may stay stationary for a short time due to the browser using HTTP/1.1 keepalives and actually reusing the same connection, not just the same port)... but if you hit the site repeatedly, you'll see it either drift around randomly, or increment. Trying it from two different web browsers on the same machine, you'd never see the same port number -- the port corresponds to the specific source connection, not the machine sourcing the connection.
Sometimes, you may find that it's the same port number as the port your machine's stack opened for the outbound connection, but even when it is, it doesn't matter, because no traffic should be able to return to your machine on that port unless it is from the IP address and port of the machine to which you made the outbound connection. Any decent network address translating device would never accept traffic from another source IP address and/or port, other than the one you addressed in the outbound connection.
There is no standard, simple, predictable, reliable, or consistent way to punch a hole in TCP NAT and then exploit that hole for a peer-to-per connection. To the extent that such things are possible in a given NAT implementation, that is an implementation that is shoddy, broken, defective, and insecure.
See also: https://www.rfc-editor.org/rfc/rfc5128
Sounds like your app could use a STUN server to get its external address.
My goal is to have two laptops in a network. One is acting as a server, serving webpages to the other. The catch here is that neither is connected to the outside internet.
What I have done so far is setup WAMP on the server laptop, and it successfully serves web pages on localhost. Now I want to access these pages on the other laptop.
To do this, I had the server create an ad-hoc network and connected the other laptop to it, but I'm stuck - and I'm worried I'm not on the right track. I followed this tutorial but in the end I figured out that just explained how to spoof a text URL as an IP address, and not really what I was looking for.
So I guess I have two questions:
Is my method the best way to do this (with ad-hoc networks)? Is there some way to connect a laptop to a wireless router and have the laptop act as a server to another laptop?
If my WAMP and ad-hoc network should work, how do I connect other laptops to my server through the ad-hoc network?
Thanks!
I would suggest the first option: get a wifi router. Then you can assign static IP adresses from the routers private network or use DHCP server on the router. Hopefully you will have an option to reserve IP adresses on DHCP server so you dont have to check every time what IP adress the laptop acting as a server got. You use this address to access your web server. Also, you can use this router later as a gateway to the internet if you want.
In ad hoc mode you will probably get an address from 169.254.0.0/16 link-local scope, and you can check it by running ipconfig as #Robadob already suggested.
On your hosting laptop open cmd and call ipconfig look for the internal IP address on the network interface your hosting the ad-hoc network.
Enter that IP address into the browser on your client laptops web browser instead of localhost.
If that doesn't work, try other ip addresses listed by ipconfig (incase you used the wrong) and then check the properties of your ad-hoc network, windows firewall and any other firewall software to disable anything that might be blocking it.
An ad-hoc network is suitable option for what your doing, most people would probably use a switch or router though, however that requires hardware you probably don't have.