This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

[7.402] Update Killed SIP registrations

Hi all
After installing Update 7.402 on to an ASG my VOIP system was unable to register back to the SIP Hosts.
The last change to this configuration was many months ago.
(The ASG is configured to protect a VOIP stand alone network with the following services running on the ASG Box. Intrusion Prot, IM, & SMTP Proxy.)
(and yes I have rebooted all boxes.)

Anybody else having problems?


Astaro any thoughts?


This thread was automatically locked due to age.
Parents
  • Can you please be more specific?

    I've tested SIP with X-Lite Softphone from sipgate.de and also used sipgate as provider (217.10.0.0/16) and it worked in both directions, outgoing and incoming calls. All this without having to reconfigure anything on X-Lite.

    If you had to manually create packetfilter rules etc., please deactivate them now with v7.402. Also deactivate any 'smart behaviour' on your SIP Clients, the ASG should now completely take care of dynamically opening ports for SIP calls etc.

    What is known being defect since v7.402 is the SIP statistics. Just ignore them for now.
  • I have an Asterisk IP PBX with 2 VOIP Trunks.
    These Trunks register to a VOIP supplier via port 5060.
    Prior to 7.402 patch I had in the "SIP Protocol Support"
    In the "SIP server networks" I had the VOIP SIP Servers.
    In the "SIP client networks" I had the Internal VOIP Network (Where the IP PBX and IP Pones Live).
    In the Packet filter rules I allowed Rules that where required to connect to the VOIP Supplier.
    In DNAT I had Rules that allow IP PBX and VOIP Supplier to setup calls.
    With the above configuration, all was OK.

    When Patch 7.402 was installed the IP PBX was unable to register the 2 VOIP Trunks.
    Turning OFF the SIP "SIP Protocol Support" All works again.

    As Most VOIP Providers require different setups to run an IP PBX, is there any detailed documentation on this function.

    Mark
  • Please try to disable your SIP packetfilter rules as well as your SIP related DNAT rules. With v7.402, everything (!) regarding SIP is fully automated using the SIP configuration on ASG.
  • Hi Mario,
    let me see if I understand what you post says.
    I have 2 VoIP phones provided by different ISps, the only similarity is they both use UDP port 5060. Are you saying that the ASG SIP will identify the ports that each uses and create rules for those ports as well as QOS settings? 
    I have one DNAT rule for one of the phones, otherwise the other just uses the standard MASQ used by all applications.

    Ian M
    After thought, does that imply I have duplicated rules for some of the packet filter and NAT setup?

    Or am I confusing SIP setup with allowing rtp packets through the ASG. I don't have any rules for the SIP traffic other than the SIP setup.
  • I just want to say that you don' t have to configure any DNAT or packetfilter rules for SIP to work since v7.402. Doing so may confuse the SIP conntrack helper and it may not work.

    Just put your SIP provider network(s) in "VoIP Security -> SIP -> SIP server Networks" and your phones network(s) in "SIP client networks" and you are all set.

    QoS is another story - you still have to take care of that.
  • Hi Mario,
    a task for tomorrow night after work, disable all the packet filter rules and the dnat. Also I added the rtp ports used by each ISP to the VoIP group.

    I will do a save, remove all the extra bits try it out and let you know.

    Ian M
  • Hi Mario,
    that was a huge improvement over previous versions. I removed all the VoIP filters and services I had created and the services still worked. Excellent, the worst part is I now have to put the services back to get QOS working on VoIP ports.

    Thank you to the ASG Team for simplifying the VoIP connectivity.

    Ian M[[[:)]]][[[:)]]][[[:)]]]
  • Welcome to the beautiful world of stateful firewalling [:D]
  • Mario,
    the part I like is not having to hunt for ways to allow seemingly unrelated answers for ISP VoIP servers through the ASG. Until this version I was always dropping packets because the server the call would initiate to is not the server that would answer.

    I must have missed the specific change of the SIP functionality in the last beta or two.

    Ian M
  • Thanks Mario 
    For your detailed response. [:)]

    I have deleted the DNAT RTP rule as well, as from what I understand (from above) the Helper will setup the RTP channel.
    This does indeed make VOIP a lot easier. This changes from 5 to 2 DNAT rules required for VOIP.

    Good work Team
    We out here in the field just need to know just a little more on the technical side of these helpers and features sometimes.
    Mark
  • Can someone write up a "Best Practices" for VOIP and/or SIP?

    I have a single VOIP (SIP) line from AT&T (who happen to be discontinuing service so I'll be switching to BroadVoice soon)...

    I've had this longer than Astaro had "VOIP Security" features, so I've always just used DNAT and PF to get it to work, and it's been fine, but now I'm wondering if it would be better to use the Astaro VOIP features?

    I don't have a list of AT&T's servers so I just did a whois and added their netblocks... I realize this isn't extremely secure...
    but, without knowing the exact servers, what should I put in the VOIP settings, the netblocks?

    Also, QOS details would be nice.
    I _think_ I have it setup right, but if I let BitTorrent go all-out, and then get a phone call, the quality is terrible.
    Someone on another thread said that QOS can't modify existing connections; it can only control new ones... is that right?

    Thanks!
    Barry
  • Hi Barry,
    while your approach might not seem that secure it is quite secure in practice. With one of my ISP (VoIP) I was not able to determine their servers, kept changing on a random basis, so I opened the destination to any. I was surprised who many strange SIP servers my phone attempted to register with. In the end I did the same as you a small ip block and that stopped all the junk.

    This is very impressive from my point of view, because I was one of couple who complained Astaro had got it wrong in their first attempt. I stil haven't recreated the qos target groups yet, I am waiting for my wife to make a long overseas call and tell me whether there is any improvement or not, that will decide the qos setup.

    Ian M
Reply
  • Hi Barry,
    while your approach might not seem that secure it is quite secure in practice. With one of my ISP (VoIP) I was not able to determine their servers, kept changing on a random basis, so I opened the destination to any. I was surprised who many strange SIP servers my phone attempted to register with. In the end I did the same as you a small ip block and that stopped all the junk.

    This is very impressive from my point of view, because I was one of couple who complained Astaro had got it wrong in their first attempt. I stil haven't recreated the qos target groups yet, I am waiting for my wife to make a long overseas call and tell me whether there is any improvement or not, that will decide the qos setup.

    Ian M
Children
  • Well back to the drawing board for me after the above setup working for a day after last changes(still strange that a day later after last changes that it stopped working), The RTP associated traffic with a SIP call the RTP setup failed.
    So Do you still require a RTP DNat Rule?

    Added the removed RTP PF rule that I removed from above post.

    Still testing Not Qute right yet.

    Mark. [:)]
  • Hi Mark,
    I have two device definitions, one for each phone and two ISP definitions again one for each ISP networks. I have treated each ISP's SIP site as a number of boxes so they can grow without causing me any grief. One is a dns pool, the other is sub range.

    I use the MASQ for for each of my internal networks.

    One thing I haven't tried is powering everything off then seeing if the registration works.

    Ian M
  • I had a support case about some VOIP problems I was having, which cleared up in 7.402, and I asked Astaro if I should be using the VOIP Security features (since it always worked before without)...

    Astaro support says that it is recommended to use the SIP proxy (VOIP Security, I presume).

    Anyways, I'm moving to a new house this weekend, but will switch the configuration soon.

    Barry
  • Mark's current findings[:)].
    Current SETUP.
    Definitions » Networks » Sip Server is defined as a DNS Group (Interface RED).
    SIP Protocol Support » SIP server networks= Sip Server is defined in DNS Group.
    SIP Protocol Support » SIP client networks= Asterisk BOX (IP PBX).
    Network Security » Packet Filter. Host Asterisk Any VOIP RTP 10000:20000.
    Network Security » NAT. DNAT [Asterisk RTP Voip] Voip Asterisk Traffic selector: Any→RTP 10000:20000→Red (Address) Destination translation:Host Asterisk RTP 10000:20000 Automatic packet filter rule:

    I added the PF and DNAT rule after VOIP stopped working approx 12hours after last change.(ie change done approx 4pm. The Next day at about 1pm all OK at 2:30pm Call setup OK but no Voice.) Rolled back config 3 days earlier enabled above and all working.
    Next is to take out RTP DNAT as per earlier post saying Helper should take care of VOIP.

    Will update after next change.

    The SIP Proxy the you mention Barry can be very misleading as you say.As a SIP Proxy and Registration Server are 2 different services (yet these services can be supplied by the same BOX).
    For SIP Registrations you should use the SIP server supplied by the VOIP Provider.
    IF a SIP Proxy is supplied by the VOIP Provider I would assume you would enter this into SIP Server Network "Area". The Phones or PBX would be required to know about the SIP Proxy into there "Settings".

    Ian that is how I would have said that I had my setup in 7.401 and when patch 7.402 came along I was unable to register to SIP Servers turning off Helper and all OK. From what I understand from the above posts you do not require any MASQ rules as the SIP Helper should that care of all of the SIP VOIP call details.

    Mark
  • I had a support case about some VOIP problems I was having, which cleared up in 7.402, and I asked Astaro if I should be using the VOIP Security features (since it always worked before without)...

    Astaro support says that it is recommended to use the SIP proxy (VOIP Security, I presume).

    Anyways, I'm moving to a new house this weekend, but will switch the configuration soon.

    Barry


    Good luck on your move, helping a buddy move in a couple of weeks, not a lot of fun, even with help!
  • [quote=
    Ian that is how I would have said that I had my setup in 7.401 and when patch 7.402 came along I was unable to register to SIP Servers turning off Helper and all OK. From what I understand from the above posts you do not require any MASQ rules as the SIP Helper should that care of all of the SIP VOIP call details.

    Mark[/quote]

    I have to assume that your ISP is using standard SIP of 5060 UDP/TCP, otherwise the rules change.
    I you are using 5060 then it should automatically hang together with entries in 2 fields of the SIP security setup.

    Ian M
  • I needed to Reboot the Asterisk Box today and I again failed to receive SIP registrations and First call had one way conversation. Returned back to OLD pre 7.402 config and all working again.
    I have submitted a support case.
    Yes SIP = 5060 UDP
    If any body here interested I will add my finding to this post.
  • Mark_D

    How did you get on with your findings?
    Any solution from the support case?

    Regards,
    Grant
  • Due to an issue with port 4444 being blocked, the Astaro Team have Logged in a couple of times but until the issue with port 4444, 4443 being blocked inbound is fixed, nothing has changed.

    I have now setup a dedicated packet analyser across a span port to help.

    Will update when anything new comes along.
     
    Mark
  • The issue with port 4444 being blocked has been resolved.
    So hopefully tonight Astaro will be able to login.

    Mark