I have this network configuration:
SIP Provider -> Mikrotik CCR as my network Gateway (NAT) -> Asterisk PBX -> Mikrotik RB as CPE device (NAT) -> SIP Devices behind the RB.
How I have to configure the NAT on asterisk and on Customer devices?
Actually I have some problems of one-way-audio but not on all calls.
Thank you in advice for the help
Asterisk can both act as a SIP client and a SIP server. Asterisk as a SIP client is configured with type=peer (or type=friend) in one or more client sections of sip.conf and, optionally, one or more register=> lines in the [general] section of sip.conf. Asterisk as a SIP server connects clients (SIP Phones) configured by specifying their own username, secret, etc. (and either type=peer or type=friend) in client sections of sip.conf.
Asterisk SIP channels in a NATed network can be generalized like this:
Asterisk as a SIP client behind nat, connecting to outside SIP Proxies
Asterisk as a SIP client behind nat, connecting to inside SIP proxies
Asterisk as a SIP server behind nat, clients on the outside connecting to Asterisk
Asterisk as a SIP server behind nat, clients on the outside behind a second NAT connecting to Asterisk
Asterisk as a SIP server behind nat, clients on the inside connecting to Asterisk
Asterisk as a SIP client outside nat, connecting to outside SIP proxies
Asterisk as a SIP client outside nat, connecting to inside SIP proxies
Asterisk as a SIP server outside nat, clients on the outside connecting to Asterisk
Asterisk as a SIP server outside nat, clients on the inside connecting to Asterisk
Every setup works somewhere, but it depends on the client, the NAT, the server and many other factors. In most cases, 1 and 3 is broken. SIP is a peer-to-peer protocol and a NAT can be generalized and simplified as a solution that allows clients on the inside to connect to servers on the outside and _not_ allow clients on the outside to connect to any server on the inside.
#1 works with a NAT-supporting proxy as SIP Express router as the outside proxy. (Get an account at IPtel.org and try!). Fails with Free World Dialup.
#2 Works- no NAT in between
#3 Works with port forwarding and some header mangling magic tips
#4 Works with port forwarding, STUN on the remote and some fine tuning of RTP port allocation
#5 Works - no NAT in between
#6 is no problem. No NAT in the middle
#7 is a problem if no port forwarding is done, similar to 3 above.
#8 is no problem. No NAT in the middle
#9 is solved with nat=yes and qualify=xxx in sip.conf for the client in most cases. Some clients (X-lite) assist themselves by using STUN and sending UDP keep-alive packets. Qualify sends keep-alive packets from Asterisk to the client on the inside.
http://www.voip-info.org/wiki/view/Asterisk+SIP+NAT+solutions
Related
If server A receives a UDP packet, can it forward it to server B and have server B directly respond to the end client without going back through server A since UDP is connectionless?
My gut feeling is no, unless both server A and server B have the same IP address (anycast maybe?)
But if the client is built to also be a UDP server, it could work in theory since the (logical) response from server B would just look like a new request. But then this really doesn't work in practice because of firewalls and NAT, for the same reason it's hard to host a game server from behind your firewall, router, and ISP.
If server A receives a UDP packet, can it forward it to server B and have server B directly respond to the end client without going back through server A since UDP is connectionless?
Yes, it can. However, there are a few caveats:
NAT devices, which most client are behind of. There are several types of NAT devices. A full-cone NAT will accept the redirected packet just fine, but an address-restricted NAT would require the packet to return from the same address it was sent to (hence, your anycast idea would work, as well as simply having server B spoof the IP of server A). A port restricted or symmetric NAT would also require the same source port (i.e. server B has to send the response from the same port server A received it from).
Other types of network middleboxes, such as firewalls might block the returning packet
Application - will the client application accept a response from a different IP address and port?
I have asterisk in a server having public ip. I am trying to asterisk from outside network from a sip phone(zoipar). I have opened the port 5060 on my router which is the default udp port for asterisk sip connection and i have also opened the 10000-20000 port for rtp defined in rtp.conf in asterisk.
When i m trying to connect my softphone to asterisk server from outside my network, it says Registration timeout and when i check if i got any hit on my port 5060, its doesnt show anything.
on my server 5060 is running
netstat -nlp | grep 5060
udp 0 0 0.0.0.0:5060 0.0.0.0:* 21768/asterisk
BTW I'm able to connect from local network without any problem .
You need to forward incoming traffic on your router from SIP and RTP to your asterisk server, it's not enough to open those ports, you need to explain your router where to send incoming traffic ton those ports
You need setup NAT.
This article will help you in your situation.
http://www.voip-info.org/wiki/view/Asterisk+sip+nat
You need to login to your router and forward the ports to your asterisk server internal IP.
You will also need to make sure your firewall on your server is setup correctly to allow the ports to go in and out of your server.
You can read more on iptables here: http://www.cyberciti.biz/tips/linux-iptables-examples.html
What I am asking is if two computers listen to the same port and a packet of information enters the router through the WAN Ip and the same port. Would the packet go to both computers? Neither? One or the other?
IE
computer 1 -(internal IP)-> 192.168.1.3 -(listens to port)-> 4444
computer 2 -(internal IP)-> 192.168.1.2 -(listens to port)-> 4444
computer 3 -(connects and sends)-> 24.157.358.45:4444
packet -> computer 1 AND computer 2
The code in VB6 is:
LAN.LocalPort = 4444
LAN.Protocol = sckTCPProtocol
LAN.Listen
I am using a WinSock object in the Microsoft WinSock Control 6.0 in VB6 Professional
If there is something that needs to be clarified I would be more than happy to.
The router won't send an inbound packet to either machine unless communication has already been established.
If 192.168.1.3 calls out to some other machine (e.g. 4.5.6.7) from its port 4444, the router will assign an arbitrary port on its external address (say 24.157.358.45 [sic] :5555) and pass the packets on to 4.5.6.7. 4.5.6.7 will send reply packets to 24.157.358.45:5555 -- because that's the only address it knows about -- and the router will relay those to 192.168.1.3:4444.
That's the normal course of things, but there are a lot of additional details to this scheme that make it possible to establish communication with a machine behind a router via trickery.
The system of having machines with private IP addresses behind a router with a public address is called network address translation (NAT); it's a pretty deep topic.
From my knowledge of routers, unless port forwarding is setup, the router will discard any packets sent on that port.
If port forwarding is setup, only one of the computers could be setup to receive the packets.
If the packet is an inbound request to establish a new TCP connection with a server that is running behind the router, the router must have an explicit port-forwarding rule configured, either statically in the router's configuration or dynamically via uPNP or SNMP, that tells the router where to route inbound packets on 24.157.358.45:4444 to, either to 192.168.1.2:4444 or to 192.168.1.3:4444, otherwise the packet will be discarded. So no, both of your listening servers will not see the same packet.
Once a TCP connection is established, the router knows which specific LAN machines are associated with which connections and will route incoming packets belonging to those connections accordingly.
The previous answers are correct, you need to enable port forwarding. If it is not enabled port 4444 will be closed on the router.
It sounds like you have multiple servers and want to forward to whatever server is turned on at the moment. This is not possible (*), the router does not care whether or not PC1 or PC2 are listening on port 4444, it will simply forward everything to the address configured in the port forwarding.
(*): Ok it is possible but it takes some extra work.
Solution 1: Trick the router into thinking there is only one server. Give PC1 and PC2 a virtual network interface with the same IP address and forward to that address. Make sure only one of these interfaces is enabled, having duplicate IP addresses in your network can have unintentional behaviour.
Solution 2: Make the router care about which server is on. You will need to write a program to run on the router (or on another server) that can detect which server is on and forward the packets accordingly. If you are using Linux the program iptables can be worth looking at.
So right now I'm using only TCP for my clients - they connect to the server, open socket and freely getting packets.
But what if I will decide to use also UDP in my game? Will they gonna have to open ports? For example, if they are using a regular WiFi, can I send UDP to the client without having opening ports problem?
Thanks.
TCP and UDP are just two examples of transport layer implementations. Both of them are using term 'port' to determine which app should receive incoming packet, but they could be routed/filtered differently by routers/switches/firewalls/etc.
So the answer is no. You will have similar problems with opening ports. Just except 'TCP port xxx should be opened' you have to demand 'UDP port xxx should be opened'.
In most home networks firewall rules allow outgoing packets (requests) to any remote port (on your server for example, where this port should be opened). And when such a packet goes through a router - it creates temporary rule to allow answers come back to the local port from which request packet.
So, normal scenario is like that:
Packet originated from home computer with IP 5.5.5.5. Lets say it has source UDP port 55555, source IP address 5.5.5.5 and destination port 8888.
Packet reaches home router. As it is going from inside - router allows it to pass through and creates rule say for 2 minutes to allow packets targeted to 5.5.5.5 to UDP port 55555.
Packet reaches corporate router before your server. It has rule to pass packets for port 8888 so packet is allowed to go.
Your server receives the packet and processes it. In response it creates packet for IP 5.5.5.5 and UDP port 55555.
Corporate router allows response to go.
Home router allows response to go according to temporary rule.
Your computer receives the response.
Corporate computers and routers often more restrictive to ensure security, so second point could restrict packet if your user (IP 5.5.5.5) is in corporate network.
It is very simplified as in reality there's almost always things like NAT and rules are more complex... But in general it gives the idea how it works internally.
The scenario is the following. I have two machines A and B:
A: Client (behind NAT)
B: Server (behind NAT)
I want B to be able to listen on any given port, so that A can send packets to B through that specific TCP port and receive any response. If both machines are not behind a NAT it is pretty straight foward process. However how do I make it work so that it works even when B is behind a router, without him having to go change the router configuration enable some port forwarding etc...
For example, how do peer-to-peer programs like torrent clients work without the user having anything to configure?
To answer the example of Peer to Peer programs, and in general: There is a technology called Universal Plug and Play which NAT routers can use to allow clients behind them to expose ports to the outside. That's what bittorrent clients can use so the other clients can directly connect to them.
An alternative to a proxy server is a match-making server. Instead of proxying all of the traffic, the match maker just negotiates until the peers can talk to each other. This involves finding the external public IPs of the peers and talking to each one so that the firewall/router knows that the peers wish to communicate.
This is called hole punching and it often has to be done by the match maker rather than the peers themselves. Once the hole are punched though, the match maker can tell the peers about each other and they can communicate directly.
You will have to either:
Set up port forwarding from the nat
gateway in front the server into the machine your server software is running, and have the client
connect to the IP address of that
gateway.
Create a proxy server sitting
inbetween the 2 nat gatewys so both
your server and client can connect
to that. Both your server and client
have to set up a connection to that
proxy which will mediate the data
between those 2 connections.
Hole punching is moderately well-understood for UDP communication, but it can be reliably used to set up peer-to-peer TCP streams as well. Here is the well detailed article on both TCP and UDP:
http://www.brynosaurus.com/pub/net/p2pnat/