beautypg.com

Ip rules with virtual routing, Interface groups, Ip rules – Amer Networks E5Web GUI User Manual

Page 293: Chapter 4: routing 293

background image

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 Clavister
Security Gateway 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 Rules with Virtual Routing

The IP rule sets for different virtual systems can be split into separate rule sets using the cOS Core
feature of creating multiple IP rule sets (see Section 3.6.4, “Multiple IP Rule Sets” for more detail on
this feature).

IP Rules for different virtual systems need not be split up. The rules can reside together in a single
IP rule set. The benefit of doing this is being able to define "shared" or "global" rules 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 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:

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

293

This manual is related to the following products: