0

I have working websites running under Apache. They are perfectly accessible from the LAN.

I also set up part of the server to be accessible from WAN. This worked at first (beginner's luck, no doubt) but now ERR_CONNECTION_RESET is consistently returned. I have explored all avenues I could think of, even reinstalled Apache, and am now out of ideas.

Port forwarding is properly set up, and verified with nmap. Both local and remote scans show my port to be open.

I have double-checked my ufw rule and enabled logging for it. The log shows that packets get [UFW ALLOW] for both local and remote incoming connections.

I have run Wireshark captures from the client. Only three packets are exchanged in the (failed) remote connection scenario:

1   0.000000000 [local_IP]  [remote_IP]   TCP 66  49527→1123 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
2   0.058425000 [remote_IP]   [local_IP]  TCP 66  1123→49527 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1320 SACK_PERM=1 WS=128
3   0.058504000 [local_IP]  [remote_IP]   TCP 54  49527→1123 [ACK] Seq=1 Ack=1 Win=16384 Len=0

The significant differences being that when connecting successfully from LAN, the second packet will have MSS=1460 and the third packet will have Win=65536. And when sent, the fourth packet contains the HTTP GET command with my LAN IP as source, and so on.

If I use tcpdump on the server side, I get the following in the problematic (WAN side) scenario (break called after connection reset was received):

$ sudo tcpdump -n -tttt -i eth0 port 1123
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
2015-07-14 06:38:45.291695 IP 92.95.32.112.49361 > 192.168.1.10.1123: Flags [S], seq 3726787794, win 8192, options [mss 1320,nop,wscale 8,nop,nop,sackOK], length 0
2015-07-14 06:38:45.291735 IP 192.168.1.10.1123 > 92.95.32.112.49361: Flags [S.], seq 2812896430, ack 3726787795, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
2015-07-14 06:38:45.351536 IP 92.95.32.112.49361 > 192.168.1.10.1123: Flags [.], ack 1, win 64, length 0
^C
3 packets captured
3 packets received by filter
0 packets dropped by kernel

When connecting locally, it rather looks like this; note the different window size on the third packet:

$ sudo tcpdump -n -tttt -i eth0 port 1123
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
2015-07-14 06:41:33.112315 IP 192.168.1.50.49379 > 192.168.1.10.1123: Flags [S], seq 3570261874, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
2015-07-14 06:41:33.112357 IP 192.168.1.10.1123 > 192.168.1.50.49379: Flags [S.], seq 3490289174, ack 3570261875, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
2015-07-14 06:41:33.512742 IP 192.168.1.50.49379 > 192.168.1.10.1123: Flags [.], ack 1, win 256, length 0
2015-07-14 06:41:33.514046 IP 192.168.1.50.49379 > 192.168.1.10.1123: Flags [P.], seq 1:433, ack 1, win 256, length 432
2015-07-14 06:41:33.514079 IP 192.168.1.10.1123 > 192.168.1.50.49379: Flags [.], ack 433, win 237, length 0
2015-07-14 06:41:33.554794 IP 192.168.1.10.1123 > 192.168.1.50.49379: Flags [.], seq 1:1461, ack 433, win 237, length 1460
2015-07-14 06:41:33.554818 IP 192.168.1.10.1123 > 192.168.1.50.49379: Flags [P.], seq 1461:2768, ack 433, win 237, length 1307
[...]^C
919 packets captured
919 packets received by filter
0 packets dropped by kernel

I have noticed that the service is apparently run only with tcp6 as opposed to my ssh server; could this be the cause? Update: apparently NOT as Listen 0.0.0.0:1123 in /etc/apache2/ports.conf did force tcp, but the problem remained when connecting from the WAN side.

$ sudo netstat -plunt | grep ssh
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      1510/sshd       
tcp6       0      0 :::22                   :::*                    LISTEN      1510/sshd       
$ sudo netstat -plunt | grep apache2
tcp6       0      0 :::1123                 :::*                    LISTEN      3290/apache2    

I have been unable to capture anything in /var/log/apache2 about these events using the following: LogLevel info, LogLevel debug and LogLevel trace8 (and the appropriate service restart). All the files in the folder keep the same datestamp before and after the failed connection, in all cases.

I may be wrong, but since Apache gives so little information I am now wondering if this could be related to an SQL or PHP issue with external links, but I actually do not have any experience with those. The service in question here is ownCloud.

Any ideas on how to troubleshoot this further, and find out what could be wrong?

  • What I am not following in this question and answer thread is why the remote port is 1123 and not port 80. (at least if I understand the wireshark listing correctly. I use tcpdump.) Could you explain? – Doug Smythies Jul 12 '15 at 15:50
  • This is simply a custom port I wish to direct the traffic to, for that specific website. I have added this port to both apache conf and website virtual host conf; that port works from LAN no problem. – Tfb9 Jul 12 '15 at 16:55
  • Yes, that it is only listening on IPV6 could be the cause. – Doug Smythies Jul 13 '15 at 4:11
  • Great, a lead! Would you know how/where this is configured? I only know of the LISTEN command where port is secified. – Tfb9 Jul 13 '15 at 10:06
  • I do not know why apache is not listening to ipv4 port 80. Odd. You could try replacing Listen 80 with Listen 0.0.0.0:80 in /etc/apache2/ports.conf. – Doug Smythies Jul 13 '15 at 14:20
0

Check whether ports are working fine first of all. You can do this a port scan tool such as this. If there are problems check your ip again because probably you have dynamic ip and changing by some periods if it is fine or test result is fine probably at home u set dynamic ip .from your network connections set a static ip for yourself like here. And yo prevent somebody to get the very same ip as you reserve this ip on modem settings. Reserving an ip is quite simple find dhcp setting under your modem lets take yur modem is on 192.168.1.1 and you set for yourself 192.168.1.2 in this case in dhcp settings type 192.168.1.3 as startpoint if non of these works contact to your ISP in some countries some ports might be not allowed to open for example I was in Cyprus half a year ago and opening port 80 is forbidden there.

--UPDATE--

As I understand as client from another computer you can connect but as server when you try to connect cannot see the page. This is a main problem unless you dont use proxy routers cannot route requests which goes out from itself into itself try to use a web proxy in this case probably it is gonna work. You cannot do anything about this as server you cannot connect to your own network without proxy

  • @Tfb9 i am sorry about that please check updated answer i hope u will solve it – nikoss Jul 12 '15 at 14:54
  • Please trust that nmap was run both 'from a local machine' and 'from a remote address'. These are the different packets I captured (the first three packets are similar in each conversation). I see that the server-client talk to each other, meaning all ports are open and well forwarded. My question is: why is that conversation being terminated when I am logging from a WAN-side machine? All I get from the browser is that the connection was reset. – Tfb9 Jul 12 '15 at 15:17
  • ah now i see more clear when u connect as client no problem but from server cannot get things working well it is in this case pretty simple if i understand right wait im updating – nikoss Jul 12 '15 at 15:26
  • Can you check the update @Tfb9 – nikoss Jul 12 '15 at 15:30
  • If I may add, to be perfectly precise: I can connect to my server easily from LAN, but I get connection reset when I try from WAN. I do have a working ssh-from-WAN set up right now, and working perfectly. This seems to be all about apache2 setup, IMHO. Thanks for the help, greatly appreciated here. – Tfb9 Jul 12 '15 at 15:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.