LinuxQuestions.org - HTTPS on custom port

- Linux - Networking (https://www.linuxquestions.org/questions/linux-networking-3/)

- - HTTPS on custom port (https://www.linuxquestions.org/questions/linux-networking-3/https-on-custom-port-4175424982/)

diwljina

08-31-2012 10:01 AM

HTTPS on custom port

Hi!

I'm not sure if this should go in this subforum, but I think it is network related problem.

I connect to svn server with custom https port and it is working on almost any machine, but on one I get:

Code:

svn: OPTIONS of 'https://IP:5442/svn/apps/trunk': could not connect to server (https://IP:5442)

I thought that it is some svn related problem, but I couldn't connect to that address with browser either. I used links to check that.

Machine I'm having problem with is a server and another server with same version of CentOS, subverstion and neon (ra_neon is module for http and https scheme) doesn't have that problem. svn and links don't have a problem with that https link on it.

One of developers that worked here earlier sad that this problem was on second server as well, but sysadmin that was working at that time resolved the issue. Don't know what he did.

I checked firewall and it's properly set up. SELinux is off.

What else could be a problem? What else to check?

Any idea?

szboardstretcher

08-31-2012 10:33 AM

Can you ping the IP address? Traceroute to it? Try clearing arp cache?

diwljina

08-31-2012 10:50 AM

I can ping it, but traceroute don't work because of firewall on server.

Problematic address doesn't show up in "arp -n".

szboardstretcher

08-31-2012 10:54 AM

Is iptables enabled on this machine and correct?

Can you tcpdump from the destination machine to see if traffic is getting there while testing?

And,.. can you connect to it like this:

Code:

openssl s_client -connect IP:PORT

diwljina

08-31-2012 11:12 AM

Yes, iptables is on and correct.

I don't have access to the svn server machine, so I can't use tcpdump there.

openssl doesn't work.

I tried svn and openssl with strace.

This is part I think is relevant:

openssl

Code:

connect(3, {sa_family=AF_INET, sin_port=htons(5442), sin_addr=inet_addr("x.x.x.x")}, 16) = ? ERESTARTSYS (To be restarted

svn

Code:

setsockopt(3, SOL_TCP, TCP_NODELAY, [1], 4) = 0

connect(3, {sa_family=AF_INET, sin_port=htons(5442), sin_addr=inet_addr("x.x.x.x")}, 16) = ? ERESTARTSYS (To be restarted)

--- SIGINT (Interrupt) @ 0 (0) ---

On other server that is working (svn):

Code:

setsockopt(3, SOL_TCP, TCP_NODELAY, [1], 4) = 0

connect(3, {sa_family=AF_INET, sin_port=htons(5442), sin_addr=inet_addr("x.x.x.x")}, 16) = 0

open("/dev/urandom", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 4

.

.

.

and so on. It continues further.

szboardstretcher

08-31-2012 11:33 AM

For a double-check, if it is a safe non-production environment, I would temporarily disable iptables and test with openssl again.

Is there anything between these computers? Firewalls, VLAN settings, filtering?

diwljina

08-31-2012 05:17 PM

It is a production environment, so I would like to avoid turning firewall off, but this it the relevant part from iptables:

Code:

65016  39M ACCEPT    all  --  !lo    *      x.x.x.x        0.0.0.0/0          

59923  30M ACCEPT    all  --  *      !lo    0.0.0.0/0            x.x.x.x

x.x.x.x. being, of course, svn server.

svn server is accessible from other machines, so I don't think there is something on that side that is blocking connection and client side is dedicated server at some data center. Not likely that they are blocking something.

You can see from iptables that packets are coming that way.

Also, I see from strace that ssl certificate is checked.

There is no problem when I test openssl command on some other server with ssl on 443 port.

All times are GMT -5. The time now is 04:02 AM.