I've never had this problem before, but suddenly as of this morning, if I try to fire up my Phoenix app while my VPN is on, I get a bunch of eaddrnotavail errors from Postgres. If I try to start my app with the VPN off, it works fine, and it continues to work fine even if I then turn the VPN on, but if I try to start it with the VPN already running, eaddrnotavail errors every time.
Anyone have any idea why this is happening or how to fix it?
I got a response from ProtonVPN on this. Apparently they're working on a technical solution, but this is the main issue:
outgoing connections to some database-related
ports are currently being blocked on most of our servers for
anti-abuse reasons
Normally, any user connected to the same ProtonVPN
server would have the same authorization to access the database you
are willing to connect to unless there are additional security
measures in place, so this is not recommended and insecure. Even if
you whitelist some ProtonVPN IP addresses with your firewall, that is
still not enough because any user would still be able to reach your
database through the very same ProtonVPN IP address.
we are working on a solution to provide dedicated IPs
Related
There are a lot of questions/answers here describing problems with connection attempts to postgresql being rejected with an error saying "no pg_hba.conf entry for host". All the ones I have read imply that this is a configuration problem that has always existed, and needs fixing. In our case, just before the weekend, suddenly all new connections were (typically) rejected after working fine for literally months (a few attempts worked for a while, but after a few hours, all new connections were rejected).
In all cases, there the error is duplicated - once for SSL on and once for SSL off.
The server is on a Linux PC. We use IPV4 addresses within our office environment, but the host address mentioned in the error is IPV6. Is this a clue as to what may have changed?
We could not trace the cause of this issue, but when one of us swapped from Wifi (fail) to LAN (fail) and back to Wifi, suddenly it connected. Others then turned their Wifi connection off and back on, and connections were restored. However... the original addresses rejected by the Postgresql server are identical to those now in use and listed as temporary IPv6 addresses for the WiFi adapter. It is as if nothing has changed for the client, and yet everything has changed. We cannot explain it.
I use a local Python web server on my Windows machine. It’s simple, but good enough while in the static web page development stage. I just run it with something like this on my WSL command line:
python3 -m http.server
I can also access it on mobile devices on the same network, by going to my local address, e.g.: http://192.168.1.12:8000. All was good, until suddenly I could no longer access it on external devices, I got a “server not responding” type of message. Also, I could clearly see that when I refreshed the page on my phone, there was no GET request on the logs.
Immediately I tested on the local machine, and it was still working fine. This obviously smelled like a Firewall. In Linux, I’d know what to do, but it’s the first time I had to deal with this on Windows. This is what I’ve tried, without resolving the connection problem:
I opened the Event Viewer but could not see any obvious logs to check
I stopped the server (CTRL+C) and started it again on another port (5000). The Windows Firewall message popped up again asking for permission for Python3 to access the “Public network” and the “Private network”. Normally I just tick the “private network” but this time I checked both, as a troubleshooting step, in case my Wi-Fi was incorrectly being considered “public”.
I went to Windows Firewall and temporarily shut it down on the private network.
I installed and tried running nmap on the WSL, but it failed to run and prompted me to install the Windows version instead.
I installed and ran the Windows version of nmap but it told me that port 5000 was open.
What is the recommended way to troubleshoot and fix this issue?
Still suspecting the firewall, I tried something new, I switched off the “public network” firewall. I tested on my mobile and the page loaded as normal again! I immediately turned the firewall back on. Tested the page on my mobile once more, still fine. So, the solution was to toggle the public network firewall. I would make it more generic and toggle all firewall categories on Windows. And of course, I would make sure that the firewall stays on, this was a very quick operation.
I thought I’d put this here rather than ServerFault or SuperUser as it could potentially be more useful to developers, and it took a precious hour of my time. I still don’t know why it stopped working on its own in the first place. Better troubleshooting steps or suggestions are welcome, but I probably won’t be able to verify it as I don’t know how to purposely induce the issue.
Another solution that worked another time, was to delete all instances of Python 3.8 from the list of allowed apps (I don't know why Windows shows the same app multiple times) then (re)start the Python server and allow it through when the Firewall question pops up again.
In windows firewall you may have 4 options to configure your local web server when you are creating new Inbound connections rule.
1 Program
2 Port
3 Predefined
4 Custom
Try to use port only in "TCP protocol" and the custom port.
Allow connection.
Select: all checks: domain, private and public.
Enter a name.
Thats all.
I have an application with a server written in F# and serve web files using suave. I remote login using powershell into another machine in the network to run the application (The application is also in one of the network drives). I do that because that machine have access to third party APIs needed for the server. Now when I do [IPAddress_Of_Remote_Machine]/[html_file] or [name_of_pc]/[html_file] then chrome is waiting forever and doesn't ever return the webpage. This wasn't happening before and I ran into this problem recently. I opened a different port and used it instead of the default one 80. This made things work but the problem keeps showing up after a couple of days. I don't think it's a firewall issue but I'm clueless to why this is happening.
When running netstat -an, this is what I get (I hid the IP address):
As you can see all of the connections are either in CLOSE_WAIT or ESTABLISHED but not LISTENING. All of these TCP connections is probably because I have PhantomJS and two other APIs running in the application as well. However the loop back address is also open on the same port 5959:
I'm not sure what is difference between these two but when using PortQryUI to query the remote server it returns a success!
I have already made an inbound rule for port 5959 on the server so it should be allowed. The web page is stuck at Waiting for [name_of_pc]. Also, sometimes this problem disappears and everything works fine.
What is the potential problem behind this? Why would this happen all of a sudden?
UPDATE:
I re-ran the application today and it's working correctly. It could be that something is dynamically set within the firewall? Not really sure what is going on. The machine I'm running the server on has a bunch of applications running on it as well so maybe there is an external process that is affecting it?
I made a hello world app with Suave and deployed it on the network drive to test if it's going to work. I opened inbound rule for port 6001
Then I ran the app:
However, it's still not working and this time it says the site cannot be reached when I do: http://[name_of_pc]:6001.
Moving this to an answer so that it can be closed:
Could you post the bindings section of your suave cfg? I'm guessing you know where that is since you are using a non-standard port but if you need don't, search for HttpBinding. I suspect you will find it pointing to 127.0.0.1 which is not good enough for remote access. You could try changing it to 0.0.0.0 or to the server's actual IP address. I would try 0.0.0.0 first for the flexibility it provides
When developing and testing WP7 apps you're pc is connected to either a real WP7 phone or to the WP7 Device Emulator. For a specific development-purpose I would like to connect directly to the development pc (let's call it the host pc) from the WP7 app without having to rely on an external toast-server. I'm using plain sockets, System.Net.Sockets.Socket.
There seem to be two options:
Obtain the host pc's LAN IP and connect to that
Connect to localhost
Option 1 usually works well, but not always: The host pc may not necessaily have an IP, in which case there's nothing to connect to. Also, in some scenarios all LAN traffic is directed through a company-wide proxy which will disrupt this mechanism.
That lead me to try out option 2. To my surprise it seems to work, but I need to be more sure than simply "it seems to work". I've googled all over but can't find any definitive answer, not even on Microsoft's site like e.g. http://msdn.microsoft.com/en-us/library/ff754351(v=VS.92).aspx. So this is my question:
What exactly is the defined behavior of connecting to localhost from a WP7 app?
Altrernatively, is there a fool-proof way of connecting back to the host-pc?
(Let me stress this again: For this particular purpose I can't use toasts, because the development pc may not even be online.)
Edit:
I work at EQATEC and the application in question is the EQATEC Profiler. Right now the profiler/app-communication is handled by injecting a socket/http-client into the deployed WP7 app that connects back to the profiler's LAN IP address. It works very well and is really fast, but in some very rare cases users are offline and therefore doesn't have an IP, or have some prohibitive lan proxy rules.
Therefore connecting to "localhost" would be excellent if that somehow magically would always work for everybody. It works for me and a couple of test-users, but does it work for all our many thousand profiler users all over the world? I'd like to be more sure.
"localhost" by definition is the machine running the code (well specifically the NIC doing the communication). For either the Phone or the Emulator, that would mean the phone or the emulator, not the PC they are attached to.
When you attach to a PC, you do have a network - it's an RNDIS connection in which both sides get an IP address which traditionally (pre-WP7) could be resolved with 'ppp-peer', though I've not tested that resolution on the Phone. I suspect it will be the same, since WMDC is still what's connecting and they'd have little reason to change that connection mechanism.
If the emulator is resolving localhost to the PC on which is resides, that's a definite bug and I would not count on it continuing to work as they add more robust socket support to the Phone platform.
System.Net.Sockets.Socket isn't really currently available for WP7 programming, but it might be available at some future point (maybe in Mango... maybe...)
AFAIK, the only way to reliably do what you want to do is to set up an http server on the development PC and to provide your app with an HTTP address of that server - or to route messages via some "Cloud proxy"
I'm surprised localhost works at all on the real device... I can only assume that they are asking the connected PC to resolve that DNS name - but even then I'm surprised 127.0.0.1 works.
The ip you're looking for is "192.168.55.100"
That's the ip address the phone uses to connect to the host pc.
If you'd like to connect to the phone, apparently its ip address will be "192.168.55.101"
For the emulator just use localhost or 127.0.0.1
This is from the old ActiveSync days, so I don't know how official it is or how likely it is to last, but for right now at least it worked on my phone.
Recently we got a new server at the office purely for testing purposes. It is set up so that we can access it from any computer.
However today our ip got blocked from one of our other sites saying that our ip has been suspected of having a virus that sends spam emails. we learned this from the cbl http://cbl.abuseat.org/
So of course we turned the server off to stop this. The problem is the server must be on to continue developing our application and to access the database that is installed on it. Our normal admin is on vacation and is unreachable, and the rest of us are idiots(me included) in this area.
We believe that the best solution is to remove it from connecting to the internet but still access it on the lan. If that is a valid solution how would this be done or is there a better way? say blocking specified ports or whatever.
I assume that this server is behind a router? You should be able to block WAN connections to the server on the router and still leave it open to accepting LAN connection. Or you could restrict the IPs that can connect to the server to the development machines on the network.