Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 2 subscribers
  • Views 2295 views
  • Users 0 members are here
Options
Suggested
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.002] SIP (UDP) Connections "dead" after PPPOE Reconnect

KoC
This is the 3rd time, i am documenting this bug:

Secenario:
- ASL [7.000]-[7.002]
- PPPOE with static IP Adress
- Internal Network is Masqueraded on PPPOE Interface
- SIP-Proxy configured
- Internat Asterisk PBX

Problem:
- The Voip connections work well
- the Peers are shown as "registered"

- when the PPPOE Interface has reconnected, the PBX show "request send", it seems the packages are no longer sent by the PPPOE Interface.

Maybe it's important to know that asterisk only uses UDP Traffic on Port 5060 (not TCP). The same happens to other udp packages. For Example IAX Voip Traffic which is also using UDP. For IAX Packages if figured out:
If the pbx stops sending any IAX-udp packages for the amount of time specified in:
/proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout_stream 
and starts sending afterwards, everything works again.

For SIP-Packages a much longer time is neccessary to get the PBX registered again. I couldnt found the refering value until know.

On an other Linux IP-Router the following solution helps. In the IP-DOWN and IP-UP script the conntrack is cleared. 

Because i reported this already in the beta and Nobody from Astaro replied until know, i would like to ask : "Is Astaro working on this issue? May i provide additional Informations an this issue? When will Astaro fix this ?" The  ASG7 is preventing the use of our VOIP telephony system :-(

Regards KoC


This thread was automatically locked due to age.
Parents Reply Children
  • 0 in reply to mhaase
    Hi there, 

    the problem in your case is not the UDP timeout, but the PPPoE reconnect with static ip addresses.

    The linux kernel as an integrated cleanup of old connection tracking entries, when an interface goes down or changes. In your case the interface changes (for a short amount of time) but still has the same ip address. In this case, the cleanup code thinks that everything is fine, but it aint, as the internal interface ID changed, which the connection tracking code uses to replace the masqueraded addresses, which now fails.

    A shorter UDP timeout is a sort of workaround, but not a fix.
    We are currently investigating this issue, but a final fix is not easy to find.

    best regards
    Gert