[Firehol-support] How can I target all of the 10.67. network EXCEPT my LAN on 10.67.5.?

Tsaousis, Costa costa at tsaousis.gr
Wed Feb 25 19:34:39 GMT 2015


and... it is always a good practice to put 'dst' in interfaces, but
keep in mind that you might also need to add the network broadcast
address, and in case of multicast, the ${MULTICAST_IPS} variable too.



On Wed, Feb 25, 2015 at 9:28 PM, Tsaousis, Costa <costa at tsaousis.gr> wrote:
> I forgot to mention that you can actually make some packets continue
> from interface to interface with policy return.
>
> For example,
>
> interface4 eth1 my_lan src "10.67.5.0/24 " dst 10.67.5.1
>    policy return
>
>    server ssh accept
>
>
> interface4 eth1 tslan src "10.67.0.0/16" dst 10.67.5.1
>    policy reject
>
>    server smtp accept
>
> The above means that "10.67.5.0/24" will be able to use both ssh and
> smtp, while all other IPs in 10.67.0.0/16 will only use smtp.
>
> Remember:
>
> - default policy for interfaces is drop
> - default policy for router is return
>
>
>
> On Wed, Feb 25, 2015 at 9:22 PM, Tsaousis, Costa <costa at tsaousis.gr> wrote:
>> Hi Rich,
>>
>> The flow the packets travel is from top to bottom.
>> If something is matched, is stopped there.
>>
>> So, this
>>
>> interface4 eth1 my_lan src "10.67.5.0/24 " dst 10.67.5.1
>> ...
>>
>> interface4 eth1 tslan src "10.67.0.0/16" dst 10.67.5.1
>> ...
>>
>> means that 10.67.5.0/24 will be stopped at my_lan.
>>
>> In FireHOL, you cannot write both positive and negative expressions of
>> the same parameter.
>> There are a few ways to overcome this:
>>
>> First is the flow. Match the more specific thing first.
>> Then you can have groups, like this:
>>
>> interface4 eth1 tslan src "10.67.0.0/16" dst 10.67.5.1
>>
>>    group with src "10.67.5.0/24 "
>>       server all accept
>>       client all accept
>>    group end
>>
>>    ... servers/clients for all other IPs in 10.67.0.0/16 ...
>>
>> Groups can be nested. You can have groups within groups within groups, etc.
>> The flow though, is always important. It also optimizes the firewall.
>> Always try putting the most frequent services, the ones with the most
>> traffic, near the top. This saves some CPU cycles on your machine.
>>
>> So the first warnings you get are there to let you know that you
>> actually overwrote the first 'src' parameter with the second 'src'
>> parameter.
>>
>> Regarding the last warning, it is not something to worry if you don't
>> need it. Something is missing from your kernel probably (conntrack
>> helpers for ftp, tftp, sip, pptp, etc).
>> Which distribution and kernel version are you using? Have you compiled
>> the kernel yourself or is a distribution supplied one?
>>
>> Costa
>>
>>
>>
>> On Wed, Feb 25, 2015 at 5:06 PM, Rich <forums at artfulrobot.uk> wrote:
>>>
>>>
>>> Hi
>>>
>>> (thanks to all who replied to my previous post - I've compiled v3rc from
>>> source on one of my Debian Wheezy boxes)
>>>
>>> I'm roughly trying to do this:
>>>
>>> interface4 eth1 my_lan src "10.67.5.0/24 " dst 10.67.5.1
>>>  policy accept
>>>
>>> interface4 eth1 tslan src "10.67.0.0/16" src not "10.67.5.0/24" dst
>>> 10.67.5.1
>>>  policy reject
>>>  server ssh accept
>>>
>>> interface4 eth1 interweb src not "${UNROUTABLE_IPS} 10.67.0.0/16 " dst
>>> 10.67.5.1
>>>  policy reject
>>>  server ssh accept
>>>  server openvpn accept
>>>
>>> In words: my server sits on a VLAN, 10.67.5.0/24 and provides a bunch of
>>> services to others on that VLAN. The server is not the gateway for the
>>> VLAN. There are other VLANs under 10.67.0.0/16 and I want to restrict
>>> access to the server from them. Then there's the rest of the internet,
>>> and I need to give it access to openvpn that runs on the server.
>>>
>>> WITH THIS SET UP I'M WARNED (TWICE, ONCE CREATING INPUT ONCE CREATING
>>> OUTPUT):
>>>
>>> WHY    : OVERWRITING PARAM: SRC4 '10.67.5.0/24' BECOMES '10.67.0.0/16'
>>>
>>> HOW CAN I TARGET ALL OF THE 10.67. NETWORK EXCEPT MY LAN ON 10.67.5.?
>>>
>>> I also get:
>>>
>>> --------------------------------------------------------------------------------
>>> WARNING : This might or might not affect the operation of your firewall.
>>> WHAT : A runtime command failed to execute (returned error 255).
>>> SOURCE : FIN
>>> COMMAND : /sbin/sysctl -w net.netfilter.nf_conntrack_helper=1
>>> OUTPUT :
>>>
>>> SYSCTL: CANNOT STAT /PROC/SYS/NET/NETFILTER/NF_CONNTRACK_HELPER: NO SUCH
>>> FILE OR DIRECTORY
>>>
>>> Any reason for that and do I need to worry?
>>>
>>> Thanks,
>>>
>>> Rich
>>>
>>> _______________________________________________
>>> Firehol-support mailing list
>>> Firehol-support at lists.firehol.org
>>> http://lists.firehol.org/mailman/listinfo/firehol-support



More information about the Firehol-support mailing list