Connecting to Amazon AWS PostgreSQL database from R session - r

I have a database instance running on Amazon AWS. I use the RPostgreSQL package to connect my R session to my AWS database.
My issue is that every time I attempt to connect to my database instance after not having done so for a while, I get a "Connection timed out" error.
I can then use a browser to go to my AWS Console, edit the Inbound and Outbound rules for my security group to allow my IP Inbound & Outbound access. Then I can connect again just fine.
But then if I don't work on my database for a day or two, when I try to connect to my DB, it doesn't work, and the permissions for Inbound/Outbound access no longer match my IP address (which I'm sure is the cause of the problem).
So... is my IP address changing? Or are the edits I'm making to my security group's inbound/outbound permissions not being saved correctly?
To be clear, here's the order of events of how things have been going:
Haven't worked on DB for a few days, attempt to connect from my R sessions. I get an error.
Use browser to go to AWS Console and edit my security group's Inbound/Outbound rules by selecting "My IP"
Try again to connect to my DB from my R session. Hooray! It works.
A few days later - pick up the project again, attempt to reconnect to my AWS DB from R, and it no longer works...
Repeat this cycle of madness
Make post on SO hoping for an angel to help me
This isn't a debilitating problem, it's just extremely annoying to have to re-do my security settings every time I want to connect to my AWS DB.
Thanks in advance for any help you can provide!

It depends, but most possibly it seems to be that your IP is changing. Most of the ISP have Dynamic IP allocation, which means the IP can change if the router is restarted.
It is hence recommended to use DNS name instead of IP address in the security group setting.
It is easier to note down your IP address and check back after two days.
Can you see your IP address which you added two days ago in the Security Group page? If yes, you can just goto google "what is my IP" and see if both the values are same. Security Group (SG) setting does not get refreshed or changed on it's own(unless you are allocating a new Security Group).
One more thing you can try. Allow all connection (0.0.0.0) just to test. After two days or so, try again. If it works, it means there is issue with the IP address changing.

Related

AzerothCore - still looping to realm selection even after updating IP address (Docker install)

I have followed the guides at https://www.azerothcore.org/acore-docker/, and everything installs and works fine. Auth, WorldServer, DB, etc all work. However, when trying to play locally (LAN, main computer with client, the server on a different Windows machine on same LAN), it consistently loops back to realm selection.
So, I searched here and found these two questions/answers:
Azerothcore: Looping on Realm Selection List
How to resolve sticking in "Realm Selection"?
I have followed the guide in the bottom one, and have changed the Address field in the database to my external IP address (assigned by ISP). The LocalAddress is 127.0.0.1 The rest of the information appears to be correct.
When trying to connect via the external IP, it won't connect at all. But when I try setting my realmlist to 127.0.0.1 it will connect and log me in, but continually loops back to the realm selection screen.
To make sure it was updating, I changed the name of the realm and it shows up correctly when I try and log in. So the data appears to be saved to the database, but I cannot get it to connect from the LAN.
Followed the official guides, and changed the IP address in the DB to external IP. Same result, except now it takes a few seconds to connect and try to log into the realm. Then fails, back to realm selection.
Help would be appreciated. Thanks.
It's 99.9% related to your networking. That's what it turns out to be for pretty much everyone asking this question.
Most likely either a port isn't forwarded correctly, or your firewall prevents the connection. Try and use an external service to verify if the port is open. (Do a search for "Port open check"). Also, check your firewall to have the worldserver listed as an exception in the right folder.
Another common mistake is to change the "default" values when using HeidiSQL in the realmlist db instead of changing the actual values in the 'data' tab.

Not able to make network calls from GCP Compute Engine

I have deployed my services in one of GCP compute engine where we make external HTTP service calls to pull data and process them for our purposes. From last two days, this call is failing with connection timeout. I have tried the same in my system. Things do work smoothly. No changes which are applied in the cloud account at all. Any possible issues which is causing this issue?
I have validated the firewall rules. Everything looks to be fine. Appreciate your valuable suggestions.
regards
Manjunath
it's been a while now since you've asked. Is this still happening? If yes please read on. Otherwise please close the posting.
Your message is quite short on details. I'm going to recap what I got:
What I got from your description
The GCE VM should be connected to the public net (I suppose it's having one of the setups: a direct public IP or an instance group member with Load Balancer or an inter connected VPC with another cloud subscription or GCP project through which it connects to the internet, without an own public IP for the VM)
The VM is not a GKE cluster instance
The VM is hosting some kind of "services" (I suppose this is some kind of containerized services?)
These services relay on establishing outbound connection to the internet
From running the same services on your local machine you can see no malfunction, the service code is ok (I suppose you deploy exactly the same code and an almost identical configuration to the VM?)
No changes have happened to the cloud account (I suppose you mean the subspriction and the project as well?)
Nothing from all this has been changed at all??
Things I'd be controlling in this situation
As your descriptin of the situation is unfortunately very rough, I'd try to give you a rough overview how I'd propose you to proceed in this order. Meanwhile please provide more details on the VM situation described above:
Public IP - No instance group with Load Balancer, No inter connected VPC:
Go to Compute Engine > VM Instances and check the External IP column. Go to Column Display Options in the top right corner of the table and enable the column if you don't see it. Make sure there is an IP here.
If the external IP exists, log in to your VM and make sure that you can ping any public internet site you know working
Trace the connection to the public site to get the route your network flow is taking
Ping the host from the next hop to your local network connection and make sure it's "really" reachable
Check whether you are having a local Firewall on your VM and disable it for a testing moment, ping again the router (or next host on the route towards the public site, from your tracing step above)
Meanwhile please provide more details on the VM situation described above

Gcloud-VPN with multiple IP-range is not connected to SonicWall

I'm using Gcloud VPN beta version with Windows server 2008 R2 VM.
When I try to connect the VPN to our company's local domain through SonicWall, it went successfully when only one IP range was used.
When I add the second IP range to the tunnel, Google Cloud console shows no error, but the VM can only connect to one IP range, and the connection switched from one IP range to the other from time to time with no pattern at all.
Does anyone have an idea about what went wrong?
It seems like the issue could be with the SonicWall.
Have you tried to reproduce the issue without the firewall?
You could take snapshots of the disk and make it the boot disk on new instances and try it out. I haven't seen this issue before but it would be a good way to see where the issue lies.
Let me know what happens.
Thank you

Can't connect to local server

Currently we have a system in place where multiple server backup to a server in house. There are a total of 11 different servers backing up to this one storage server. Without any change(any that we are aware of) one of the servers stopped being able to connect to the storage server. It's weird too because the one that can't connect is actually our DNS server. It can ping the storage server and nslookup returns the appropriate value. However when I tried to browse to the server in windows explore via network I get the following message:
"Check the spelling of the name. Otherwise, there might be a problem with your network. To try to identify and resolve network problems, click Diagnose." - Error Code: 0x800004005 Unspecified error.
If at all possible I would like the solution to not have to restart the server(obviously that's a big request) but we run 24/7 and can't have the DNS server down for the next few weeks.
Thanks in advance!
I am completely guessing here however lets start with this, does it work if you try and connect to the share using IP?
A few things to consider in the mean time? What O.S is it?
-> Is network discovery off?
-> Have any firewalls been accidentally turned on
-> We had a similar sort of problem when the server lost it's trust relationship with AD (required a reboot I am afraid).
Unfortunately this error can relate to a range of problems including network devices, anti-virus, firewalls, shares, user accounts etc etc.

ActiveDirectoryMembershipProvider "The specified domain or server could not be contacted."

I have an application that is using ActiveDirectoryMembershipProvider to grant access to users. The application is hosted on a non-domain machine, with a firewall between the application server and the domain controller.
We've opened the LDAP port to the DC on the inside network - yet no matter what we try, we end up with an error that says "The specified domain or server could not be contacted."
Does anyone have any suggestions on how I can resolve this? We've tried everything we can think of and just aren't getting anywhere.
My connection string is:
<add name="ADConnectionString"
connectionString="LDAP://10.5.3.7:389/DC=MyTestDomain,DC=local"/>
And my provider is:
<add name="ActiveDirectoryMembershipProvider"
type="System.Web.Security.ActiveDirectoryMembershipProvider"
connectionStringName="ADConnectionString"
attributeMapUsername="SAMAccountName"
connectionProtection="None"
connectionUsername="LdapUser"
connectionPassword="LdapPassword" />
The application is hosted on a non-domain machine, with a firewall between the application server and the domain controller.
Since you could query directly using an LDAP tool, that suggests that the firewall is open correctly. However, keep in mind that the ActiveDirectoryMembershipProvider is not using plain old LDAP, it's using Microsoft technologies. For example, if you set connectionProtection="Secure", ADMP will try using SSL and port 636, if that fails, it will use Microsoft's built-in IPSec signing (see this article for more details).
Anyway, this makes me wonder about a couple things:
Does the AD domain have an IPSec "required" policy which refuses connections from non-domain/non-configured computers? (Probably not, since you connected with plain LDAP, but it's worth investigating.)
Have you added the domain controller's NetBIOS name to your lmhosts file, and its DNS name to your hosts file? (Many protocols check that their target's reported name matches the name you tried to connect to.)
A lot of people have noted problems using ADMP between different domains, and the solution required that a one-way trust be created. Since it sounds like your client computer is not in a domain, you can't have that trust--unless either (a) it is a member of a different domain with a one-way trust or (b) it is a member of the same domain and thus client-server trust is implicit.
It seems like the solution is to open port 445.
Read this thread
We're not allowed to open so I guess I'm stuck.
You can use this two articles, may be solve your problem
www.ddj.com/windows/184406424
forums.asp.net/t/1408268.aspx
and check your firewalls
I had this error, and managed to fix it. There are multiple reasons that can lead to this, here is a to-do list to identify exect problem:
Create a micro application, with single method Membership.GetAllUsers(), execute on machine outside Active Directory (AD), with incorrect password in connection string, check if you get incorrect password exception. If you don't get it you can't connect to your AD server, check firewall, if you do get invalid password exception, goto next step.
If you can, try to execute same app, localy on AD server, first with incorrect password, than with correct, executing app locally provides more detailed exception what is wrong (for me this exception lead me to fixing problem). In my case it told me that Server service is not started, than that Workstation service is not started.
Some thoughts on the fact that it required Server and Workstation services to be working on server: afaik Server service is used for windows file sharing (netbios over TCP), and is using 445 port, so it mey be that this port must be opened in addition to LDAP port. My second observation was that event if 445 port opened (netstat -an) it still can be not working, winows will drop all packets to this port if Windows Client and File and Printer sharing checkboxes are not checked on network interface adapter which rcived this packets. Check "telnet External_IP 445". Thats all info i gathered while strugling with this problem.
Have you tested with an LDAP browsing tool, from the remote box to see if it can connect with the criteria being used here? I.e. Is it a connectivity problem or something else?
In case anyone stumbles on this and wants to smash their head on a wall... Recently tried doing all this for an AD server that my company had in a different domain than the current context. Was using the IP provided and getting failures as stated here. Even used a tool like Softerra LDAP Admin and it worked fine, however AccountManagement failed.
We had a publicly exposed URL hooked to that IP address (still only allowing certain IP's to make calls). Once I replaced the IP with the URL provided, it worked like a charm.
Hope this saves someone the hours of head smashing I just put myself through.

Resources