Gospel. Culture. Technology. Music.

Tag: Port


Redirecting HTTP Requests to HTTPS on Same Port in NGINX

I had a particular need with Shoutcast (since the application is 1) able to do HTTP and HTTPS on the same port, and 2) since I wanted to reverse proxy those requests for security filtering with ModSecurity) to have HTTP requests that hit the HTTPS port to upgrade those requests to HTTPS on the same port instead of just erroring out (bad protocol error). Some of this had to do with browser and other client-end mechanisms forcing an HTTPS upgrade of late, but finding it wasn’t working correctly all the time. I struggled to find a good solution but came to an answer finally on stackoverflow. I’m documenting it here for future reference and for those that may need that kind of functionality since it’s a very specific request. I normally just do a 301 redirect for situations like this, but it doesn’t seem to work when streaming media for whatever reason using particular media clients. This has done the trick.

Using Postfix SASL Authentication with Google 2-step Verification On

For future reference. This came in very handy after I turned on Google 2-step verification. Originally found here: http://passion4high-tech.blogspot.com/2013/03/postfix-sasl-authentication-failed-with.html

————————————–

If you configure your Google account for extra security to use the 2-step verification, then some applications which work outside the browser might not be compatible with 2-step verification and cannot ask for verification codes.

Postfix which was installed and configured to send out emails won’t work anymore, and you might notice error messages in the /var/log/mail.log file.

Something like:

SASL authentication failed; server smtp.gmail.com said: Application-specific password required.

The solution below should fix this issue:

OpenVPN Sharing a TCP Port with SSL on NGINX and Apache?

I’m absolutely baffled there isn’t more information out there about this. It seems like web managers and techs would be all over this, but there’s barely any information out there on this. I had a hard time finding documentation on OpenVPN’s site itself!

As one guy stated here (the post where I finally understood how this works) it’s not really “sharing” the port per se, but OpenVPN is deciphering between HTTP/S traffic and OpenVPN traffic and then forwarding web traffic over to another port, defined below. That’s crucial to understand.

Before I start, I want to note this doesn’t have to be done on an SSL port, as I understand it. I’m just using that as an example because it seems to be the most logical way to make it work if this is your configuration (you know, an SSL VPN going to an SSL port).

It should also be noted in this configuration example that OpenVPN, using the port-share parameter, is actually doing the listening on TCP port 443 and acting as a proxy itself that forwards non-OpenVPN traffic to the NGINX SSL port which we’ll layout below. You cannot do this utilizing UDP, that I know of.

So here’s what you do.

1) Set your NGINX or Apache listening ports. Set your NGINX standard http port 80 and SSL listening port to something OTHER than 443 … so, for arguments’ sake, let’s set it to 4443.

So it would look like this for Apache and NGINX:

For Apache, in the main httpd.conf (Windows) or in ports.conf (Ubuntu/Linux):

Listen 4443

For NGINX, in /etc/nginx/sites-available/defaults:

server {
        listen   4443;

        location / {
                root  /web/etc/blah;
        }
}

Once implemented, restart your respective service, Apache or NGINX.

2) Next, you’re going to set your OpenVPN server parameters. Set your listening port to 443 from its standard 1194 and add the port-share parameter to point to the Apache or NGINX port created above. The config should look as follows now:

port 443
port-share 127.0.0.1 4443
proto tcp

OpenVPN will now be ready to accept connections over 443 and route the appropriate https/SSL traffic to Apache or NGINX.

3) Change your firewall settings. Leave your TCP port 80 rule pointing directly to Apache or NGINX. Then point your SSL rule to TCP port 443 running on your OpenVPN server. OpenVPN will now catch the traffic directed at it and decipher between OpenVPN traffic and HTTPS traffic.

4) Change the configuration in your OpenVPN clients. Point your OpenVPN clients to TCP port 443 instead of the port you were using before:

remote domain.name.com 443

or

remote [IP ADDRESS] 443

Hope it works. Cheers!

AT&T Re-Blocking Outgoing Email Port 25 for Uverse Customers?

(FYI: When I first had Uverse setup, they allowed me to open SMTP port 25. This problem started when it was inadvertently blocked again recently. Long story short, there were other reports of this happening. Below is the process of trying to get it unblocked again.)

I have come to the realization tonight that my mail server has not been sending out emails since February 17th. I hopped on AT&T’s Uverse chat support and was informed (after connecting to a second tech for a possible different answer because, you know, not all techs know the same things) that AT&T is now blocking outbound SMTP port 25 for Uverse customers. I initially had the port opened on my account to allow outbound email for my mail server. But it doesn’t work now as of February 17. And if you want to have this port opened now, you must contact their Connectech team to unblock it. The number, as of now, is 1-866-294-3464, or you can apparently connect with their chat service here: https://chatnow.att.com/. If you send me an email directly right now, I’ll try to respond another way in the mean time.

—————————————————————

UPDATE 1: Okay this is rich. So I contacted Connectech via the chat app (which is an exe download, similar to TeamViewer), chatted with the tech about the problem and was asked if I had purchased a support plan. I said, no, I just need my port 25 opened again. He said, I can’t help you unless you have a package purchased (paraphrasing all of the aforementioned).

So let me get this straight: I already pay AT&T Uverse a larger amount of money for their technology (okay fine, whatever) than the other guys. I pay for support too when I have a problem, support that comes with my service. AT&T decides to block outbound port 25. To get it open, I can’t just call the regular support anymore. I have to call their outsourced “professional techs” to flip a switch. And in the process, at least pay them $20 more a month. You’ve gotta be kidding me? This is a new low for AT&T customer service. Ever heard of corporate communism? With their level of bureaucracy, red tape and hoops to jump through to get something done, for the one’s they’re supposed to be servicing, I can’t think of a better term. Or how about inefficiency?

—————————————————————

UPDATE 2: So after having blogged and tweeted this issue, I have received two responses from AT&T techs saying they can help. They asked me to direct message them on Twitter now with my account information. And although they are still tweeting others with issues, they will not respond. I don’t get it. Still waiting though …

—————————————————————

UPDATE 3: A social media guy (Mike A) from AT&T contacted me directly about the issue and is getting the ball rolling. Appreciate it!

—————————————————————

UPDATE 4: After receiving a call, I have yet to hear anything about a possible resolution or whether it is even still being looked at. I’ve called twice, left messages, with no response. Benefit of the doubt: could be very busy.

—————————————————————

UPDATE 5: Received a call from Mike A a little while ago at the social media team at AT&T and they let me know they have resolved the problem, port 25 is not being blocked anymore. There were apparently other reports of this happening and they are handling it on a case by case basis. Appreciate the help, Mike A, at @ATTTeamNatasha!

 

Powered by WordPress & Theme by Anders Norén