can't do suitable block in firewall
Hi everyone. I'm trying to get some control of the MSN protocol in my network. My OpenBSD firewall has 4 interfaces: 2 lan, 1 wan and 1 dmz. What i'm trying to do is: 1. Allow some hosts to use MSN; 2. Redirect the MSN connections of some hosts from the LAN interfaces to a MSN proxy in the DMZ interface; 3. Block the rest. This is how i'm trying to achieve: # msn proxy redirect rdr on $lan1_iface proto tcp from $msn-redirect to any port 1863 -> $proxy rdr on $lan1_iface proto tcp from $msn-redirect to any port 25000:3 -> $proxy # msn filter pass out quick on $inet_iface inet proto tcp from $msn-redirect to $proxy port 1863 keep state pass out quick on $inet_iface inet proto tcp from $msn-allowed1 to any port 1863 keep state pass out quick on $inet_iface inet proto tcp from $msn-allowed2 to any port 1863 keep state pass out quick on $inet_iface inet proto tcp from $proxy to any port 1863 keep state block out on $inet_iface inet proto tcp from any to any port 1863 All hosts but the $proxy are in the $lan1_iface, the $proxy host is in the DMZ. I'm doing NAT in the $inet_iface (wan interface). The thing is that this is not working. Any host can connect to the MSN. If I switch "block out on" for "block out quick on", then no one, even the allowed ones, can connect. What i'm doing wrong? Tks in advance, and sorry for my poor english. --
Re: can't do suitable block in firewall
On 04/19/2010 08:43 PM, Leonardo Carneiro - Veltrac wrote: Hi everyone. I'm trying to get some control of the MSN protocol in my network. Upgrade to XMPP (jabber). http://xmpp.org/about/ If you need client software, pidgin is one option available in ports http://www.openbsd.org/4.6_packages/i386/pidgin-2.5.7.tgz-long.html /Lars
Re: can't do suitable block in firewall
Hi Lars and others. I already have a XMPP server on my network, and it replaces MSN in almost every task, but the gateway features does not work 100% yet (at least in the server that i use). For this, i still need MSN for some tasks, which is the point of the rules i'm trying to setup. Tks again Lars Nooden wrote: On 04/19/2010 08:43 PM, Leonardo Carneiro - Veltrac wrote: Hi everyone. I'm trying to get some control of the MSN protocol in my network. Upgrade to XMPP (jabber). http://xmpp.org/about/ If you need client software, pidgin is one option available in ports http://www.openbsd.org/4.6_packages/i386/pidgin-2.5.7.tgz-long.html /Lars
Re: can't do suitable block in firewall
On 04/19/2010 09:12 PM, Leonardo Carneiro - Veltrac wrote: ... I already have a XMPP server on my network, and it replaces MSN in almost every task, but the gateway features does not work 100% yet (at least in the server that i use)... Which features and which server? /Lars
Re: can't do suitable block in firewall
I use the Openfire xmpp server. But adding new contacts via a msn gateway is a real headache. I'm thinking about moving to ejabberd. Anyway, what i really need right now is to setup the selective redirect to the msn so some users go through the msn-proxy, some just go, and the rest just don't go :) Lars Nooden wrote: On 04/19/2010 09:12 PM, Leonardo Carneiro - Veltrac wrote: ... I already have a XMPP server on my network, and it replaces MSN in almost every task, but the gateway features does not work 100% yet (at least in the server that i use)... Which features and which server? /Lars
Re: can't do suitable block in firewall
Shane Lazarus wrote: Heya On Tue, Apr 20, 2010 at 5:43 AM, Leonardo Carneiro - Veltrac mailto:lscarne...@veltrac.com.br>> wrote: My OpenBSD firewall has 4 interfaces: 2 lan, 1 wan and 1 dmz. What i'm trying to do is: 1. Allow some hosts to use MSN; 2. Redirect the MSN connections of some hosts from the LAN interfaces to a MSN proxy in the DMZ interface; 3. Block the rest. This is how i'm trying to achieve: # msn proxy redirect rdr on $lan1_iface proto tcp from $msn-redirect to any port 1863 -> $proxy rdr on $lan1_iface proto tcp from $msn-redirect to any port 25000:3 -> $proxy # msn filter pass out quick on $inet_iface inet proto tcp from $msn-redirect to $proxy port 1863 keep state pass out quick on $inet_iface inet proto tcp from $msn-allowed1 to any port 1863 keep state pass out quick on $inet_iface inet proto tcp from $msn-allowed2 to any port 1863 keep state pass out quick on $inet_iface inet proto tcp from $proxy to any port 1863 keep state block out on $inet_iface inet proto tcp from any to any port 1863 Is the reference to passing out the redirected traffic to the $proxy via the $inet_interface instead of the $dmz_interface correct, a typo or the issue? Shane Hi Shane. No, it's not a typo. It's a last second modification that i tried before send the email. Was 'any' before i replace with '$proxy'. However, like you well observed, it's wrong :( I'll try other rules today and i'll post then here. Tks for you concern.
Re: can't do suitable block in firewall
Hi Shane, Heya and others. I tried a new setup, using tables (look more
eficient than using a thousan rules to each variable). But is still
failing :(
# tables
table persist const file "/etc/pf.conf.d/msn-rdr"
table persist const file "/etc/pf.conf.d/msn-allow"
# msn proxy
rdr on { $lan1_iface, $lan2_iface } proto tcp from to any
port 1863 -> $proxy
rdr on { $lan1_iface, $lan2_iface } proto tcp from to any
port 25000:3 -> $proxy
# msn filter
pass out quick on { $lan1_iface, $lan2_iface } inet proto tcp from
to $proxy port 1863
block out quick on ! $inet_iface inet proto tcp from !
to any port 1863
In the msn-rdr table are IP of the hosts that should be redirected to
the proxy, and in the msn-allow are the IP of the hosts that should be
allowed to connect directly with the MSN over the internet (including
the host $proxy). The $proxy host is in a fourth interface named $dmz_iface.
If i remove the "quick" statement of the block rule, anyone in any
interface can connect, and with the 'quick' statement, no one can =S.
Also, back in february, when i just redirected everyone to the proxy,
the rdr rules used to work, but with this more selective rule, it's not
working at all.
Tks in advance.
Leonardo Carneiro - Veltrac wrote:
> Shane Lazarus wrote:
>> Heya
>>
>> On Tue, Apr 20, 2010 at 5:43 AM, Leonardo Carneiro - Veltrac
>> mailto:lscarne...@veltrac.com.br>> wrote:
>>
>> My OpenBSD firewall has 4 interfaces: 2 lan, 1 wan and 1 dmz.
>> What i'm trying to do is:
>>
>>
>>
>>
>> 1. Allow some hosts to use MSN;
>> 2. Redirect the MSN connections of some hosts from the LAN
>> interfaces to a MSN proxy in the DMZ interface;
>> 3. Block the rest.
>>
>> This is how i'm trying to achieve:
>>
>># msn proxy redirect
>>rdr on $lan1_iface proto tcp from $msn-redirect to any port
>> 1863 ->
>>$proxy
>>rdr on $lan1_iface proto tcp from $msn-redirect to any port
>>25000:3 -> $proxy
>># msn filter
>>pass out quick on $inet_iface inet proto tcp from
>> $msn-redirect to
>>$proxy port 1863 keep state
>>pass out quick on $inet_iface inet proto tcp from
>> $msn-allowed1 to
>>any port 1863 keep state
>>pass out quick on $inet_iface inet proto tcp from
>> $msn-allowed2 to
>>any port 1863 keep state
>>pass out quick on $inet_iface inet proto tcp from $proxy to any
>> port
>>1863 keep state
>>block out on $inet_iface inet proto tcp from any to any port 1863
>>
>>
>> Is the reference to passing out the redirected traffic to the $proxy
>> via the $inet_interface instead of the $dmz_interface correct, a typo
>> or the issue?
>>
>> Shane
>>
>>
> Hi Shane. No, it's not a typo. It's a last second modification that i
> tried before send the email. Was 'any' before i replace with '$proxy'.
> However, like you well observed, it's wrong :(
>
> I'll try other rules today and i'll post then here. Tks for you concern.
Re: can't do suitable block in firewall
Leonardo Carneiro - Veltrac wrote:
> Hi Shane, Heya and others. I tried a new setup, using tables (look more
> eficient than using a thousan rules to each variable). But is still
> failing :(
>
> # tables
> table persist const file "/etc/pf.conf.d/msn-rdr"
> table persist const file "/etc/pf.conf.d/msn-allow"
>
> # msn proxy
> rdr on { $lan1_iface, $lan2_iface } proto tcp from to any
> port 1863 -> $proxy
> rdr on { $lan1_iface, $lan2_iface } proto tcp from to any
> port 25000:3 -> $proxy
>
> # msn filter
> pass out quick on { $lan1_iface, $lan2_iface } inet proto tcp from
> to $proxy port 1863
> block out quick on ! $inet_iface inet proto tcp from !
> to any port 1863
>
> In the msn-rdr table are IP of the hosts that should be redirected to
> the proxy, and in the msn-allow are the IP of the hosts that should be
> allowed to connect directly with the MSN over the internet (including
> the host $proxy). The $proxy host is in a fourth interface named $dmz_iface.
>
> If i remove the "quick" statement of the block rule, anyone in any
> interface can connect, and with the 'quick' statement, no one can =S.
> Also, back in february, when i just redirected everyone to the proxy,
> the rdr rules used to work, but with this more selective rule, it's not
> working at all.
>
> Tks in advance.
>
Hmm, i'm almost getting it. Switching
block *out* quick on ! $inet_iface inet proto tcp from ! to any
port 1863
to
block *in* quick on ! $inet_iface inet proto tcp from ! to any port
1863
solved the problem partially. Now, the allowed host are being allowed
and the others not, but the hosts that should be redirected are not
being redirected and also cannot connect.
Re: can't do suitable block in firewall
Leonardo Carneiro - Veltrac wrote:
> Leonardo Carneiro - Veltrac wrote:
>
>> Hi Shane, Heya and others. I tried a new setup, using tables (look more
>> eficient than using a thousan rules to each variable). But is still
>> failing :(
>>
>> # tables
>> table persist const file "/etc/pf.conf.d/msn-rdr"
>> table persist const file "/etc/pf.conf.d/msn-allow"
>>
>> # msn proxy
>> rdr on { $lan1_iface, $lan2_iface } proto tcp from to any
>> port 1863 -> $proxy
>> rdr on { $lan1_iface, $lan2_iface } proto tcp from to any
>> port 25000:3 -> $proxy
>>
>> # msn filter
>> pass out quick on { $lan1_iface, $lan2_iface } inet proto tcp from
>> to $proxy port 1863
>> block out quick on ! $inet_iface inet proto tcp from !
>> to any port 1863
>>
>> In the msn-rdr table are IP of the hosts that should be redirected to
>> the proxy, and in the msn-allow are the IP of the hosts that should be
>> allowed to connect directly with the MSN over the internet (including
>> the host $proxy). The $proxy host is in a fourth interface named $dmz_iface.
>>
>> If i remove the "quick" statement of the block rule, anyone in any
>> interface can connect, and with the 'quick' statement, no one can =S.
>> Also, back in february, when i just redirected everyone to the proxy,
>> the rdr rules used to work, but with this more selective rule, it's not
>> working at all.
>>
>> Tks in advance.
>>
>>
> Hmm, i'm almost getting it. Switching
>
> block *out* quick on ! $inet_iface inet proto tcp from ! to any
> port 1863
>
> to
>
> block *in* quick on ! $inet_iface inet proto tcp from ! to any
> port 1863
>
> solved the problem partially. Now, the allowed host are being allowed
> and the others not, but the hosts that should be redirected are not
> being redirected and also cannot connect.
>
I'm well aware that nat occurs before the filtering, but what about
redirections that does not involve nat?
Re: can't do suitable block in firewall
On 2010-04-20, Leonardo Carneiro - Veltrac wrote: >> > I'm well aware that nat occurs before the filtering, but what about > redirections that does not involve nat? translation = NAT = Network Address Translation = nat and rdr and binat rules. Since translation occurs before filtering, the filter engine will see packets as they look after any addresses and ports have been translated. Filter rules will therefore have to filter based on the translated ad- dress and port number. Packets that match a translation rule are only automatically passed if the pass modifier is given, otherwise they are still subject to block and pass rules. ... Evaluation order of the translation rules is dependent on the type of the translation rules and the direction of a packet. binat rules are always evaluated first. Then either the rdr rules are evaluated on an inbound packet or the nat rules on an outbound packet. Rules of the same type are evaluated in the same order in which they appear in the ruleset. The first matching rule decides what action is taken.
Re: can't do suitable block in firewall
On 04/19/2010 09:12 PM, Leonardo Carneiro - Veltrac wrote: ... the gateway features does not work 100% yet (at least in the server that i use) There are additional solutions. One is to work with the contacts to get them set up with XMPP clients, since the gateway function is there only to deal with legacy protocols as a means to phase them out through various means. Do you have a link to the bug report or discussion about the shortcomings of the gateway ? (e.g. Openfire, Kraken, or others) /Lars
Re: can't do suitable block in firewall
Stuart Henderson wrote: On 2010-04-20, Leonardo Carneiro - Veltrac wrote: I'm well aware that nat occurs before the filtering, but what about redirections that does not involve nat? translation = NAT = Network Address Translation = nat and rdr and binat rules. Since translation occurs before filtering, the filter engine will see packets as they look after any addresses and ports have been translated. Filter rules will therefore have to filter based on the translated ad- dress and port number. Packets that match a translation rule are only automatically passed if the pass modifier is given, otherwise they are still subject to block and pass rules. ... Evaluation order of the translation rules is dependent on the type of the translation rules and the direction of a packet. binat rules are always evaluated first. Then either the rdr rules are evaluated on an inbound packet or the nat rules on an outbound packet. Rules of the same type are evaluated in the same order in which they appear in the ruleset. The first matching rule decides what action is taken. Tks for the insight. I thought that when the documantation says nat, it only means the 'nat' rule. Tks in advance.
Re: can't do suitable block in firewall
Shane Lazarus wrote:
Heya
Seems to me that you should probably allow traffic out to the $proxy
via the $dmz_if at some point...
For that matter, allow from the $proxy back in through the $dmz_if and
out...
Something like:
# tables
table persist const file "/etc/pf.conf.d/msn-rdr"
table persist const file "/etc/pf.conf.d/msn-allow"
# msn proxy
rdr on { $lan1_if, $lan2_if } proto tcp from to any port {
1863 25000:3 } -> $proxy
# msn filter
block all
pass in on { $lan1_if $lan2_if } inet proto tcp from to
$proxy port { 1863 25000:3 }
pass out on { $dmz_if } inet proto tcp from to $proxy port {
1863 25000:3 }
pass in on { $lan1_if $lan2_if $dmz_if } inet proto tcp from
to any port { 1863 25000:3 }
pass out on { $inet_if } inet proto tcp from to any port {
1863 25000:3 }
Note that Hypens are not recommended for user defined names inside
pf.conf , being Macros, Table Names et al.
( man pf.conf for allowed characters )
So your table names and have been altered above
to conform to recommendations.
Also you have not mentioned any NAT rules here so these rules would
only work with Public IP Addresses throughout.
Lastly, try to group the rules together to get a better idea of packet
flow when building rules like these.
It was obvious to me from the first that you were missing rules, which
you would likely have been able to see yourself if you had grouped the
rules by expected packet flow.
For example:
Internal Network Redirects --> Proxy Server
Proxy Server --> Internet
Internal Network Direct --> Internet
Shane
Hi Shane and others. Tks for the tips. With it, i finally manage to get
working. I did not paste all my firewall script, that's why it didn't
have any NAT rule.
I only did a small change in your sugestion to get to work.
First, i switched the 'block all' to 'block in on ! $inet_iface inet
proto tcp from any to any port 1863' since i allow all traffic between
internal interfaces and all traffic going out through inet_iface by default.
I also changed the second pass rule; from 'pass out on { $dmz_if } inet
proto tcp from to $proxy port { 1863 25000:3 }' to 'pass
out on { $dmz_iface } inet proto tcp from $proxy to port {
1863 25000:3 }' (inverted the 'from' and 'to' statements).
I'll follow your tips regading the hypens stuff. Tks for your help.
Re: [ot] xmpp server (was 'can't do suitable block in firewall')
Lars Nooden wrote: On 04/19/2010 09:12 PM, Leonardo Carneiro - Veltrac wrote: ... the gateway features does not work 100% yet (at least in the server that i use) There are additional solutions. One is to work with the contacts to get them set up with XMPP clients, since the gateway function is there only to deal with legacy protocols as a means to phase them out through various means. Do you have a link to the bug report or discussion about the shortcomings of the gateway ? (e.g. Openfire, Kraken, or others) /Lars I can't force my clients (real clients, not host clients) to work with XMPP (they still use MSN), but there are thousand of solutions. I did not upgrade to kraken yet ( i'm still using the Gateway IM plugin ), but openfire development seems to have stopped. It's such a waste, cause it have the best management interface of all the xmpp servers that i have seen. I do not have a bug ticket, but i'm sure there is one open. The openfire brazilian users community is pretty active, and some users, like Marcelo Terres, keep in touch with some developers, and all point that the openfire development have stopped for real. =(
