Re: PF rule for transparent siproxd ?
Hi Stuart,
Le 08/04/2014 18:31, Stuart Henderson a écrit :
> On 2014-04-07, Christophe 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.
Re: PF rule for transparent siproxd ?
On 2014-04-07, Christophe 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.
Re: PF rule for transparent siproxd ?
On 2014-04-08, Christophe wrote: > Hi Stuart, > > Le 08/04/2014 10:41, Stuart Henderson a écrit : >> On 2014-04-07, Christophe 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...
Re: PF rule for transparent siproxd ?
Hi Stuart, Le 08/04/2014 10:41, Stuart Henderson a écrit : > On 2014-04-07, Christophe 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.
Re: PF rule for transparent siproxd ?
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.
Re: PF rule for transparent siproxd ?
On 2014-04-07, Christophe 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.
Re: PF rule for transparent siproxd ?
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
