D-Link NetDefendOS, User Manual

Page: 329 / 912

Note that SAT rules do not need to take into account that there are more organizations
connected to the same physical unit. There is no direct connection between them; everything
arrives through the same interface, connected to the
main routing table. If this was done without
virtual routing, the Allow rules would have to be preceded by NAT rules for traffic from other
organizations. Care would also have to be taken that such rules were in accordance with the
security policy of each organization. Such problems are eliminated with virtual routing.
The source interface filters are very specific. Any is not used as the source interface anywhere,
since such a rule would trigger regardless. Consider for instance what would happen if the
vs1-http-in rules were to use Any as source interface. They would trigger as soon as packets
destined to pubip-vs1 were received on main-ext . The destination address would be rewritten to
192.168.0.5 , and passed on using the main routing table. The main routing table would not know
what to do with 192.168.0.5 and pass it back out to the default gateway outside the NetDefend
Firewall.
If the same naming scheme as shown in this example is used, making sure the source interfaces
are correct can be done quickly. All the rules concerning the
main system have source interfaces
beginning with " main- ". All those concerning vs1 have source interfaces beginning with " vs1- ",
and so on.
The destination interface filters, however, do not need to be as specific as the source interface
filters. The possible destinations are limited by the routing tables used. If the
vs1 table only
includes routes through vs1- interfaces, Any filters can only mean "through other interfaces in the
same virtual system". It may however be sound practice to write tighter destination interface
filters in case an error occurs elsewhere in the configuration. In this example, rule 1 might use
main-ifs , rule 4 might use vs1-main . The SAT and corresponding Allow rules however are already
fairly tight in that they only concern one single destination IP address.
4.5.5. Multiple IP rule sets
An alternative approach to having all the IP rules for different virtual systems in one rule set is to
make use of
Multiple IP rule sets .
Although all scanning of IP rules begins in the main rule set, it is possible to define a rule in main
whose action is Goto so that scanning continues in a separate, named rule set. These extra rule
sets can be defined as needed and one rule set can be created for each virtual system and its
corresponding routing table.
More details on this subject can be found in Section 3.6.4, “Multiple IP Rule Sets” .
4.5.6. Trouble Shooting
When setting up virtual routing, the following steps can help with troubleshooting any
problems.
• Make sure that the source interface filters are correct
• Double check interface PBR table membership, for all types of interfaces and tunnels.
• Use "ping -p <pbrtable>" to source pings from different virtual systems.
• Use "ping -r <recvif> -s <srcip>" to test the rule set, simulating that the ping was received on
a given interface from a given IP address.
• Use "arpsnoop -v <ifacenames>" to get verbose information about ARP resolution.
• Use "route <pbrtable> -all" to view all route entries in a given table, including "core" routes.
• Use "route -lookup <ipaddr> <pbrtable>" to make sure that a given IP address is routed the
Chapter 4: Routing
329