Zeroshell with multiple SIP devices and multiple WANs?

Home Page Forums Network Management ZeroShell Zeroshell with multiple SIP devices and multiple WANs?

This topic contains 6 replies, has 0 voices, and was last updated by  atheling 9 years, 6 months ago.

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • #41936

    atheling
    Member

    I’ve reached the limits of my older commercial dual-wan firewall/router and am considering using Zeroshell. I’ve done a number of searches on Zeroshell but I don’t see anything that seems to directly answer my questions. Please excuse me and point me to the appropriate information if I’ve missed it.

    Environment:
    Two ISPs with fixed IP addresses. The DSL line uses PPPoE (bridged from PPPoA in the modem). The cable modem dishes out an address via DCHP. While the protocols could use dynamic IP, I am paying for and getting static IP values with appropriate reverse DNS.

    I have a number of SIP ATAs on the LAN. I have a SIP IP phone and a SIP soft phone that can rove outside the LAN. All currently register with an Asterisk server on the LAN. I have been using port mapping on the current firewall router to send all SIP and RTP traffic to the Asterisk box and I have configured Asterisk so that none of the ATAs are allowed to “re-invite”. So all the RTP traffic goes through the Asterisk box.

    My problem is my VoIP provider recently changed things so that I need to use t.38 on the ATA attached to the FAX machine. And for that to work a “re-invite” to change from g711 to t.38 is needed. So the t.38 UDP datagrams are going directly to the firewall. Return traffic is not going to the ATA so the FAXes fail.

    Is Zeroshell smart about handling SIP? That is can I configure the system so that the RTP and t.38 UDP traffic can go directly to the firewall bypassing the Asterisk box? I understand that some “deep inspection” of the SIP datagrams by the firewall/router is needed to make this work.

    Secondly, I primarily use one ISP link for VoIP and the other for everything else. But for redundancy I have my MX and SRV records set so that non-VoIP traffic might be carried on the VoIP link and incoming calls might occur on the non-VoIP link. How smart is Zeroconf about coorelating the link the SIP traffic is on with the link the RTP traffic is on?

    Finally, will the SIP datagrams be rewritten as required to reflect the public IP address of the link they are sent on. That is can I drop the “public IP” setting out of Asterisk? This would allow me to have an automatic failover of my VoIP traffic when a link goes down (currently I need to do a manual change to get things working again).

    Thanks!

    (edit to a typo)

    #48793

    atheling
    Member

    To answer my previous post, Zeroshell 1.0.beta12 does correctly support QoS, multiple WANs with load balancing and public servers on the LAN.

    I have submitted changes to Fulvio to correct those issues that blocked me and at this point am happy with how Zeroshell is working. There are some remaining issues I am looking at but they are very minor and do not detract from my current operation.

    I am to the point where my issue with T.38 appears to be in my Asterisk version/setup (a separate box). The Zeroshell box (a Soekris net5501 with added Ethernet NIC) can be setup to deal correctly with tracking SIP connections and properly handling the forwarding of the associated RTP stream.

    You can make a beta12 Zeroshell handle QoS, multiple WANs and externally accessible hosts by overriding what it does in the mangle table in the underlying Linux iptables. Or you can wait for the next Zeroshell beta which I believe will have my changes included.

    #48794

    ieee754
    Member

    hi atheling –

    can i ask what you mean by “overriding what it does in the mangle table” ?

    I am having all sorts of trouble getting SIP to work through my zeroshell.

    for the purposes of testing i have completely erased my output/input/forward chains and set them to ACCEPT.

    i have net balancer turned on.
    i have a rule setup to direct all traffic from my asterisk box, 192.168.61.250, out on ppp0.
    i have a virtual server entry for udp 5060 and udp 10000-20000 to forward to 192.168.61.250

    i can see the asterisk registration attempts going out through the connection monitor – with a [UNREPLIED] state next to each attempt.

    i can see the following in the PRE/POSTROUTING chains:


    Chain PREROUTING (policy ACCEPT 2964 packets, 280K bytes)
    pkts bytes target prot opt in out source destination
    0 0 DNAT tcp -- ppp3 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:1723 to:192.168.61.2:1723
    0 0 DNAT tcp -- ppp3 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:4125 to:192.168.61.2:4125
    5 276 DNAT tcp -- ppp3 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:25 to:192.168.61.3:25
    4 220 DNAT tcp -- ppp3 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 to:192.168.61.2:443
    0 0 DNAT udp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:5060 to:192.168.61.250:5060
    0 0 DNAT udp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 udp dpts:10000:20000 to:192.168.61.250:10000-20000

    Chain POSTROUTING (policy ACCEPT 219 packets, 17960 bytes)
    pkts bytes target prot opt in out source destination
    2625 235K SNATVS all -- * * 0.0.0.0/0 0.0.0.0/0
    651 59278 MASQUERADE all -- * ppp0 0.0.0.0/0 0.0.0.0/0
    137 12877 MASQUERADE all -- * ppp1 0.0.0.0/0 0.0.0.0/0
    135 12392 MASQUERADE all -- * ppp2 0.0.0.0/0 0.0.0.0/0
    202 18911 MASQUERADE all -- * ppp3 0.0.0.0/0 0.0.0.0/0

    Chain SNATVS (1 references)
    pkts bytes target prot opt in out source destination

    naturally the asterisk box complains there is no response.
    you can see my mail port fwd working fine in the above table.
    you can see 0 packets being fwd that match the 5060 rule.

    any suggestions?

    i am completely at a loss here. thanks.

    #48795

    ppalias
    Member

    Change the virtual server to source port UDP 5060. I don’t think that after the PAT the packet still has 5060 as the source port.

    #48796

    ieee754
    Member

    @ppalias wrote:

    Change the virtual server to source port UDP 5060. I don’t think that after the PAT the packet still has 5060 as the source port.

    makes sense. so you are suggesting that after PAT the source port is modified / translated and the reply would be to that port, instead of 5060? am i understanding you correctly?

    here is my virtual server setup;

    obviously these are setting up dst port fwds – how do i (manually?) modify them to srcport ?

    thanks ppalias![/img]

    #48797

    ppalias
    Member

    Yes, after PAT the port usually changes to some other, so my guess is that the source port in the packet with the public IP address will be other than 5060. But the answer will come back from port 5060 definitely. However ZS keeps track of the connections so it should forward the answer back to your Asterisk, despite the virtual server entry. So my suggestion is the following:

    iptables -t nat -I POSTROUTING 1 -s 192.168.61.250 --sport 5060 -p udp -o ppp0 -j SNAT --to-source 1.2.3.4:5060

    Where 1.2.3.4 is your public IP address of ppp0.

    #48798

    ieee754
    Member

    @ppalias wrote:

    iptables -t nat -I POSTROUTING 1 -s 192.168.61.250 --sport 5060 -p udp -o ppp0 -j SNAT --to-source 1.2.3.4:5060

    Where 1.2.3.4 is your public IP address of ppp0.

    ok – i will give this a shot later today and let you know how i go. thanks again.

    #48799

    atheling
    Member

    Been out of town and away from the computer and then came home to find my web/mail server having hissy fits that needed addressing. Sorry about my delay in answering your query.

    @ieee754 wrote:

    hi atheling –

    can i ask what you mean by “overriding what it does in the mangle table” ?

    There are “marks” that are associated with each packet in the mangle table with in iptables. It is a separate table from the nat or filter tables. You can look at your mangle table with the following command:

    iptables -t mangle -L -v -n

    Zeroshell uses the marks before routing to setup which routing table will be used. This binds connections to interfaces. After routing Zeroshell uses the marking system to setup QoS. The two uses are in conflict as of beta12 so you can’t do multiple WANs and QoS “out of the box”. I submitted fixes for that to Fulvio and he emailed back that they would be in the next release. I don’t know when that release will occur.

    This command will show you which routing rules will be used based on things like the “fwmark” (old name for the mark):

    ip rule list

    And then you can look at the actual routing table with the following (where xxx is one of the tables listed in the rule list from above):

    ip route list table xxx

    The nice little display of routing table given in the UI is actually deceptive: It is only a list of the default routing table made available for view for people who don’t know that “route” has been superceeded by “ip route”.

    @ieee754 wrote:

    hi atheling –
    I am having all sorts of trouble getting SIP to work through my zeroshell.

    …snip…

    It did not work well for me until I added the following to my pre-boot script:

    modprobe nf_nat_sip

    Not sure why it is not part of the standard setup. There is some mention of the older version of nat_sip breaking things in the archives of this forum and/or older release notes (can’t remember which). But it seems to work for me okay.

Viewing 8 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic.