0

We have a pair of Internet-facing SIP PROXY/REGISTRAR servers (for resilienced and load-balancing). When a SIP phone registers, it will be handled by one of the REGISTRAR servers (round-robin DNS) - and since this registration is renewed, the firewall port/address translation is maintained. Therefore, when a call is to be sent back to the phone the INVITE message passes successfully through the firewall.

However, it is likely that the phone may register with one of the two servers, but the INVITE may come from the other. In this situation, the call fails since there is no translation in place on the firewall.

Is there a feature in the SIP protocol to facilitate this? Any other ideas? As our traffic grows, we will no doubt end-up with more than two servers - so the problem will escalate.

Thanks,

Mike

MikeBrom
  • 31
  • 3

2 Answers2

1

We had the same problem on a Juniper SRX on junos 12.1R2.9.

The SIP provider has 4 IP addresses which change by DNS round robin, and obviously hundreds (max 512 IP addresses) that sent the RTP packets.

The previous firewall was a Snapgear, old, but with ease of use. The Juniper has symmetric NAT and seems more strict.

We managed to get audio from inside to outside using a persistent source nat.

For audio from outside to inside, we had to add a source nat rule:

  1. Disable SIP ALG when in use.
  2. Make sure you connect always to the same IP of the SIP provider (say 131.131.160.2).
  3. If traffic comes in from the IP range of SIP provider, then map source address to the same IP address 131.131.160.2.

The persistent NAT ensures that the traffic is allowed. Obviously it works. Perhaps step 2 can be skipped but given the amount of down time so far I have left it in.

nat { source { pool sip-zipt-nl-no-round-robin { address { 131.131.160.2/32; } } address-persistent; interface { port-overloading off; } rule-set trust-to-untrust { from zone trust; to zone untrust; rule source-nat-rule { match { source-address 0.0.0.0/0; } then { source-nat { interface { persistent-nat { permit any-remote-host; } } } } } }

rule-set sip-incoming { from zone untrust; to zone trust; rule sip-zipt-nl-no-round-robin { match { source-address 131.131.160.0/23; destination-address 0.0.0.0/0; } then { source-nat { pool { sip-zipt-nl-no-round-robin; } } } } } }

Guido Leenders
  • 11
  • 1
0

The actual problem is that your proxy/registrars do not share the registration database .

jgauffin
  • 139
  • 1
  • 13
  • Thanks for taking the time to reply - unfortunately this is not the case here. – MikeBrom Oct 25 '10 at 12:23
  • The registrars are sharing the database - and we have used Wireshark to confirm that the issue is with the dynamic associations on the client firewall. I need to find a way to convince the firewalls to open-up another association - or work around the problem in another way. Unfortunately due to load balancing I can't control which proxy the subsequent INVITE will come from. – MikeBrom Oct 25 '10 at 12:24