| This article describes how STUN protocol works to resolve the SIP Nat issues |
|
Session helper / SIP ALG translates the SIP and SDP parameters when the packet is sent to the SIP provider. Fortigate will also open pinholes dynamically based on the “c=” and “m=” attributes in the SDP packet. Some SIP providers recommend disabling session helper or ALG. In this case, how can the SIP NAT issues be resolved?
STUN can be used to resolve this issue. First, let us understand what is STUN protocol. Session Traversal Utilities for NAT, provides a tool for dealing with NATs. It provides a means for an endpoint to determine the IP address and port allocated by a NAT that corresponds to its private IP address and port. It also provides a way for an endpoint to keep a NAT binding alive.
STUN is a client-server protocol. It supports two types of transactions. One is a request/response transaction in which a client sends a request to a server, and the server returns a response.
Topology:
In this topology, Client-1 (soft client) is registered to PBX hosted in cloud. Client-1 is trying to call Client-2 on its extension (in a real world this would actual phone number).
Some SIP providers recommend disabling SIP session helper or SIP ALG. In this case, the provider will suggest an alternate solution to address the NAT issue. STUN is one of the solution to address this issue.
How STUN works?
STUN server sits somewhere in public internet, waits for incoming requests, examines packet source IP and port, packs this information as STUN response, and replies to the request with the information it discovered. This way client behind NAT are able to find out about their public ip address/port pair and use that when they need to pass this to remote peer in order to receive audio on that IP/port pair.
Soft phone on client-1 is brought up , and we can see the STUN messages/response and SIP register / 200 OK. Bind request from 192.168.250.100 to 10.10.104.4 is nat’d and sent out via wan.
LAN PCAP (Bind request)
WAN PCAP (Bind request)
Below are the BIND response from STUN server: WAN PCAP (Bind Response)
STUN Server is telling the client that it got the bind request from IP “10.10.101.2” and port “56343”.
FortiGate will perform session lookup and will do the DNAT to 192.168.250.100.
LAN PCAP (Bind Response)
With this information, Client-1 can craft the SIP Signaling messages. Client-1 sends SIP Register message to the PBX server. If the authentication is successful, PBX server will return with SIP 200 OK message.
LAN PCAP (SIP Register)
In the LAN PCAP, we can see that the SIP headers has the wan interface IP address. If STUN was not used and session helper/ALG was disabled then the same PCAP on the LAN side would have the client’s IP address in the SIP headers.
FortiGate will create a new session for this flow and will route to packet to the PBX.
WAN PCAP (SIP Register)
Shown below are the response from the PBX server.
WAN PCAP (200 OK)
Session lookup is performed and the traffic is sent to the client.
LAN PCAP (200 OK)
Logging into the PBX to make sure, if it has learnt the correct IP addresses of the softphones.
Now let us make call from Client-2 to Client-1 and review the SIP and RTP packet flows.
Show below are the packet exchanges between Client-1 and PBX when Client-2 is initiating the call.
WAN PCAP (SIP Invite)
PBX is sending the SIP invite message to Client-1(connected behind the Firewall). In the PCAP, PBX wants Client-1 to send audio traffic on IP address 10.10.101.7 and on port 12022.
Fortigate will find existing session as the IP-tuple is the same as seen in the SIP register message. After the session lookup, traffic will be forwarded to Client-1,
Client-1 sends Bind request again: LAN PCAP (Bind request)
WAN PCAP (Bind Request)
STUN server responds with mapped IP address 10.10.101.2 and port 64416.
WAN PCAP (Bind response)
Response is sent to the client,
Now Client-1 constructs SIP 200 OK packet based on the STUN response LAN PCAP (SIP 200 OK)
Again, without STUN or session helper/ALG , in this pcap client would have added its own IP address and port for the SDP parameters.
FortiGate forwards the SIP 200 OK to the PBX,
WAN PCAP ( SIP 200 OK )
Based on the SIP signaling messages,
Audio Traffic to PBX should be sent to 10.10.101.7 and on port 12022 and Audio Traffic for Client should be sent to 10.10.101.2 and port 64416
Now let’s confirm if the Audio traffic is sent and received based as seen on the signaling messages.
LAN (RTP – from client to PBX)
WAN (RTP- from client to PBX)
WAN ( RTP from PBX to Client-1)
LAN ( RTP from PBX to Client-1)
No audio issues observed. There are no helper/ ALG in this case. Therefore, no expectation session will be created.
Extras: Firewall Configuration:
|
