Topic: [SOLVED] VOIP Server behind SME server doesn't respond

[stefan_gk]

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.

Code: [Select]

[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>

Code: [Select]

[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.

[pfloor]

What is your network configuration?

How did you try to forward the port?

[CharlieBrady]

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.

[JonB]

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

[stefan_gk]

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.

[stefan_gk]

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

Code: [Select]

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!

[stefan_gk]

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

[JonB]

What does a tcpdump on eth0 port 22 show?

It should show packets on port 22 going to your VOIP server.

Jon

[stefan_gk]

What does a tcpdump on eth0 port 22 show?

It should show packets on port 22 going to your VOIP server.

Jon

Code: [Select]

[# 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 ...

[JonB]

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

[stefan_gk]

The subject of the topic is changed to "VOIP Server behind SME server doesn't respond"

[CharlieBrady]

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.

[JonB]

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

[CharlieBrady]

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.

[stefan_gk]

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.