Koozali.org: home of the SME Server
Obsolete Releases => SME Server 7.x => Topic started by: stefan_gk on January 27, 2007, 07:59:11 AM
-
THIS TOPIC WAS WITH SUBJECT "Port forwarding doesn't work!!!"
I have IP telephony server behind my SME71. The supporting company need access to port 22 on teir server from Internet/Their office.
I tryed port forward some port to iptelsrv:22 but it doesn't work.
[root@srv iptables]#tcpdump -vv -i eth1 dst port 11111
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
22:19:46.663006 IP (tos 0x0, ttl 58, id 33320, offset 0, flags [DF], proto 6, length: 60) office-router.57858 > my-ext-iface.11111: S [tcp sum ok] 133678472:133678472(0) win 5840 <mss 1460,sackOK,timestamp 2159036320 0,nop,wscale 2>
22:19:48.243941 IP (tos 0x0, ttl 58, id 33322, offset 0, flags [DF], proto 6, length: 60) office-router.57858 > my-ext-iface.11111: S [tcp sum ok] 133678472:133678472(0) win 5840 <mss 1460,sackOK,timestamp 2159039320 0,nop,wscale 2>
[root@srv iptables]# iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
PortForwarding all -- anywhere anywhere
SMTPProxy tcp -- anywhere anywhere tcp dpt:smtp
TransProxy tcp -- anywhere anywhere tcp dpt:http
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
PostroutingOutbound all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain PortForwarding (1 references)
target prot opt source destination
PortForwarding_4508 all -- anywhere my-ext-iface
Chain PortForwarding_4508 (1 references)
target prot opt source destination
DNAT tcp -- anywhere anywhere tcp dpt:11111 to:iptelsrv:22
Chain PostroutingOutbound (1 references)
target prot opt source destination
ACCEPT all -- my-ext-iface anywhere
MASQUERADE all -- anywhere anywhere
Chain SMTPProxy (1 references)
target prot opt source destination
ACCEPT all -- anywhere localhost
ACCEPT all -- anywhere srv.mycompany.local
ACCEPT all -- anywhere my-ext-iface
DNAT tcp -- anywhere anywhere to:my-int-iface:25
Chain TransProxy (1 references)
target prot opt source destination
ACCEPT all -- anywhere localhost
ACCEPT all -- anywhere srv.mycompany.local
ACCEPT all -- anywhere my-ext-iface
DNAT tcp -- anywhere anywhere to:my-int-iface:3128
In /var/log/iptables/current log file there are no records for dropped packets.
Look very strange!
Any help will be appreciated.
-
What is your network configuration?
How did you try to forward the port?
-
I tryed port forward some port to iptelsrv:22 but it doesn't work.
Port forwarding *does* work.
Two most common causes of port forwarding *appearing* not to work are:
- attempt to test the port forward from the internal network (which doesn't, and cannot, work).
- default route on the target system does not point back to the SME server.
-
Does your server know the hostname iptelserv?
Have you added it to 'hostnames'?
Try using the ip address of iptelserv instead of host name.
Jon
-
What is your network configuration?
How did you try to forward the port?
The server is in typical configuration Sever & Gateway. Internet connection is on eth1 and LAN is on eth0.
I do forwarding from Server manager GUI and the result is seen from initial post here.
-
Port forwarding *does* work.
Two most common causes of port forwarding *appearing* not to work are:
- attempt to test the port forward from the internal network (which doesn't, and cannot, work).
- default route on the target system does not point back to the SME server.
In my case the test fail both from inside and from outside.
I hope that tcpdump -vv -i eth1 dst port 11111 shows incomig traffic from outside
For the case of default route I'm not sure. I'll ask the company who supports ip telephony server to check that.
Thanks for suggestion!
-
Does your server know the hostname iptelserv?
Have you added it to 'hostnames'?
Try using the ip address of iptelserv instead of host name.
Jon
Actually I'm using IP instead of name and changed it in posting just to hide the real addresses.
Thanks
-
What does a tcpdump on eth0 port 22 show?
It should show packets on port 22 going to your VOIP server.
Jon
-
What does a tcpdump on eth0 port 22 show?
It should show packets on port 22 going to your VOIP server.
Jon
[# tcpdump -n -vv -i eth0 host VOIP-SERVER
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
12:49:41.062161 IP (tos 0x0, ttl 119, id 26402, offset 0, flags [DF], proto 6, length: 48) OUTSIDE-PC.25541 > VOIP-SERVER.ssh: S [tcp sum ok] 3352861315:3352861315(0) win 65535 <mss 1460,nop,nop,sackOK>
12:49:43.899388 IP (tos 0x0, ttl 119, id 26406, offset 0, flags [DF], proto 6, length: 48) OUTSIDE-PC.25541 > VOIP-SERVER.ssh: S [tcp sum ok] 3352861315:3352861315(0) win 65535 <mss 1460,nop,nop,sackOK>
12:49:46.060807 arp who-has VOIP_SERVER tell SME-SERVER
12:49:46.061670 arp reply VOIP-SERVER is-at XX:XX:XX:XX:XX:XX
12:49:49.933086 IP (tos 0x0, ttl 119, id 26409, offset 0, flags [DF], proto 6, length: 48) OUTSIDE-PC.25541 > VOIP-SERVER.ssh: S [tcp sum ok] 3352861315:3352861315(0) win 65535 <mss 1460,nop,nop,sackOK>[/size]
I think that for some reason VOIP-SERVER doesn't respond on ssh requests. But in the same time I succeed to do ssh from SME Server to VOIP-SERVER.
I allready ask the people from VOIP Company is there any permisions to do ssh from networks different than network of the interface - and the answer were NO. So the issue is still opened ...
-
You may still have an issue but it is not a port forwarding issue.
Port forwarding is working correctly. You are sending packets from the internet on port 11111 to your external ethernet port and they are being forwarded via your internal network on port 22 to the voip server. This is how port forwarding works.
The fact that the voip server is not responding to those packets is another issue that has nothing to do with port forwarding.
The subject of this thread is incorrect and should be changed to reflect that this not a port forwarding issue.
Jon
-
The subject of the topic is changed to "VOIP Server behind SME server doesn't respond"
-
The fact that the voip server is not responding to those packets is another issue that has nothing to do with port forwarding.
You don't have enough information to conclude that it's not responding. See my earlier post - reason number 2 will cause the SME server to see the inbound packets and not see any return traffic.
-
Charlie,
You are quite correct and I could have worded my response differently.
I should have said that it is not responding to that ip address or that port.
However, that was not the main reason for my post which was to prove to the OP that port forwarding is in fact working and that the problem lies within the voip server, what ever that reason may be.
Jon
-
I should have said that it is not responding to that ip address or that port.
No, that's not even accurate. It could very well be responding, and we just don't see the response, because it is trying to send it to a bogus default gateway.
However, that was not the main reason for my post which was to prove to the OP that port forwarding is in fact working and that the problem lies within the voip server, what ever that reason may be.
Yep, that part sounds accurate.
-
I tryed port forward some port to iptelsrv:22 but it doesn't work.
Port forwarding *does* work.
Two most common causes of port forwarding *appearing* not to work are:
- attempt to test the port forward from the internal network (which doesn't, and cannot, work).
- default route on the target system does not point back to the SME server.
YES. After doing findings several days I come to this note again. I got root acces to VOIP Server and checked the default gateway, and yep WRONG ONE. I've changed it to correct one and everything is OK.
I hope that this post will also other people to resolve their similar problems.
-
The subject of the topic is changed to "[SOLVED] VOIP Server behind SME server doesn't respond"
-
I hope that this post will also other people to resolve their similar problems.
Please check whether the FAQ is updated if it does not contain this information. Opening a ticket via the Bug Tracker is the way to ask for the FAQ to be updated.
-
A peripheral was misconfigured
I don't think that warrants a FAQ entry