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
Summary of Contents for NetDefendOS
Page 30: ...Figure 1 3 Packet Flow Schematic Part III Chapter 1 NetDefendOS Overview 30 ...
Page 32: ...Chapter 1 NetDefendOS Overview 32 ...
Page 144: ...Chapter 2 Management and Maintenance 144 ...
Page 284: ...Chapter 3 Fundamentals 284 ...
Page 392: ...Chapter 4 Routing 392 ...
Page 419: ... Host 2001 DB8 1 MAC 00 90 12 13 14 15 5 Click OK Chapter 5 DHCP Services 419 ...
Page 420: ...Chapter 5 DHCP Services 420 ...
Page 573: ...Chapter 6 Security Mechanisms 573 ...
Page 607: ...Chapter 7 Address Translation 607 ...
Page 666: ...Chapter 8 User Authentication 666 ...
Page 775: ...Chapter 9 VPN 775 ...
Page 819: ...Chapter 10 Traffic Management 819 ...
Page 842: ...Chapter 11 High Availability 842 ...
Page 866: ...Default Enabled Chapter 13 Advanced Settings 866 ...
Page 879: ...Chapter 13 Advanced Settings 879 ...