PF rule for transparent siproxd ?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

PF rule for transparent siproxd ?

Christophe-46
Hi list,

I encounter a problem while aptempting to get siproxd acting as a
transparent SIP proxy and PF.

OpenBSD version is 5.4 on amd64.

> OpenBSD 5.4 (GENERIC) #37: Tue Jul 30 15:24:05 MDT 2013
>     [hidden email]:/usr/src/sys/arch/amd64/compile/GENERIC

siproxd installed from package "siproxd-0.8.1p3.tgz"

The setup is as simple as possible (IPv4 only) :

em1 : LAN, 172.18.160.253/24
em0 : WAN with DHCP.

I'm trying to get transparent proxy config as described here :

http://siproxd.sourceforge.net/siproxd_guide/siproxd_guide_c7s4.html

But replacing iptables rules by pf rules.

Content of siproxd.conf is :

> if_inbound  = em1
> if_outbound = em0
>
> hosts_allow_reg = 172.18.160.0/24,127.0.0.1/8
> sip_listen_port = 5060
>
> daemonize = 1
>
> silence_log = 0
>
> user = _siproxd
> chrootjail = /var/siproxd/
>
> registration_file = siproxd_registrations
>
> autosave_registrations = 300
>
> pid_file = siproxd.pid
>
> rtp_proxy_enable = 1
>
> rtp_port_low  = 17030
> rtp_port_high = 17080
>
> rtp_timeout = 300
>
> rtp_dscp = 46
>
> sip_dscp = 0
>
> rtp_input_dejitter  = 0
> rtp_output_dejitter = 0
>
> tcp_timeout = 600
> tcp_connect_timeout = 500
> tcp_keepalive = 20
>
> debug_level = -1
> debug_port = 5050
>
> plugindir=/usr/local/lib/siproxd/
> load_plugin=plugin_logcall.so
>

Using outbound SIP proxy on (soft)phones let me know that siproxd config
is working. But it's not the goal :

The goal is to accept every SIP device from inside the LAN to register
to SIP provider without any "outbound proxy" configuration, and let
siproxd acting as a masquerading server.


PF rules :

> set skip on lo
> set loginterface pflog0
>
> block in on ! lo0 proto tcp to port 6000:6010
>
> match out log on em0 inet from 172.18.160.0/24 to any nat-to em0
>
> pass in on em1 inet proto tcp from 172.18.160/24 to any port { 80, 443 } keep state
> pass in on em1 inet proto icmp from 172.18.160.0/24 to any keep state
>
> pass in on em0 inet proto tcp from any to em0 port 22 keep state
> pass in on em0 inet proto icmp from any to em0 keep state
>
> # Here is the rule I try to use .
> pass in log on em1 inet proto udp from 172.18.160.0/24 to any port 5060 divert-to 172.18.160.252 port 5060
>
> pass in on em0 inet proto udp from any to em0 port 5060 keep state
> pass in on em0 inet proto udp from any to em0 port 17030:17080 keep state


I tried several rules but none of them redirects packets on siproxd (no
log on siproxd) , and none of them logs to pflog0 interface :( .

pass in log on em1 inet proto udp from 172.18.160.0/24 to any port 5060
divert-to localhost port 5060

pass in log on em1 inet proto udp from 172.18.160.0/24 to any port 5060
divert-to 127.0.0.1 port 5060

pass in log on em1 inet proto udp from 172.18.160.0/24 to any port 5060
divert-packet port 5060

pass in log on em1 inet proto udp from 172.18.160.0/24 to any port 5060
rdr-to 127.0.0.1 port 5060

pass in log on em1 inet proto udp from 172.18.160.0/24 to any port 5060
rdr-to 172.18.160.252 port 5060

The only one that can log in pflog0 is :

pass in log on em1 inet proto udp from 172.18.160.0/24 to any port 5060
keep state

But it doesn't fit my needs ...

I'd like to be as simple as redirecting FTP traffic on ftp-proxy;
Redirect SIP requests to a local service than can handle rewrite of
packets.

Final goal is to replace Cisco routers (that handle SIP inspection and
redirect public RTP ports to the appropriate device) by OpenBSD.

Any ideas ?

Regards,
Christophe.

Reply | Threaded
Open this post in threaded view
|

Re: PF rule for transparent siproxd ?

Simon Perreault-3
I don't know the direct answer to your question, but taking a step back...

Any reason you want a transparent SIP proxy rather than an
explicitly-configured SIP B2BUA? The latter is usually much easier to
set up and maintain.

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

Reply | Threaded
Open this post in threaded view
|

Re: PF rule for transparent siproxd ?

Stuart Henderson
In reply to this post by Christophe-46
On 2014-04-07, Christophe <[hidden email]> wrote:
> The goal is to accept every SIP device from inside the LAN to register
> to SIP provider without any "outbound proxy" configuration, and let
> siproxd acting as a masquerading server.

Do you really need it? Most user-facing SIP providers run SBCs to work
around NAT problems (amongst other things) and either don't need, or
work better without, SIP NAT helpers.

Reply | Threaded
Open this post in threaded view
|

Re: PF rule for transparent siproxd ?

Christophe-46
In reply to this post by Simon Perreault-3
Hi Simon,

Le 07/04/2014 20:20, Simon Perreault a écrit :
> I don't know the direct answer to your question, but taking a step back...
>
> Any reason you want a transparent SIP proxy rather than an
> explicitly-configured SIP B2BUA? The latter is usually much easier to
> set up and maintain.
>

SIP B2BUA can be interesting, thanks for the advice ;).

But in this case, there is already several devices configured.
(different types, and different SIP providers).

If we can avoid reconfiguring all the devices ... ;) .

Christophe.

Reply | Threaded
Open this post in threaded view
|

Re: PF rule for transparent siproxd ?

Christophe-46
In reply to this post by Stuart Henderson
Hi Stuart,

Le 08/04/2014 10:41, Stuart Henderson a écrit :
> On 2014-04-07, Christophe <[hidden email]> wrote:
>> The goal is to accept every SIP device from inside the LAN to register
>> to SIP provider without any "outbound proxy" configuration, and let
>> siproxd acting as a masquerading server.
>
> Do you really need it? Most user-facing SIP providers run SBCs to work
> around NAT problems (amongst other things) and either don't need, or
> work better without, SIP NAT helpers.
>

As you say : most , but not all ... and we have to deal with :( .

Cisco routers (2600 and 800 series) are able to handle this : only
public IP address are seen in SIP packets on external network interface,
without configuring anything in "internal SIP devices" (IPBX or phones).

That's why I try to get a similar behavior using a transparent SIP proxy.

Don't know if it's the best way to do, but from what I know of SIP
protocol and NAT issues, I found it was a nice solution to handle all
cases with minimum configuration (or reconfiguration) ;).


Christophe.

Reply | Threaded
Open this post in threaded view
|

Re: PF rule for transparent siproxd ?

Stuart Henderson
On 2014-04-08, Christophe <[hidden email]> wrote:

> Hi Stuart,
>
> Le 08/04/2014 10:41, Stuart Henderson a écrit :
>> On 2014-04-07, Christophe <[hidden email]> wrote:
>>> The goal is to accept every SIP device from inside the LAN to register
>>> to SIP provider without any "outbound proxy" configuration, and let
>>> siproxd acting as a masquerading server.
>>
>> Do you really need it? Most user-facing SIP providers run SBCs to work
>> around NAT problems (amongst other things) and either don't need, or
>> work better without, SIP NAT helpers.
>>
>
> As you say : most , but not all ... and we have to deal with :( .
>
> Cisco routers (2600 and 800 series) are able to handle this : only
> public IP address are seen in SIP packets on external network interface,
> without configuring anything in "internal SIP devices" (IPBX or phones).
>
> That's why I try to get a similar behavior using a transparent SIP proxy.
>
> Don't know if it's the best way to do, but from what I know of SIP
> protocol and NAT issues, I found it was a nice solution to handle all
> cases with minimum configuration (or reconfiguration) ;).

First diagnosis step with many ITSPs is to disable any such proxies...

Reply | Threaded
Open this post in threaded view
|

Re: PF rule for transparent siproxd ?

Stuart Henderson
In reply to this post by Christophe-46
On 2014-04-07, Christophe <[hidden email]> wrote:
[..]

Let's ignore the siproxd side of things and just look at the ruleset.

>> set skip on lo
>> set loginterface pflog0
>>
>> block in on ! lo0 proto tcp to port 6000:6010
>>
>> match out log on em0 inet from 172.18.160.0/24 to any nat-to em0
>>
>> pass in on em1 inet proto tcp from 172.18.160/24 to any port { 80, 443 } keep state
>> pass in on em1 inet proto icmp from 172.18.160.0/24 to any keep state
>>
>> pass in on em0 inet proto tcp from any to em0 port 22 keep state
>> pass in on em0 inet proto icmp from any to em0 keep state
>>
>> # Here is the rule I try to use .
>> pass in log on em1 inet proto udp from 172.18.160.0/24 to any port 5060 divert-to 172.18.160.252 port 5060
>>
>> pass in on em0 inet proto udp from any to em0 port 5060 keep state
>> pass in on em0 inet proto udp from any to em0 port 17030:17080 keep state

You have no "pass" or "block" rules for any outbound traffic so the implicit
default is used for outbound traffic - this is "pass all no state" - I would
start the ruleset with an explicit "block" and then perhaps "pass out" if
that's what you want.

Reply | Threaded
Open this post in threaded view
|

Re: PF rule for transparent siproxd ?

Christophe-46
Hi Stuart,

Le 08/04/2014 18:31, Stuart Henderson a écrit :

> On 2014-04-07, Christophe <[hidden email]> wrote:
> [..]
>
> Let's ignore the siproxd side of things and just look at the ruleset.
>
> You have no "pass" or "block" rules for any outbound traffic so the implicit
> default is used for outbound traffic - this is "pass all no state" - I would
> start the ruleset with an explicit "block" and then perhaps "pass out" if
> that's what you want.
>

Oops, true ! I made a `grep -v` mistake ... Sorry :( .

Here is the real ruleset, that effectively contains block and pass
"default" rules.

> set skip on lo
> set loginterface pflog0
>
> block in log
> pass out  
>
> block in on ! lo0 proto tcp to port 6000:6010
>
> match out log on em0 inet from 172.18.160.0/24 to any nat-to em0
>
> pass in on em1 inet proto tcp from 172.18.160/24 to any port { 80, 443 } keep state
> pass in on em1 inet proto icmp from 172.18.160.0/24 to any keep state
>
> pass in on em0 inet proto tcp from any to em0 port 22 keep state
> pass in on em0 inet proto icmp from any to em0 keep state
>
> pass in log on em1 inet proto udp from 172.18.160.0/24 to any port 5060 divert-to 172.18.160.253 port 5060  
>
> pass in on em0 inet proto udp from any to em0 port 5060 keep state
> pass in on em0 inet proto udp from any to em0 port 17030:17080 keep state



Regards,
Christophe.