Firewall variations fall broadly into two categories: "supported" and "unsupported". Unsupported configurations are presented (for those who have the necessary facility with linux to configure them without step-by-step instructions) because they do not require NAT and therefore may be useful in certain situations.
Unsupported means that:
The Logical Firewall Variation e10 Rule Generator makes an extra 10.0.y.z network available for masquerading NAT behind the Logical Firewall. This is the only recommended way of using the Logical Firewall's NAT to provide connectivity to clients for which public IP addresses are unavailable. (Using 10.95.y.z and 128.95.y.z for different hosts is discouraged).
Clients on the extra 10.0 network can communicate freely (without NAT) with clients on your primary 10. network (they're all behind the firewall) unless you select "isolate e10 clients" in the rule generator. Connections to a host outside the firewall or through an ipsec tunnel will appear (on the remote end) to have originated on the firewall itself.
There is no need (or opportunity) to inform the rule generator about specific clients on the extra 10.0 network and, unlike your primary 10. network where every 10. address is paired with a public address, on the 10.0 network, you are free to (obliged to) assign them yourself.
At UW, firewall administrators can register their firewalls with the NOC to help prevent them from being disconnected if one of their clients misbehaves. However masquerading NAT clients which misbehave still put a firewall at increased risk of disconnection by the NOC (because the offending traffic appears to originate with the firewall's IP and MAC address). Therefore, to help mitigate this risk, masquerading NAT traffic can (optionally) be assigned to a second (sacrificial) NIC with a second IP and MAC address (if your firewall PC has two NICs). Although this is now a 2-NIC firewall, it is still connected as a logical firewall (not a physical firewall) with both NICs connected to different ports on the same upstream switch and both having public IP addresses. Think of it as two separate logical firewalls in one: a normal LFW with only non-masquerading (1:1) NAT clients and a second variation #ch10 firewall with only masquerading NAT clients. If a masquerading NAT client misbehaves badly enough that the NOC needs to disconnect it, the second (sacrificial) NIC will likely be disconnected leaving the main NIC and the non-masquerading NAT clients connected (note this also requires uw-setup version 1.71 or newer). See also Configuring a DHCP Server.
You do not need to do this to have multiple Logical Firewalls on the same subnet. The main reason to do this is to prevent the clients of two Logical Firewalls on the same physical network from being able to communicate with each other directly on the same default 10. network.
There is currently no explicit rule-generator variation to do this, however you can make a one line change to a copy of "gui-paste" to achieve the same result. (It will make a global substitution in the rule generator output as you do the gui-paste).
Here are the detailed steps you'd need to take:
10.0."
(in this example it is "10.0.123".
cp -p /usr/local/bin/gui-paste /usr/local/bin/my-gui-paste ln -s /usr/local/bin/my-gui-paste /usr/local/sbin/gui-paste hash -r echo local/bin/my-gui-paste >> /usr/local/bin/uw-restore.local echo local/sbin/gui-paste >> /usr/local/bin/uw-restore.local
This will make a copy of "gui-paste" in
"my-gui-paste" and add "my-gui-paste" to the list of
local files which will be carried forward by "uw-restore" when you
do an upgrade of the firewall. A link is also created so that if
you type "gui-paste" by mistake, you will still get "my-gui-paste".
{gsub(/10\.95\.123\./, "10.0.123.")} # change primary 10 net
Be sure to change all three
numbers before the comma to match your default 10. network.
The example above would change network "10.95.123" to
network "10.0.123".
TWO_NIC_FIREWALL=1 and
ALTER_INTERFACES=1 in the "tables" file
(on your firewall). If you did this, you could also
run your own DHCP server
behind the firewall and serve DHCP clients, although if
you can physically divide your network this way, you may also prefer a
different firewall or unsupported
variation #4 or variation 1a.
Similarly, if your subnet already has (or you
setup) a DHCP server
which can be safely configured to serve 10.x.y.z addresses, you can
use the logical firewall in the default (single-NIC) mode for DHCP
clients.
Because there can be only 64 tiny (2-bit) subnets in a /24 network, this variation can support no more than 64 clients per /24 subnet (but the similar Variation #nm29 below can support up to 160).
The Logical Firewall Variation #nm30
Rule Generator will generate rules which prevent all traffic
between clients (except for ICMP). To allow some inter-client traffic,
firewall rules can be added manually. (For
example, to allow TCP port 22 between all LFW clients, you'd add
(as per instructions at the link above):
iptables $FWD -p tcp --dport 22 $SYN -d $I_NET $MI -j $ACCEPT
To simplify the task of figuring out clients' netmask, gateway and broadcast addresses; please consult the purple-colored information at the end of the rule generator output which specifies which values to use for each client.
This variation yields a physical firewall, not a logical firewall, (meaning it has two network interface cards (NICs) and is inserted physically *between* the router and the protected hosts). It differs from traditional firewall approaches in that it does not require different subnet address allocations for each side of the firewall and no configuration changes are required on the protected clients (except rewiring them to be physically behind the firewall). This configuration requires the linux kernel "bridge-nf" patch (which first appears in Gibraltar release 0.99.6a).
To use this variation you must use two network interface cards (NICs), as would be true for any conventional physical firewall. Both NICs will share the firewall's single IP address, which should be on the subnet you're firewalling. Since this firewall is a bridge, it will (must) be transparent to ARP and other broadcast traffic to function. Since the linux host can also route, it can also be a PPTP (VPN) server (see VPN Configuration 1 and VPN Configuration 2).
The Filtering Bridge Variation 4: Rule Generator can be used to generate an in-line NAT-free physical firewall with essentially the same ease and procedure as a logical firewall (no manual editing is required). No changes are required to clients (except they must be rewired to connect to the second/internal interface of the firewall). However, no claim is made that you should choose this configuration over one of the many other filtering bridge firewalls for any reason other than leveraging your familiarity with Gibraltar and the Logical Firewall Rule Generator.
For comparison with a variation #1a firewall, a variation #4 firewall:
Here is some clarification about broadcasts with respect to bridging and filtering (as far as I can tell by experimentation):
Note: Beginning with release 0.99.6a, Gibraltar has the "bridge-nf" patch required to function as a true filtering bridge. Therefore, before choosing variation #1 or #1a, be sure to consider variation #4.
This configuration yields a physical firewall, not a logical firewall, (meaning it has two network interface cards (NICs) and is inserted physically *between* the router and the protected hosts). It differs from traditional firewall approaches in that it does not require different subnet address allocations for each side of the firewall. Instead, this configuration allows the subnet address range associated with the router port to be shared by the protected hosts "downstream" of the firewall. This is done by partitioning the original subnet range into sub-ranges.
To use this variation you must use two network interface cards (NICs), as would be true for any conventional physical firewall. Each NIC must have its own IP address.
In linux, firewall rules are applied as packets are forwarded between network interfaces. Unless filtering bridge patches are applied to linux, this forwarding only happens when routing between two different networks.
Let's assume you're on a /24 network (meaning the first 24 bits of the IP address are the network and your netmask is 255.255.255.0). If you intentionally "misconfigure" your firewall's two interfaces so that one interface is on each of the two /25 networks your /24 contains, it will be willing to route between them.
Though it isn't strictly necessary, your firewall rules will be much simpler if you choose the /25 containing your subnet's router (probably the lower /25 for most UW subnets) as the "outside" of your firewall. This means, all your firewall's clients must have addresses on the upper /25 (x.y.z.129-254) and all other hosts must be on the lower /25 (x.y.z.1-126).
If the partitioning above is met and clients are physically connected to the second NIC (eth1), changes to the firewall rules generated by the logical firewall rule generator are minimal (just comment out any NAT rules, set proxy_arp to 1 (at the end where it is set to 0), change the values of O_NET, O_BCA, I_NET, I_BCA) and add a suitable interface definition for eth1 in /etc/network/interfaces. (Remember that gui-paste won't preserve manual changes to the interfaces file.)
In practice, however, you'll probably be unable to partition your subnet in half but you can use any one or more /26, /27, /28, /29, /30, /31 nets as the "inside" of your firewall if you make the necessary adjustments to the firewall's routing tables and firewall rules. Still, variation #1a, below, is probably a more practical approach.
Since more specific routes (with larger netmasks) have precedence over less specific routes, it is also possible to leave the default route and "outside" interface (eth0) unchanged (at /24) and just add "host routes" (/32s) via the second interface (eth1) for each firewall client. This will get you pretty close to a conventional "filtering bridge firewall" where any client on the subnet can be moved behind the firewall without being changed in any way. The main difference between this configuration and a conventional filtering bridge is that host routes are used on the firewall for each firewall client.
Note that if you open a TCP connection to a machine, then quickly rewire it to be behind a variation 1a firewall which permits that TCP connection, and then run the "tables" command; the existing TCP connection will survive the transplant and now go through the firewall (although it may stall for a minute or so until arp-cache entries and TCP-retry-timers time-out).
The Almost Filtering Bridge Variation 1a: Rule Generator can be used to generate an in-line NAT-free physical firewall with essentially the same ease and procedure as a logical firewall (no manual editing is required). No changes are required to clients (except they must be rewired to connect to the second/internal interface of the firewall). However, no claim is made that you should choose this configuration over one of the many other filtering bridge firewalls for any reason other than leveraging your familiarity with Gibraltar and the Logical Firewall Rule Generator.
For comparison with a variation #4 firewall, a variation #1a firewall:
This configuration is a refinement of variations #1 and #1a above so be sure to read those first.
In the supported logical firewall configuration, clients are isolated from
the rest of the network because they have 10.x.y.z addresses.
In this very
unconventional (and unsupported) configuration, they are isolated by disabling
their use of ARP. This means, each firewall client must have a statically
configured ARP entry for the firewall and likewise the firewall must have a
statically configured ARP entry for each of its clients. The firewall is
instructed to "proxy ARP" for each of its clients (and only for its
clients--you must NOT enable
/proc/sys/net/ipv4/conf/all/proxy_arp as above unless you want to disrupt
everyone on the subnet!). Instead, on the firewall, for each client
ip address a.b.c.d, run:
"ip neighbor add proxy a.b.c.d net eth0"
Because linux won't send a "proxy ARP" (reply) for an address on the same interface which received the request, you must use two physical NICs (with two IP addresses) just like in variation #1 above. The difference is, that in this configuration, you will connect them both to the same place (switch).
In addition to disabling ARP on firewall clients, you must modify their routing tables by deleting the customary subnet route, adding a host route to the firewall, and making sure the firewall is their default route. This prevents them from trying to bypass the firewall for other hosts on the subnet (not that they could succeed with ARP disabled).
Note that in this configuration, unlike all other configurations, even traffic between two clients behind the firewall passes through the firewall. (Although you could, if you didn't mind the complexity, add more static ARP entries and host routes to allow specific clients to communicate directly).
In this variation, you assign your client (perhaps a Windows NT/98/2K/XP PC) a private (unroutable) 10. address (as usual) and your client establishes a VPN connection to the LFW's 10. address using PPTP. The PPTP daemon on the firewall issues your client its public/routable IP address (which your client uses by encapsulating traffic involving that address in PPTP packets sent and received using its private 10. address to and from the LFW). This configuration requires the use of firewall rule generator 2.0 or higher and Gibraltar release 0.99.4 or higher.
In this variation, DO NOT inform the rule generator of the VPN clients (you don't want it to generate NAT rules or interfaces for them).
Note that having some clients use the VPN method and others use the the supported NAT method works just fine. Interoperation between them should be seamless.
The following files need editing to use PPTP on Gibraltar:
/etc/pptpd.conf,
/etc/ppp/pptpd-options and
/etc/ppp/chap-secrets.
The following lines in "/etc/pptpd.conf" are sufficient:
speed 115200 option /etc/ppp/pptpd-options localip 192.168.254.254 # Note: use harmless IPs below, the real IPs will come from chap-secrets remoteip 192.168.0.1-254
Place the following (suitably edited) lines in
"/etc/ppp/pptpd-options".
| Use the green text on the left with Gibraltar 0.99.8 and newer OR the red text on the right with older releases: |
# the name below must only match the "server" field in chap-secrets
name LFW
domain your_dept.washington.edu
auth
# Uncomment the 6 lines below to enable encryption, if desired.
#require-mschap #+chapms
#require-mschap-v2 #+chapms-v2
#require-mppe #mppe-40
#require-mppe-128 #mppe-128
#nomppe-stateful #mppe-stateless
#-mru
#
# Note: replace p.q.r.s below with the IP address of a DNS server
ms-dns p.q.r.s
# Note: replace a.b.c.d below with the IP address of your WINS server
ms-wins a.b.c.d
netmask 255.255.255.0
nodefaultroute
proxyarp
lock
The "chap-secrets" file, is used both to authenticate
clients (by name/password) and to deterministically assign IP addresses
to them.
Because Windows 98 (perhaps others) sometimes prepends
"YOUR_DOMAIN\\" to the front of the name, you may need to make two entries
(one with and one without your login domain).
For security, by default, the firewall should only accept PPTP
connections from the local 10. subnet. (If you intend to use PPTP
remotely, you'll need to change that). Each client wishing to connect
via PPTP, must have a line in /etc/ppp/chap-secrets with
the following fields:
#name server password IP_address client1 LFW client1pw #.#.#.# DOMAIN\\client1 LFW client1pw #.#.#.# client2 LFW client2pw #.#.#.# DOMAIN\\client2 LFW client2pw #.#.#.#
Once these configuration changes are made, the PPTP daemon
on the firewall ("pptpd") must be started. For testing, it can
just be started manually from the command line (it requires no command-line
options). For use in production, you'll want to cause the daemon to start
automatically by uncommenting the "pptp" line in
"/etc/runlevel.conf".
You can get your VPN connection to start whenever you login to your windows system by putting a link to (drag and drop) the VPN connection into the startup folder.
On WinXP and Win2k, the only change to the defaults needed after setting up a VPN connection with the wizard is to disable "require data encryption" (if you choose not to enable encryption for efficiency reasons).
On Win98, the following "Microsoft VPN Adapter" properties should work:
General:
VPN Server: 10.x.y.z (the private address of your logical firewall)
Connect Using "Microsoft VPN Adapter"
Server Types:
Advanced options:
+ Log on to network
+ enable software compression
+ require encrypted password
- require data encryption
- record a log file for this connection
Allowed network protocols:
- NetBEUI
- IPX/SPX Compatible
+ TCP/IP
TCP/IP Settings:
+ Server assigned IP address
- specify an IP address
+ Server assigned name server address
- specify name server addresses
+ Use IP header compression
+ Use default gateway on remote network
Variation #3 (above) can be used for Unix/Linux clients, however PPTP does not always come with Unix/Linux systems and installing it may require building a new kernel. Therefore, one might prefer to use a different VPN solution to achieve a similar result. VTUN would seem to be a good choice as it is efficient and should be easy to obtain/install on the client from the VTUN homepage. VTUN is already installed on Gibraltar.
In this variation, you assign your client (a Unix/Linux system) a private (unroutable) 10. address (as usual) and your client establishes a VPN connection to the LFW's 10. address using VTUN. The VTUN daemon on the firewall issues your client its public/routable IP address (which your client uses by encapsulating traffic involving that address in VTUN packets sent and received using its private 10. address to and from the LFW). This configuration requires the use of firewall rule generator 2.0 or higher and Gibraltar release 0.99.4 or higher.
In this variation, DO NOT inform the rule generator of the VPN clients (you don't want it to generate NAT rules or interfaces for them).
Note that having some clients use the VPN method and others use the the supported NAT method works just fine. Interoperation between them should be seamless.
On the firewall, create "/etc/vtund.conf" with the following
contents, replacing A.B.C.D with the public/routable
address of the client:
options {
port 5000; # Listen on this port.
syslog daemon; # Syslog facility.
ppp /usr/sbin/pppd; # Path to the PPP daemon
}
client1 {
pass client1pw; # must be same as in client vtund.conf
type tty; # tty tunnel
speed 0; # maximum speed
proto tcp; # TCP protocol
comp no; # no compression
encr no; # no encryption
keepalive yes; # Keep connection alive
up {
ppp "192.168.254.254:A.B.C.D proxyarp noauth";
};
down {
};
}
On the client, create "/etc/vtund.conf" with the following
contents, replacing 10.L.F.W with the 10. address
of the firewall:
options {
port 5000; # Connect to this port.
timeout 60; # General timeout
ppp /usr/sbin/pppd; # Path to the PPP daemon
route /sbin/route; # Path to route
}
client1 {
pass client1pw; # must be same as in firewall vtund.conf
persist yes; # Persist mode
up {
program "echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_filter"; # for linux
ppp "noauth";
route "add default gw 192.168.254.254";
route "del default eth0";
};
down {
route "add default gw 10.L.F.W eth0";
route "del default gw 192.168.254.254";
};
}
If the firewall rules which "protect the firewall itself" don't accept connections on port 5000, create a line similar to the one for port 1723 (pptp) to accept them. Then start "vtund" by running:
vtund -s # on the firewall vtund client1 10.L.F.W # on the clientVtund is stopped by running "killall vtund". To cause "vtund" to start when the firewall boots, uncomment its entry in "/etc/runlevel.conf".
The Logical Firewall Variation 172 Rule Generator allows the Logical Firewall to double as a departmental "Project 172" NAT gateway (temporarily--if/until C&C provides a central alternative). 172 hosts are considered "outside" the LFW. The LFW does not offer them any protection, just NAT off campus.
To use this NAT gateway, clients would need to set their default route to the 172 address of the Logical Firewall.
The Logical Firewall Variation 172 and e10 Rule Generator enables both variations 172 and e10 simultaneously.
For your conveineice, if you already have a logical firewall, you can upload its "tables" file into the variation webforms above and you'll only need to manually enter information in the new fields on the opening screen.
Corey Satten
Email -- corey @ u.washington.edu
Web -- http://staff.washington.edu/corey/
Date --
Mon Jan 28 12:27:55 PST 2008