Date: Thu, 11 Jan 2001 19:34:17 -0600 From: Gerd Knops <gerti@bitart.com> To: Eric Nilson <nilsone@yahoo.com> Cc: freebsd-questions@FreeBSD.ORG Subject: Re: Firewall/ Routing Message-ID: <20010112013417.16612.qmail@camelot.bitart.com> In-Reply-To: <20010111235959.5991.qmail@web10011.mail.yahoo.com> References: <20010111235959.5991.qmail@web10011.mail.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Eric Nilson wrote: > Dear Mailing list members: > > Here is an interesting problem that I have been trying > to figure out with very little success... > > I am attempting to set up a FreeBSD server as a > gateway/ firewall to two independent ISPs for a > 192.168.x.x internal network. Here is some of the > criteria: > > 1. Internal network will use ISP1 as primary route to > Internet > 2. in the event ISP1 fails, ISP2 will be used by > internal network > 3. In the event ISP1 revives, internal network will > use ISP1 again > 4. Servers on the internal network need to be able to > respond to traffic from both ISP1 and ISP2 > > > (sorry for the ASCII art) > > ISP1 ISP2 > \ / > \ / > \ / > \ / > Firewall/ FreeBSD > / \ > / \ > / \ > / \ > / \ > Workstations Servers > > Is this possible? If so, how? > > Thank you for your assistance! > Can you spell can of worms? Anyhow... There are a number of issues here, depending on what the main motivation is. Inbound traffic --------------- Let's assume the above includes DNS and name servers. What happens quite frequently is that at some place in the world routing is screwed up, and the folks affected by that can't reach your DNS/mail server through ISP1 anymore, but they can reach it via ISP2. The problem here is that your servers will send their answers back via the default route (eg ISP1), and due to the routing problem somewhere in the distance those answers don't reach their target. So what is needed for the above scenario is that requests coming in through ISP1 are answered via ISP1, and requests coming in via ISP2 are answered via ISP2. For this to work, your DNS/mail servers need to be either on or outside the firewall, so they can identify where the packets come from. Let us assume you have a machine set to IP A (via ISP1) and aliased to IP B (via ISP2), default route points to the gateway to ISP1. Thankfully services like named etc. bind their responses to the address the request came in from (A if the request came via ISP1, and B if the request came in via ISP2). We can now use ipfw to 'bend' packets that originate on address B to be directed to the gateway to ISP2, using a ruleset like this: add 1000 allow all from A to any add 1010 allow all from any to BN add 1020 allow all from any to AN add 1030 fwd BGW all from B to any A and B are the IP addresses (see above), AN and BN are the network addresses, and BGW is the IP address of the gateway to ISP2. The first rule is just a shortcut to speed up the bulk of the packets. The second and third rule let traffic in from either ISP1/2. The last rule is the one that does the trick: If the 'from' address is B, forward the packet to the gateway to ISP2. Now you can have primary and secondary DNS/mail server on seperate addresses and networks, but the same physical machine. Outbound traffic ---------------- I use ipf/ipnat for my internal 192.168 network. ipnat can use the 'magic' address '0.0.0.0/32' to mean 'pick up IP from interface'. So to switch from ISP1 to ISP2 I can use this script (fxp0 is my interface to the 'outside'): route delete default ifconfig fxp0 down ifconfig fxp0 inet B netmask yyyy ifconfig fxp0 inet A netmask xxxx alias route add default BGW BGW as above is the gateway to ISP2, xxx/yyy are the respective netmasks. And to switch back: route delete default ifconfig fxp0 down ifconfig fxp0 inet A netmask xxxx ifconfig fxp0 inet B netmask yyyy alias route add default AGW To add support for inbound traffic as discusse dabove I also need to add ipfw -f flush ipfw rules.ipfw.B and ipfw -f flush ipfw rules.ipfw.A where rules.ipfw.A/B are the ipfw rules as discussed above. To automate that, a smal perl script or such that routinely pings for instance the first backbone past your ISP1 could be used. When the ping stops responding, switch to ISP2. When the ping comes back, switch back to ISP1. Hope that helps! Gerd To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010112013417.16612.qmail>