Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    SIPROXD Transparent Proxy

    Scheduled Pinned Locked Moved pfSense Packages
    10 Posts 5 Posters 12.9k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • M
      mwalsh
      last edited by

      Any idea how to make SIPROXD a transparent proxy?

      Thanks,

      Mike

      1 Reply Last reply Reply Quote 0
      • S
        sullrich
        last edited by

        I believe it already is.

        1 Reply Last reply Reply Quote 0
        • M
          mwalsh
          last edited by

          It doesn't seem to be working transparently since I am still getting one-way audio. I believe the issue is that the port 5060 packets aren't being redirected to the SIPROXD app but my BSD knowledge is too limited to know how to check my hypothesis.

          Thanks,

          Mike

          1 Reply Last reply Reply Quote 0
          • M
            Master One
            last edited by

            I can second that. SIPROXD is not working as transparent proxy out of the box, because therefor all traffic on port 5060 needs to be routed through SIPROXD, and that's not the case. To use SIPROXD, you need to define it as the SIP outbound-proxy (means address of LAN interface at port 5060) in the used VoIP application.

            I was playing around with it all day, because asterisk does not support setting a SIP outbound proxy, that's why it will only work, if SIPROXD is used as a transparent proxy.

            To make it work, all outgoing SIP traffic needs to be redirected to SIPROXD, as seen here with the example for iptables:

            redirect outgoing SIP traffic to siproxd (myself)

            iptables -t nat -A PREROUTING -m udp -p udp -i eth0 –destination-port 5060 -j REDIRECT

            But whatever I tried, I could not replicate that rule by setting up a NAT Port Forward.

            Is this functionality just not working on pfSense?

            1 Reply Last reply Reply Quote 0
            • M
              Master One
              last edited by

              This is weird:

              SIPROXD is listening on LAN (em0) 192.168.1.1:5060, so the only possible redirection rule looks like this:

              rdr on em0 inet proto udp from any to any port = 5060 -> 192.168.1.1 port 5060
              

              Is this supposed to work?

              How about letting SIPPROXD listen on LAN (em0) 192.168.1.1:5061, and redirect this way:

              rdr on em0 inet proto udp from any to any port = 5060 -> 192.168.1.1 port 5061
              

              Does this make a difference? I don't think so, because AFAIK a NAT rule on the same interface just doesn't work that way (which is supposed to be possible with iptables just due to that 'trick' with PREROUTING).

              Looks like the only logical way to handle such a transparent proxy, is to let SIPPROXD listen on lo0 127.0.0.1:5060, and do the redirecting as:

              rdr on em0 inet proto udp from any to any port = 5060 -> 127.0.0.1 port 5060
              

              The problem is, lo0 can not be choosen as the inbound interface in the SIPROXD GUI menu, and establishing a pure rdr seems also not to be possible using the NAT Port Forward GUI, because when I enter a port forward which creates the needed rdr rule, it also produces the following nat rule:

              nat on em0 inet proto tcp from 192.168.1.0/24 to 127.0.0.1 port = 5060 -> 192.168.1.1
              rdr on em0 inet proto udp from any to any port = 5060 -> 127.0.0.1
              

              So if this way is the only one supposed to work:

              1. How do I set lo0 (127.0.0.1) as the inbound interface for SIPROXD?
              2. How do I generate the needed rde rule without the nat part?

              1 Reply Last reply Reply Quote 0
              • M
                Master One
                last edited by

                I can confirm now that a rdr to 192.168.1.1 (the LAN interface address) is not working.

                So what's the solution then??? Nobody any idea?

                Is nobody here using SIPROXD?

                SIPROXD in transparent mode is even included in m0n0wall 1.3b now, so all the other projects have it up and running, except pfSense? Can't believe that!

                1 Reply Last reply Reply Quote 0
                • M
                  Master One
                  last edited by

                  Come on guys, does really nobody have a clue? This is a general issue, applying to all creation of a transparent proxy service, and I know it can be solved somehow (just the "how" is still missing).

                  As the option for SIPROXD in transparent mode is just a click away in Endian Firewall and m0n0wall 1.3b, this is a missing feature in the pfSense SIPROXD package!

                  1 Reply Last reply Reply Quote 0
                  • M
                    mwalsh
                    last edited by

                    This is proably a simplistic answer, but isn't squid a transparent proxy?

                    If so you might be able to look at the squid code to see how it was implemented.

                    Mike

                    1 Reply Last reply Reply Quote 0
                    • dotdashD
                      dotdash
                      last edited by

                      Also, if it works on m0n0, one could compare the pfSense package with the m0n0wall version. Although the issue could be that m0n0 is doing something with ipfilter that is harder to do in pf.

                      1 Reply Last reply Reply Quote 0
                      • G
                        gl1176
                        last edited by

                        I just got mine working. Here's a link to my post:

                        http://forum.pfsense.org/index.php/topic,10084.0.html

                        1 Reply Last reply Reply Quote 0
                        • First post
                          Last post
                        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.