On 28 jul 2006, at 11.19, jeraklo wrote:
...
The network layout looks like following:
CLIENT (can have public IP or private IP)
| (private client IP assumes default gateway uses NAT)
|
|
INTERNET
|
|
NIC_0_FIREWALL_0 (public IP)
FIREWALL_0
NIC_1_FIREWALL_1 (public IP, subnet_A)
|
|
NIC_0 (public IP, subnet_A)
VPN_SERVER (OpenBSD)
NIC_1 (public IP, subnet_B)
|
|
NIC_0_FIREWALL_1 (public IP, subnet_B)
FIREWALL_1
NIC_1_FIREWALL_1 (public IP, subnet_C)
|
|
DESTINATION SUBNET (public IP network, subnet_C)
This looks like a rather archaic layout, dating from when firewalls
had just an "inside" and an "outside" interface. Fortunately those
days are long over and all modern firewalls support multiple interfaces.
This design has the drawback of all traffic needing to pass through
three nodes (a.k.a single points of failure) with all that entails,
plus some extra administration with two firewalls.
You probably want either
Internet --- Firewall --- 'destination subnet'
|
VPNServer
or (although this may fail for political reasons :):
Internet --- Firewall/VPNServer --- 'destination subnet'
It is not possible for VPN server to reside directly
into destination subnet (subnet_C) because of
administrative reasons, but if you give me a _very_
good reason to do so, maybe it could be arranged. The
scenario layout would then look like this (in this
case, note the lack of both the second firewall and
the second NIC on VPN server):
You do not want this, and not just for administrative reasons. :)
The most obvious arguments why are perhaps a VPN configuration bug
could make your 'destination subnet' more open than intended, and you
definitely have to trust the clients not to send bad traffic. The
firewall is completely blind here...
To set this up, it's recommended you be fairly familiar with how IP
routing works, then read some of the PF- and IPsec-related manual
pages (pf.conf, ipsecctl etc al) plus examples, and you should be set
to go.
/H
