abc987
New Contributor II

iprope

Can anybody explain what this ' iprope' means? ' iprope_in_check() check failed, drop' ' get firewall iprope list'

FCNSP/WCSP

1 Solution
darwin_FTNT

Iprope -> Group of firewall policies installed into the kernel parsed from cmdb configuration: 'config firewall policy' is mapped to iprope policy group ENC_FWD (0x100004)

'config firewall local-in-policy' is mapped to iprope policy group IN (0x100001)

These iprope group can be listed by: 'diag firewall iprope list'

Each of these policy groups is installed at different nodes of the netfilter chain. The netfilter chain has the following nodes:

NF_INET_PRE_ROUTING, NF_INET_LOCAL_IN, NF_INET_FORWARD, NF_INET_LOCAL_OUT, NF_INET_POST_ROUTING,

NF_INET_AF_ORIGIN, NF_INET_AF_SINK,

The netfilter chain works as the following example cases:

1. A packet arrived at the interface card and the driver copies the incoming data into skb.    The skb is processed and eventually reached the netfilter chain node pre-routing.    The skb is lookup into the routing table to decide whether it is for local host or forward to another external hosts(based on IP address).    If it is destined for local host, the node local in is triggered and iprope in group is processed.    If it is destined for forwarding, the node forward is triggered and iprope forward group is processed.    Then it reached the post routing node, where the interface card output function is hooked.    Then the skb is passed on to the link layer and to another external router. 2. If a local process writes data to a socket using write() system call, the layer 7 application data     transition into kernel space.     Then the system call function transfer the data to transport layer function, e.g., tcp function.     Then the tcp function passed the skb to the network layer, the IP function, which is hooked into     netfilter chain local out node.  It will be processed and proceed to the next post routing node.

 3. There are many functions hooked into the netfilter chain, e.g., firewall rules, interrupt handler input/output,

     virtual devices like ipsec, sslvpn, nat64/46, etc. Basically the netfilter chain is like a virtual bus where the individual packet is processed as struct skb data.

For the function iprope_in_check(), it is hooked into local in node.

Inside the function are called 4 ordered groups of iprope (ttl, local, implicit, admin):

ttl -> config firewall ttl policy matching

local -> config firewall local-in-policy

implicit -> hard-coded ports/services like HA, routing, etc.

admin -> seems like ssh, telnet, http services dynamically added based on config

The local-in policy group is triggered before implicit and admin and thus can override them.

 

For the implicit-in group, it could be moved into external cmdb config instead hard-coded into source code.

But this would cause service interruption if configured incorrectly.

Also this would make it easier to configure which ports to be accessible.

 

View solution in original post

5 REPLIES 5
JMGIII
New Contributor

If I am not mistaken that log message means the system could not find the reverse/return route, so it dropped the packet.
abc987
New Contributor II

I understand about RPF check. My problem is to understand/translate this word ' iprope' . So I don' t understand the description of ' get firewall iprope list' in CLI Reference.

FCNSP/WCSP

darwin_FTNT

Iprope -> Group of firewall policies installed into the kernel parsed from cmdb configuration: 'config firewall policy' is mapped to iprope policy group ENC_FWD (0x100004)

'config firewall local-in-policy' is mapped to iprope policy group IN (0x100001)

These iprope group can be listed by: 'diag firewall iprope list'

Each of these policy groups is installed at different nodes of the netfilter chain. The netfilter chain has the following nodes:

NF_INET_PRE_ROUTING, NF_INET_LOCAL_IN, NF_INET_FORWARD, NF_INET_LOCAL_OUT, NF_INET_POST_ROUTING,

NF_INET_AF_ORIGIN, NF_INET_AF_SINK,

The netfilter chain works as the following example cases:

1. A packet arrived at the interface card and the driver copies the incoming data into skb.    The skb is processed and eventually reached the netfilter chain node pre-routing.    The skb is lookup into the routing table to decide whether it is for local host or forward to another external hosts(based on IP address).    If it is destined for local host, the node local in is triggered and iprope in group is processed.    If it is destined for forwarding, the node forward is triggered and iprope forward group is processed.    Then it reached the post routing node, where the interface card output function is hooked.    Then the skb is passed on to the link layer and to another external router. 2. If a local process writes data to a socket using write() system call, the layer 7 application data     transition into kernel space.     Then the system call function transfer the data to transport layer function, e.g., tcp function.     Then the tcp function passed the skb to the network layer, the IP function, which is hooked into     netfilter chain local out node.  It will be processed and proceed to the next post routing node.

 3. There are many functions hooked into the netfilter chain, e.g., firewall rules, interrupt handler input/output,

     virtual devices like ipsec, sslvpn, nat64/46, etc. Basically the netfilter chain is like a virtual bus where the individual packet is processed as struct skb data.

For the function iprope_in_check(), it is hooked into local in node.

Inside the function are called 4 ordered groups of iprope (ttl, local, implicit, admin):

ttl -> config firewall ttl policy matching

local -> config firewall local-in-policy

implicit -> hard-coded ports/services like HA, routing, etc.

admin -> seems like ssh, telnet, http services dynamically added based on config

The local-in policy group is triggered before implicit and admin and thus can override them.

 

For the implicit-in group, it could be moved into external cmdb config instead hard-coded into source code.

But this would cause service interruption if configured incorrectly.

Also this would make it easier to configure which ports to be accessible.

 

localhost

Thank you very much for sharing this. Very interesting.

 

lunhas2k4
New Contributor II

Thanks for the tip Mr. Darwin.

Carlitos loves firewalls

NSE4 (5.4,6.0)

NSE5 (Fortimanager 6.0, Fortianalyzer 6.0)

NSE7 (Enterprise Firewall 6.0)