EasyManua.ls Logo

D-Link NetDefendOS

D-Link NetDefendOS
912 pages
To Next Page IconTo Next Page
To Next Page IconTo Next Page
To Previous Page IconTo Previous Page
To Previous Page IconTo Previous Page
Loading...
Also note how the IPv4 addresses of the internal interfaces of the virtual systems differ. If
per-interface routing table membership were not used, the core routes for both IP addresses
would be added in both routing tables, leading to 192.168.0.1 being unusable in vs2 (even
though it should be usable) and 192.168.0.254 being unusable in vs1. With per-interface routing
table membership, interface IP addresses belonging to one virtual system will not interfere with
other virtual systems and loopback interfaces are not needed.
The IPv4 addresses of the main-vs1 and main-vs2 interfaces are the same as the IP address of the
external interface. They could also have been set to something nonsensical, such as 127.0.0.1.
Regular routing would still have worked since loopback interfaces are raw IP interfaces (the ARP
protocol is not used over them). However, their IP addresses will be visible to users doing a
traceroute from the inside, and also the issue exists of traffic originating from the NetDefend
Firewall itself to the internal networks, such as pings or logging. Such traffic is most often routed
according to the main routing table, and will be sourced from the IP address of the nearest
interface in the main routing table.
4.5.4. IP Rule Sets with Virtual Routing
The IP rule sets for different virtual systems can be split into separate rule sets using the
NetDefendOS feature of creating multiple IP rule sets (see Section 3.6.4, “Multiple IP Rule Sets” for
more detail on this feature).
IP rules and IP policies for different virtual systems need not be split up. They can reside together
in a single IP rule set. The benefit of doing this is being able to define "shared" or "global" rules or
policies that span over several virtual systems. For example, for aggressive "worm" attacks, it may
be desirable to drop all communication on ports known to be used by the worm until
counter-measures can be put into place. One single Drop rule or policy placed at the top of the
rule set can take care of this for all the virtual systems. Using the example of the previous section,
this is how the IP rule set might look if IP rules are used:
Interface Groups
# Name Interfaces
1 main-vsifs main-vs1, main-vs2
2 main-ifs main-wan, main-vsifs
3 vs1-ifs vs1-main, vs1-lan
4 vs2-ifs vs2-main, vs2-lan
IP Rules
# Name Action Source If Source Net Dest If Dest Net Service
IP Rules for the "main" virtual system
1 main-allowall Allow main-ifs all-nets Any all-nets all_services
IP Rules for the "vs1" virtual system
2 vs1-http-in SAT vs1-ifs all-nets pubip-vs1 all-nets http SetDest
192.168.0.5
3 vs1-http-in Allow vs1-main all-nets Any pubip-vs1 http
4 vs1-out NAT vs1-int all-nets Any all-nets all_services
IP Rules for the "vs2" virtual system
5 vs2-smtp-in SAT vs2-main all-nets Any pubip-vs2 all_services
6 vs2-smtp-in Allow vs2-main all-nets Any pubip-vs2 smtp
7 vs2-http-out NAT vs2-int 192.168.0.4 vs2-main all-nets http
Chapter 4: Routing
328

Table of Contents

Related product manuals