[TriLUG] OT: Router then Firewall

Tue May 16 23:57:47 EDT 2006

jonc wrote:

>Excellent info! A gem of a script too.
>Certainly worthy of being repeated...
>
>===<from Jason's original email>===
>-----------------------------------------------------
>#!/bin/sh
>IF1=eth0
>IF2=eth1
>IP1=66.45.113.214 #IP address of eth0
>IP2=133.37.29.34 #IP address of eth1
>P1=66.45.113.213 #gateway for eth0
>P2=133.37.29.33 #gateway for eth1
>P1_NET=66.45.113.209 #network of eth0
>P2_NET=133.37.29.30 #networkof eth1
>
>ip route add $P1_NET dev $IF1 src $IP1 table T1
>          ip route add default via $P1 table T1
>          ip route add $P2_NET dev $IF2 src $IP2 table T2
>          ip route add default via $P2 table T2
>
>ip route add $P1_NET dev $IF1 src $IP1
>            ip route add $P2_NET dev $IF2 src $IP2
>
>ip route add default via $P2
>
>ip rule add from $IP1 table T1
>            ip rule add from $IP2 table T2
>--------------------------------------------------
>finally, add two routing table entires into /etc/iproute2/rt_tables:
>
>echo "200 T1">>/etc/iproute2/rt_tables
>echo "201 T2">>/etc/iproute2/rt_tables
>
>once this was done the web server worked flawlessly, serving up pages to 
>hosts regardless of whether they used the original IP address or the 
>new one.  this way it didn't matter how long DNS changes took to 
>propogate, both results worked equally well.
>
>  
>
Friendly public service announcement (I'm sure Jon knows, but I can't 
let a statement like the above go by with out responding).  Assuming you 
have some semblance of control over the DNS records themselves, you 
should lower the TTL before you change the IP (or name) associated with 
that record, and then raise the TTL again after the change has 
stabilized.  Let's consider a hypothetical scenario.  You run a web 
server, www.example.com.  You're going to change providers, and thus 
change the IP of the machine serving www.example.com.  The steps to 
follow go something like this:

1:  Examine the current record, determine how long the TTL is (we'll say 
it's 3 days, or 10800 seconds).
2:  At least one current-TTL-interval (3 days) before you intend to make 
the change, update the TTL for that record (and all other potentially 
affected records) to be very low, for example 5 mins (900 seconds).
3:  Test the new setup on the new IP, then 'throw the switch' by 
changing the DNS record.
4:  Establish that everything is working as expected, perhaps wait 1 day 
to be sure.
5:  Make a final DNS update to return the TTL to it's previous long / 
stable value.

This way, your DNS updates can normally have nice long cache times, 
making your bandwidth bill lower, your user's latency lower, still 
giving you the ability to have quick change over of service, and making 
the Internet a healthier place.  This makes everyone happy.  :)

As an exercise for the reader, how would you handle migrating your DNS 
server(s) from one IP address (or one subnet) to another, using similar 
techniques?  Do you need to talk to someone outside your organization, 
or can you do it all in-house?  Are you sure of your answer to that last 
question?  How would you find out for sure...  :)  A Google T-shirt(*) 
to the person who comes up with the best / most complete answer(+).

Aaron S. Joyner

* - Size of your choice, in white or black:
http://www.googlestore.com/product.asp?catid=5&code=GO0108
http://www.googlestore.com/product.asp?catid=5&code=GO13022

+ - Final decision about answer quality is at my sole discretion, 
although I promise to be as fair as possible.  Credit for information 
posted will come on a first-come, first-serve basis - ie. if someone 
posts a 90% complete answer, and you rephrase their answer plus 10% 
more, unless that 10% is really critical they'll probably be considered 
to have the better answer.  Hence, posting sooner is better, but I'll 
probably wait either until every angle has been exhausted or at most 5 
days.  Time differences of less than roughly 2-3 mins in time sent are 
not considered note-worthy.

>======
>
>On Mon, 2006-05-15 at 16:25, Jason Tower wrote:
>  
>
>>you should be able to do this with either linux or openbsd, this might 
>>point you in the right direction:
>>
>>http://www.trilug.org/pipermail/trilug/Week-of-Mon-20031027/021269.html
>>
>>not 100% identical to what you want to do but kinda sort of vaguely similar.
>>
>>jason
>>
>>Steve Hoffman wrote:
>>    
>>
>>>Can anyone suggest a decent router, that can also be used as a firewall 
>>>with
>>>NAT?  I was able to set a cisco 2500 series router to route between two
>>>incoming connections by using route-maps.  I've recently purchased a Cisco
>>>ASA 5510 to add a little more protection and was assured at the time of
>>>purchase it could do what I needed..well, now I see that it can not.  If I
>>>have to purchase a second one I will, but I'd rather have a good router 
>>>that
>>>can route between more then one inbound provider and restrict access to our
>>>public interfaces.
>>>
>>>Here's what I want...
>>>
>>>All addresses are private IP's on the internal network (10.0.0.0/24)
>>>
>>>A total of two incoming internet connections with three separate IP ranges
>>>(2 /29's and 1 /28)
>>>
>>>I'd prefer that all traffic go out via one default ip address UNLESS a NAT
>>>rule is setup to translate to one of the 24 available IP addresses, at 
>>>which
>>>point the packet should go to the default gateway for that network....
>>>
>>>I can't imagine I'm the first person to want this, but I guess I'm the 
>>>first
>>>to want to do it with an ASA?  On the surface the ASA can do everything
>>>EXCEPT specify the next hop for an external internet connection.  It only
>>>allows for one default route and doesn't allow for a "set default next-hop
>>>xxx.xxx.xxx.xxx" as a router does...which shoots my whole plan to shit.
>>>I've considered using RIP or OSPF, but unfortunately one of our internet
>>>connections is a RR business class (hey..it's got great download speed)
>>>connection that I can't alter the routing info so that's out.
>>>
>>>As always, your words of wisdom are welcome.
>>>
>>>Thanks,
>>>Steve
>>>      
>>>
>
>  
>