I am interested in connecting to a web server I am running inside my home network on a Raspberry Pi. I have been reading up on how STUN servers work, and gather that they determine the port that the external facing router uses to redirect HTTP requests back to a device inside the local network.
I have an external website and I put a php file there to report back on the IP and port that requests come from. I can see that the requests come from the IP of my home router and each device uses a consistent port when a request is made.
If we assume my router has an external address of 123.123.123.123 and my Pi is allocated port 50500 for return requests I thought I would therefore be able to access the website on my Pi by using these combined as http://123.123.123.123:50500. However this does not work. Should this work?
(Note: port forwarding is not an option so please do not suggest that).
So I think the answer here is related to the fact that only UDP and TCP traffic are simple enough to get through the NAT using just the pi and port combination. I am trying to make a HTTP request over the same channel but this is more complex and therefore doesnt make it through.
That's pretty vague, and possibly not entirely correct. So I would love to hear from any experts in the field who can add more depth to this answer or correct me.
The ngrok is the easy and free one.
I setup webhook for social media in five minutes when develop IM robot .
There is a sample from Slack, but it apply to any social media or could solution which need webhook.
Related
In order to get some home automation software to work, I need to have public access to my Raspberry Pi 3. However, I currently reside in an on-campus dorm and as a result am on the college's network and do not have the ability to port forward.
I have a router that connects to the school network via Ethernet and then broadcasts its own network, however, this is still a part of the school's network and I can't port forward this.
I've looked into ways to get around this such as Page Kite, using some form of reverse SSH or HTTPS tunneling, but due to lack of support on Raspberry Pi or daunting setup I'm not really sure what to do. I do have an old HP laptop on Windows 7 that I could use as some sort of slave or server if that would help.
All help is very much appreciated. This has been a major roadblock in me finishing this project.
You don't say what kind of public access you're expecting, but without access to the main router you just need to signup for a dynamic DNS service with a client-based updating tool. All the most known ones (DynDNS Dynu, no-ip) all offer that option as far as I know.
The theory is that you keep the service updated anytime your internal WAN IP changes and they keep your hand-picked url updated with that IP. Then you can access your Pi with that IP thru a web browser or whatever service/port you've setup.
Here's a good starting article - with links to Dynu downloads for Linux that should work for you.
http://www.howtogeek.com/66438/how-to-easily-access-your-home-network-from-anywhere-with-ddns/
And an article from noip.com site on installing their Linux update client
https://www.noip.com/support/knowledgebase/installing-the-linux-dynamic-update-client/
We are attempting to use a Cisco ASA as a VPN as well as forward traffic to two servers.
Our ISP has given us a range of IP addresses that are sequential.
154.223.252.146-149
default GW of 154.223.252.145, we're using netmask 255.255.255.240
We have the first of these, 154.223.252.146, assigned to the external interface on our ASA and it’s successfully hosting our VPN service. It works great.
The next and final goal is to have 154.223.252.147 forward https traffic to 10.1.90.40 and 154.223.252.148 forward https traffic to 10.1.94.40.
Our current blocker is our inability to get the outside interface of the asa to respond to these ip addresses.
We’ve been able to use 154.223.252.146 to forward https traffic correctly. So we know that works.
I’ve plugged my laptop into the switch from our ISP and have successfully manually assigned 154.223.252.147 and 154.223.252.148 with the default gw of 154.223.252.145 and was happily connected. So we know the IP’s are there and available, we just need to convince the ASA to respond to them and use them to forward https.
We’ve tried plugging cables from the switch into other interfaces on the firewall. This failed because the netmask overlaps with our first outside interface 154.223.252.146 255.255.255.240, Cisco hates this and doesn’t allow it.
We’ve read documentation and have heard that it’s possible to assign a range of IPs to the ouside interface by defining a vlan. We do not know how to successfully make this work and out attempts have failed.
What's the best way to accomplish this configuration with a Cisco ASA?
You don't need to assign multiple IPs from the same range to more than one interface. That doesn't work with Cisco. Instead try a static one to one NAT for your Web server and terminate your VPN traffic on the IP address assigned to the interface.
Watch this video for one to one NAT:
https://www.youtube.com/watch?v=cNaEsZSsxcg
Cisco has an active scanning technology that was enabled on this ASA. We were able to diagnose it by intermittent bad behavior. After troubleshooting long enough we realized that some of the behavior couldn't be consistent with the changes we were making. So we started looking for things that the firewall would be trying to do by itself. That ended up helping us narrow it down. Disabling active scanning allowed our external vlan configurations to work. Now moving on to tightening up the configs.
Suppose that I have a server and the clients are connected to the server. The server is accessible through a public ip.
I would like to "forward" the connection so that the clients would be directly connected to each other withouth the server in the middle.
I do not know if this is possible at all and I myself couldn't find a way to do it.
Other assumptions:
neither client has a public IP, both clients are behind a NAT
there can be more connections initiated if necessary
I am looking for a strictly software solution, without the need to reconfigure router, open ports, etc. etc.
The reason I would like to achieve this is to reduce the load on server. Once a two clients are associated together there is no real need (except technical one) to continue using the server as a, sort of, proxy. Direct client connection would also reduce the latency of the connection.
Take a look at http://en.wikipedia.org/wiki/UDP_hole_punching. If neither machine has a public IP, and you can't open ports, and you don't want all data to pass through the server, this is probably the only other potential option. If this wouldn't work for you, you're likely stuck with all data going through the server. If you can set up port forwarding, that would make for a better solution, then just use the server to exchange IP and port information (as it exists at the time the connection is established).
A short answer is: it is not possible.
One of the main problems is that router do not know where to redirect the request from the server (or other client). Just a case : You have a router which has multiple devices(computer, cell phone...) behind it. It gets a request and do not know, who wants to get the request.
There is a workaround for that but it is not reliable (Does not work always.) Some Companies use it if it is possible, but they have always an alternative to that (like communication over server) if it fails. It is called nat punching. More details here: http://en.wikipedia.org/wiki/TCP_hole_punching
I do not know for which reason do you need. If you need it for client server connection you can use something like long polling, call back....
Otherwise you need to set the router, or take the route over the server.
You can do two things one is hole punching http://en.wikipedia.org/wiki/TCP_hole_punching
so this will allow you to respond to your client who are behind NAT (you can configure your client to send their private ip and port number used by NAT to reply to them).
Other thing you can do is to make a peer-to-peer network as done by skype and make one of the client as relay network and keep track of active relay's and update them periodically. (see http://en.wikipedia.org/wiki/Skype_protocol )
So now your server has to just act as proxy and as an admin which kind of manage all connection but least amount of info pass through it.
I hope this help.
Some home routers support upnp and can be instructed to open a certain port and forward it to a certain client on the LAN.
You can use upnpc on GNU/Linux to open ports on the router. It also has a library to do it from C code (but it's not very well documented).
However this method might not work on all home devices, so in that case see the other answers.
I've noticed recently that I don't have to forward ports for mmorpg's that I play.
I'm thinking about working on a game that people can play online and had a question.
Why is this the case given its a two way socket connection that is constantly sending data back and forth? Doesn't their server need to get through my firewall in order to connect to me?
TCP crash lesson: TCP is a two-way protocol. The challenge is that at least one host needs to initiate. Since within an MMORPG, your own computer is never acting as a server, nobody has to connect to it. All the information about game state is passed through the company's public facing servers that have public facing IP addresses (and hey, maybe they actually use port forwarding there, just to confuse my explanation... but you never have to see their pretty network internals, proxies, and other wizardry.).
Anyway, when you connect to Stackoverflow, you're making one outbound connection that requests data from the server, and then over that same connection you're receiving it back. Same exact scenario, only with a webserver instead of a game.
UPnP allows you to tackle many routers. There's also NAT Punch-Through if you have access to a third party that isn't behind a router.
Either way, port forwarding is only necessary if you wish to act as a server (or the sender in a P2P relationship). A client does not need to forward ports.
You don't need to forward ports to access the web either, despite data coming in as well.
When you make an outgoing TCP connection, your NAT router puts the connection in a table, so that when data comes in, it knows what machine in your LAN to send the packet to.
Everyone mentions TCP, but NAT works for UDP as well: The first outgoing UDP packet associates that source port with the internal IP address, and your NAT device will forward incoming traffic to that port to the correct host on the internal network.
In other words, if your computer requests the connection (outbound) first, the router opens up the port automatically, on the assumption that you're going to want data back. But if you want remote users to connect to your computer without your computer requesting it, the router would normally drop the packets since it wouldn't know where to send them (they were unsolicited). So instead, you need to tell the router to deliver any unsolicited packets at port N to your computer.
Sorry to add another answer so late, and I know one was already accepted, but I personally found the other answers to be more confusing than this simple explanation.
We meet a testing scenario which needs to tamper with source IP address of a Http request to simulate clients coming from different countries. Do you know any tool help on this?
Last but not least, our web site is built with ASP.NET.
Thanks.
In a test environment it usually isn't difficult. First read this SO question about virtual network interfaces.
If the server and client are on the same machine, all you have to do is figure out how to get your client software to bind to your virtual interface.
wget for instance has the --bind-address option to specify which local address to bind to. Web browsers are a bit more difficult to do this with; you may need to just run it in a VM.
If your server and client are on the same LAN, you just need to configure your router with some static routes to your client machine. In this case you probably don't need a virtual network interface, just set a static IP for your client machine; as long as the gateway is set up correctly it should be able to send packets to the server, and as long as the route is set up correctly the replies should find their way back to the client.
If the client and server are separated by an internet, it's rather more difficult. One option is to set up a network tunnel endpoint on the server and tunnel it to the client machine, which "knows" that it has the virtual network interface.
As noted in answers to the ServerFault question "Are IP addresses trivial to forge", you cannot easily forge source addresses in a protocol that required two way communication (e.g. TCP). Note that this "two way communication" is required at the packet level. You cannot just say "no problem, I want to send requests and ignore HTTP responses." To establish a TCP session, you need to receive data. Your best bet is to use a proxy server.
I am unsure if the IP standard allows for this, but if you are working in a Lab environment, where you don't need internet connectivity during the test, I can see it working under following circumstances:
Basically, I would set the server's network interface to use netmask 0.0.0.0 and flush the rest of the routing table.
Then you could configure a client machine to take on any IP address as long as you use netmask 0.0.0.0. And two-way communication should be possible.
Server[1.2.3.4/0] <---> Client[x.x.x.x/0]
But please bear with me. I haven't tested this, so I could be wrong :-)
If you have access to your infrastructure, you can add an interface off the router and then place a static route on the router to that network.
Server-----Router----Internet
/
Test_PC----/
Alternatively you can look into PBR (Policy Based Routing) and on the routers you can flag source packets and change the source on the fly, so your server will think they are coming from where you'd like them to come from.
Server-------------Router_with_PBR-------------Internet----- PC
SCR:4.2.2.2 Change SCR:6.6.6.6 to 4.2.2.2 6.6.6.6
But you have to ask yourself why do you want to see when packets come from different countries. Some countries have massive proxy servers that filter access ( "Great Firewall of China"), so the above tests will not prove much.
Your best bet then is using proxy servers or if your looking for a long term solution then setup a server (virtual is great for this) and use RDP for testing. I'm sure you can rent a virtual server somewhere for a month or two.
That's not possible. Because when you forge the ip address, the response is never going to come back, which is required for http.
The best way is to use proxies. See also this question on serverfault.
If you change your source IP address, that means no traffic from your web server will be able to reach back to the client.
You might be able to use some kind of proxy and/or address translation filter to do the remapping while still allowing two-way communication.