Re: Setting up a box to do NAT and Static IPs
On Thu, Oct 12, 2006 at 01:06:12AM -0400, Martin Gignac wrote: On 10/11/06, Girish Venkatachalam [EMAIL PROTECTED] wrote: Yeah, I'm familiar with 3261. However the SIP proxy that 3261 talks about has a completely different function than what an ALG/SBC does. Maybe I shouldn't have used the term SIP proxy in my previous e-mails. My bad. -Martin No, it isn't your mistake Martin. I am overworked :-) and have not been following your threads. Moreover you are exceeding my level of understanding of the topic. :-) Sorry, hope you solve your problem soon. Wish you Godspeed! Back to work! regards, Girish
Re: Setting up a box to do NAT and Static IPs
On Wed, Oct 11, 2006 at 02:31:29PM -0400, Martin Gignac wrote: On 10/11/06, Jon Radel [EMAIL PROTECTED] wrote: If my memory serves me right, SIP actually has ALG built into the standard itself and www.opensip.org might already give you what you want. Hmm, wasn't aware of that. Do you have any specific RFC or 3GPP spec number that I could check out concerning this? -Martin The standard? But SIP has so many. I was asking because although I'm familiar with the usual SIP RFCs (3261 and family) I was not aware of the SIP actually has ALG built into the standard itself notion that Girish mentionned and I wanted to know if there was any actual documentation to support this. I am so sorry... Did not realize that I was rubbing shoulders with giants... Good lesson for me to STFU when reqd. :) But the core spec, RFC 3261, http://www.rfc-editor.org/rfc/rfc3261.txt , doesn't touch on the topic at all so far as I've ever noticed. Yeah, I've never heard of this in 3261 either. NAT fixup for SIP is a nasty thing and I've seen a number of broken implementations and incompatible solutions. As a hosted IP PBX provider, we've had the best luck using session border controllers at the edge of our network, which are configured to assume that phones are behind NAT. Yeah, we use SBCs in IMS as well. Unfortunately, SIP is nowhere near being a standard where you can assume interop just because you implement a bunch of RFCs. Especially if you mix NAT in. Add to that the 3GPP and OMA additions for IMS and it gets even wilder. -Martin Let me take a stab at guessing how things are going to turn out. I don't know when or if at all IPv6 is going to get deployed. Then NATs instead of disappearing as originally intended may actually get more widespread use. Horrors! I think ultimately some startup will come up with widely used VoIP solution and all NAT manufacturers will be forced to open up ports. It is the ports determination problem of FTP,RTP and other protocols that make operation across NATs so hard and unpredictable. If only ports were standardised better... Port negotiation should never be part of the protocol itself. But the world is not perfect and we have to live with it. regards, Girish
Re: Setting up a box to do NAT and Static IPs
On Thu, Oct 12, 2006 at 01:41:49AM +0100, Stuart Henderson wrote: On 2006/10/12 01:15, ropers wrote: Neither do I understand what really goes on during IP forwarding as opposed to bridging with forwarding(routing) tcp/ip packets have a destination IP address which isn't bound to an interface on the router but the MAC address _is_ the address of the routers (destination address is not ARP'd for because the previous router knows it's not a directly-connected destination). with bridging, the MAC address is of the final destination, and is learned by the previous router by ARPing for it (ethernet broadcasts cross the bridge unaltered). see tcpdump -e Stuart, I read and reread the previous paragraph but I am not able to understand it. Let me try to express my understanding. Please point out the holes in that( I am sure there are many). I am especially confused since you have mentioned forwarding(routing). Routing protocols have two phases or components called building the routing table and actual forwarding of IP packets. It is the building of routing tables that happen over TCP(BGP),UDP(RIP) or IP(OSPF). This happens independently or real packet forwarding which is the primary job of a router. Now, once an IP packet arrives thro' an interface of a router, its destination IP address is looked up in the routing table, its TTL value checked and decremented, its IP checksum recomputed since we modified the TTL, and then finally(and most importantly), the destination MAC address of the packet modified to match the longest prefix match of the routing table lookup. Thus, if you see actually it is the destination MAC address stored in the ethernet header that is actually modified at every hop of the router. The IP header is largely untouched. Am I making sense or talking rubbish? Now, briding is actually the job of a layer 2 device like a switch/hub and mostly happens in hardware since it is a dumb function. What OpenBSD hopes to achieve thro' providing briding in software is to do that same job intelligently. The man page clearly says that. If you add pf to briding then voila!, you have a marvellous way to filter packets transparently without actually modifying the routing topology of the network. And since pf can do much much more than mere filtering, the convenience of not modifying your routing topology is a marvellous gift to sysadmins... or, for that matter, why I needed to enable net.inet.ip.forwarding=1 in /etc/sysctl.conf for the bridge to work. I'm not sure you do, but I think you need it for PF. If it was a bit more sensible time of day I'd double-check (-: I guess this is more of a security measure. Since bridging involves lower layer handling, the user has to explicitly state his intent. I find no confusion here. You need to do the same if you are using IPsec as well. Best, Girish
Re: Setting up a box to do NAT and Static IPs
I'd like to thank everybody for their comments. I'm listening and learning. Keep those posts coming! :) --ropers
Re: Setting up a box to do NAT and Static IPs
On 2006/10/12 14:39, Girish Venkatachalam wrote: On Thu, Oct 12, 2006 at 01:41:49AM +0100, Stuart Henderson wrote: On 2006/10/12 01:15, ropers wrote: Neither do I understand what really goes on during IP forwarding as opposed to bridging with forwarding(routing) tcp/ip packets have a destination IP address which isn't bound to an interface on the router but the MAC address _is_ the address of the routers (destination address is not ARP'd for because the previous router knows it's not a directly-connected destination). with bridging, the MAC address is of the final destination, and is learned by the previous router by ARPing for it (ethernet broadcasts cross the bridge unaltered). see tcpdump -e I read and reread the previous paragraph but I am not able to understand it. Let me try to express my understanding. Please point out the holes in that( I am sure there are many). I am especially confused since you have mentioned forwarding(routing). Routing protocols have two phases or components called building the routing table and actual forwarding of IP packets. It is the building of routing tables that happen over TCP(BGP),UDP(RIP) or IP(OSPF). This happens independently or real packet forwarding which is the primary job of a router. Ignore dynamic routing protocols for now, they don't help you to learn the basics and most networks get along fine without them. You don't need to run a dynamic routing protocol to route packets between directly-connected networks, it happens automatically when you turn on net.inet.ip.forwarding. Let's create a few directly connected networks: (I could of course have used physical nics) # ifconfig vlan100 create # ifconfig vlan101 create # ifconfig vlan100 vlan 100 vlandev em0 # ifconfig vlan101 vlan 101 vlandev em0 # ifconfig vlan100 172.16.100.0 netmask 255.255.255.0 # ifconfig vlan101 172.16.101.0 netmask 255.255.255.0 # ifconfig vlan vlan100: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 00:0a:e4:2d:99:ee vlan: 100 priority: 0 parent interface: em0 groups: vlan inet6 fe80::20a:e4ff:fe2d:99ee%vlan100 prefixlen 64 scopeid 0x8 inet 172.16.100.0 netmask 0xff00 broadcast 172.16.100.255 vlan101: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 00:0a:e4:2d:99:ee vlan: 101 priority: 0 parent interface: em0 groups: vlan inet6 fe80::20a:e4ff:fe2d:99ee%vlan101 prefixlen 64 scopeid 0x9 inet 172.16.101.0 netmask 0xff00 broadcast 172.16.101.255 # netstat -rnfinet Routing tables Internet: DestinationGatewayFlagsRefs UseMtu Interface default85.158.44.145 UGS 5 427136 - ath0 85.158.44.144/28 link#2 UC 40 - ath0 85.158.44.145 00:00:24:c2:e1:f8 UHLc214390 - ath0 85.158.44.146 00:0e:9b:93:23:e4 UHLc02 - lo0 127/8 127.0.0.1 UGRS00 33224 lo0 127.0.0.1 127.0.0.1 UH 7 144072 33224 lo0 172.16.100/24 link#8 UC 00 - vlan100 172.16.101/24 link#9 UC 00 - vlan101 224/4 127.0.0.1 URS 00 33224 lo0 Any packets arriving on vlan100 with a destination address of 172.16.101.xx first get ARP'd for, then assuming a suitable MAC address was found they get passed on. Now, once an IP packet arrives thro' an interface of a router, its destination IP address is looked up in the routing table, its TTL value checked and decremented, its IP checksum recomputed since we modified the TTL, and then finally(and most importantly), the destination MAC address of the packet modified to match the longest prefix match of the routing table lookup. Thus, if you see actually it is the destination MAC address stored in the ethernet header that is actually modified at every hop of the router. The IP header is largely untouched. Yes that's it. Then it's shoved out the relevant interface. Now, briding is actually the job of a layer 2 device like a switch/hub and mostly happens in hardware since it is a dumb function. A bridge learns which addresses are on each side and only forwards those frames across: a hub is not a bridge. A switch is a multi-port bridge. (In the olden days a common setup might be to have two buildings with hub-based networks or more likely coax or 10base5 with a bridge separating them so that local traffic stayed within the building). What OpenBSD hopes to achieve thro' providing briding in software is to do that same job intelligently. The man page clearly says that. If you add pf to briding then voila!, you have a marvellous way to filter packets transparently without actually modifying the routing topology of the network. Yes,
Re: Setting up a box to do NAT and Static IPs
On 12/10/06, Stuart Henderson [EMAIL PROTECTED] wrote: or, for that matter, why I needed to enable net.inet.ip.forwarding=1 in /etc/sysctl.conf for the bridge to work. just checked and you definitely don't need net.inet.ip.forwarding=1 to bridge. net.inet.ip.forwarding is for IP packets, not ethernet frames. not even when I'm running pf(4) on the bridge?
Re: Setting up a box to do NAT and Static IPs
On 2006/10/12 13:57, ropers wrote: On 12/10/06, Stuart Henderson [EMAIL PROTECTED] wrote: or, for that matter, why I needed to enable net.inet.ip.forwarding=1 in /etc/sysctl.conf for the bridge to work. just checked and you definitely don't need net.inet.ip.forwarding=1 to bridge. net.inet.ip.forwarding is for IP packets, not ethernet frames. not even when I'm running pf(4) on the bridge? not the one I just setup as a quick test... (amd64, last snapshot before the tree unlocked, bridging sk0 to nfe0, though I doubt any of that makes a difference). think there must be something else at play on yours. you do of course need ...ip.forwarding=1 for NAT though.
Re: Setting up a box to do NAT and Static IPs
On 10/11/06, ropers [EMAIL PROTECTED] wrote: I've just had another thought: Why do the IP phones have to have public IPs? Is this because giving them NATted, private range IPs previously didn't work so well? The VoIP phones Patrick is using are probably (my guess) using the Session Initiation Protocol (SIP) for signalling. http://en.wikipedia.org/wiki/Session_Initiation_Protocol SIP embeds IP information of the host (phone) inside the exchanged application messages and make use of the Session Description Protocol whenever it tries to set up a voice call (using the INVITE transaction) so that both phone know which kind of of voice/video stream encoding to expect, and on which port and IP it'll be coming to/from. http://en.wikipedia.org/wiki/Session_Description_Protocol If Patrick puts the phones behind a NAT box then the phones will have private IPs and will reflect these privates IPs in whatever SIP messages they send out onto the Internet. Unfortunately, if public phones receive these SIP messages with private IPs they might try to contact said IPs, which will fail miserably. It's a similar issue to NAT and FTP, since FTP also embeds IP address inside the control stream of the FTP session. Hence this is why OpenBSD has ftp-proxy(8). If Patrick wants to use SIP behind NAt he'll need the added intelligence of an Application Level Gateway. http://en.wikipedia.org/wiki/Application-level_gateway An ALG tracks SIP sessions and performs all the necessary NATs and creates all the dynamic firewall rules to allow incoming and outgoing media traffic for phone calls. I don't think pf alone will fit the bill for this. That's why if he has public IPs available for the phones it might be the quickest route to success. Still, if you *are* stuck behind a NAT and you have SIP phones and you don't want to spend a fortune on an ALG there might be open source solutions (which I have never looked into) that will achieve the same thing. A quick search on Google did turn this up: http://siproxd.sourceforge.net/index.php?op=overview Could be interesting... -Martin -- Suburbia is where the developer bulldozes out the trees, then names the streets after them. --Bill Vaughan
Re: Setting up a box to do NAT and Static IPs
On 11/10/06, Martin Gignac [EMAIL PROTECTED] wrote: On 10/11/06, ropers [EMAIL PROTECTED] wrote: I've just had another thought: Why do the IP phones have to have public IPs? Is this because giving them NATted, private range IPs previously didn't work so well? The VoIP phones Patrick is using are probably (my guess) using the Session Initiation Protocol (SIP) for signalling. http://en.wikipedia.org/wiki/Session_Initiation_Protocol SIP embeds IP information of the host (phone) inside the exchanged application messages and make use of the Session Description Protocol whenever it tries to set up a voice call (using the INVITE transaction) so that both phone know which kind of of voice/video stream encoding to expect, and on which port and IP it'll be coming to/from. http://en.wikipedia.org/wiki/Session_Description_Protocol If Patrick puts the phones behind a NAT box then the phones will have private IPs and will reflect these privates IPs in whatever SIP messages they send out onto the Internet. Unfortunately, if public phones receive these SIP messages with private IPs they might try to contact said IPs, which will fail miserably. It's a similar issue to NAT and FTP, since FTP also embeds IP address inside the control stream of the FTP session. Hence this is why OpenBSD has ftp-proxy(8). If Patrick wants to use SIP behind NAt he'll need the added intelligence of an Application Level Gateway. http://en.wikipedia.org/wiki/Application-level_gateway An ALG tracks SIP sessions and performs all the necessary NATs and creates all the dynamic firewall rules to allow incoming and outgoing media traffic for phone calls. I don't think pf alone will fit the bill for this. That's why if he has public IPs available for the phones it might be the quickest route to success. Still, if you *are* stuck behind a NAT and you have SIP phones and you don't want to spend a fortune on an ALG there might be open source solutions (which I have never looked into) that will achieve the same thing. A quick search on Google did turn this up: http://siproxd.sourceforge.net/index.php?op=overview Once again, thanks a whole bunch for your excellent and insightful information. :)
Re: Setting up a box to do NAT and Static IPs
On Wed, Oct 11, 2006 at 09:32:07AM -0400, Martin Gignac wrote: On 10/11/06, ropers [EMAIL PROTECTED] wrote: I've just had another thought: Why do the IP phones have to have public IPs? Is this because giving them NATted, private range IPs previously didn't work so well? The VoIP phones Patrick is using are probably (my guess) using the Session Initiation Protocol (SIP) for signalling. http://en.wikipedia.org/wiki/Session_Initiation_Protocol SIP embeds IP information of the host (phone) inside the exchanged application messages and make use of the Session Description Protocol whenever it tries to set up a voice call (using the INVITE transaction) so that both phone know which kind of of voice/video stream encoding to expect, and on which port and IP it'll be coming to/from. http://en.wikipedia.org/wiki/Session_Description_Protocol If Patrick puts the phones behind a NAT box then the phones will have private IPs and will reflect these privates IPs in whatever SIP messages they send out onto the Internet. Unfortunately, if public phones receive these SIP messages with private IPs they might try to contact said IPs, which will fail miserably. It's a similar issue to NAT and FTP, since FTP also embeds IP address inside the control stream of the FTP session. Hence this is why OpenBSD has ftp-proxy(8). If Patrick wants to use SIP behind NAt he'll need the added intelligence of an Application Level Gateway. http://en.wikipedia.org/wiki/Application-level_gateway An ALG tracks SIP sessions and performs all the necessary NATs and creates all the dynamic firewall rules to allow incoming and outgoing media traffic for phone calls. I don't think pf alone will fit the bill for this. That's why if he has public IPs available for the phones it might be the quickest route to success. Still, if you *are* stuck behind a NAT and you have SIP phones and you don't want to spend a fortune on an ALG there might be open source solutions (which I have never looked into) that will achieve the same thing. A quick search on Google did turn this up: http://siproxd.sourceforge.net/index.php?op=overview Could be interesting... -Martin If my memory serves me right, SIP actually has ALG built into the standard itself and www.opensip.org might already give you what you want. NAT traversal has been a problem for VoIP and there are several strategies. I am talking about UDP hole punching in my article. But you can do the same thing for TCP too though it might not work as reliably as UDP. http://www.linuxjournal.com/9004 But what I am wondering is since this is a known issue, if there is any better and more elegant solutions already... regards, Girish
Re: Setting up a box to do NAT and Static IPs
On 10/11/06, Girish Venkatachalam [EMAIL PROTECTED] wrote: If my memory serves me right, SIP actually has ALG built into the standard itself and www.opensip.org might already give you what you want. Hmm, wasn't aware of that. Do you have any specific RFC or 3GPP spec number that I could check out concerning this? -Martin -- Suburbia is where the developer bulldozes out the trees, then names the streets after them. --Bill Vaughan
Re: Setting up a box to do NAT and Static IPs
Yes, I've tried siproxd, but my lack of knowledge has caused me to fail to get this working properly. I'm VERY excited with all the responses you folks gave me. Now I have to take the time to read all them over. I'll respond to the other posts very soon. Thank you once again for all the help - this mailing list rocks! Patrick Martin Gignac wrote: On 10/11/06, ropers [EMAIL PROTECTED] wrote: I've just had another thought: Why do the IP phones have to have public IPs? Is this because giving them NATted, private range IPs previously didn't work so well? The VoIP phones Patrick is using are probably (my guess) using the Session Initiation Protocol (SIP) for signalling. http://en.wikipedia.org/wiki/Session_Initiation_Protocol SIP embeds IP information of the host (phone) inside the exchanged application messages and make use of the Session Description Protocol whenever it tries to set up a voice call (using the INVITE transaction) so that both phone know which kind of of voice/video stream encoding to expect, and on which port and IP it'll be coming to/from. http://en.wikipedia.org/wiki/Session_Description_Protocol If Patrick puts the phones behind a NAT box then the phones will have private IPs and will reflect these privates IPs in whatever SIP messages they send out onto the Internet. Unfortunately, if public phones receive these SIP messages with private IPs they might try to contact said IPs, which will fail miserably. It's a similar issue to NAT and FTP, since FTP also embeds IP address inside the control stream of the FTP session. Hence this is why OpenBSD has ftp-proxy(8). If Patrick wants to use SIP behind NAt he'll need the added intelligence of an Application Level Gateway. http://en.wikipedia.org/wiki/Application-level_gateway An ALG tracks SIP sessions and performs all the necessary NATs and creates all the dynamic firewall rules to allow incoming and outgoing media traffic for phone calls. I don't think pf alone will fit the bill for this. That's why if he has public IPs available for the phones it might be the quickest route to success. Still, if you *are* stuck behind a NAT and you have SIP phones and you don't want to spend a fortune on an ALG there might be open source solutions (which I have never looked into) that will achieve the same thing. A quick search on Google did turn this up: http://siproxd.sourceforge.net/index.php?op=overview Could be interesting... -Martin
Re: Setting up a box to do NAT and Static IPs
Yes, I've tried siproxd, but my lack of knowledge has caused me to fail to get this working properly. Then using your available public IPs should be the ticket. -Martin -- Suburbia is where the developer bulldozes out the trees, then names the streets after them. --Bill Vaughan
Re: Setting up a box to do NAT and Static IPs
Martin Gignac wrote: On 10/11/06, Girish Venkatachalam [EMAIL PROTECTED] wrote: If my memory serves me right, SIP actually has ALG built into the standard itself and www.opensip.org might already give you what you want. Hmm, wasn't aware of that. Do you have any specific RFC or 3GPP spec number that I could check out concerning this? -Martin The standard? But SIP has so many. There are some old, long expired drafts that touch on the topic, e.g., http://www1.cs.columbia.edu/sip/drafts/draft-ietf-nat-protocol-complications-00.txt There's a best current practice document for call flow that mentions SIP ALGs: ftp://ftp.rfc-editor.org/in-notes/rfc3665.txt but that's more about proxies than about something that untangles NAT. But the core spec, RFC 3261, http://www.rfc-editor.org/rfc/rfc3261.txt , doesn't touch on the topic at all so far as I've ever noticed. NAT fixup for SIP is a nasty thing and I've seen a number of broken implementations and incompatible solutions. As a hosted IP PBX provider, we've had the best luck using session border controllers at the edge of our network, which are configured to assume that phones are behind NAT. We tell our customers to not even think about STUN ( ftp://ftp.rfc-editor.org/in-notes/rfc3489.txt ), to not even think about putting the phones behind a firewall with any ALG functionality turned on (one ALG works fine until we issue a reinvite upon changing from ringing all the phones in a hunt group to actually establishing RTP streams with the phone that picks up, at which point the ALG drops all the packets; one mostly works except it plays funny games with port numbers sometimes and starts sending registration requests from a single phone using multiple port numbers, leading to confusion about where we're to send invites, etc., etc.) Unfortunately, SIP is nowhere near being a standard where you can assume interop just because you implement a bunch of RFCs. Especially if you mix NAT in. See http://en.wikipedia.org/wiki/Session_Border_Controller for more, including some nice references. --Jon Radel [EMAIL PROTECTED] [demime 1.01d removed an attachment of type application/x-pkcs7-signature which had a name of smime.p7s]
Re: Setting up a box to do NAT and Static IPs
On 10/11/06, Jon Radel [EMAIL PROTECTED] wrote: If my memory serves me right, SIP actually has ALG built into the standard itself and www.opensip.org might already give you what you want. Hmm, wasn't aware of that. Do you have any specific RFC or 3GPP spec number that I could check out concerning this? -Martin The standard? But SIP has so many. I was asking because although I'm familiar with the usual SIP RFCs (3261 and family) I was not aware of the SIP actually has ALG built into the standard itself notion that Girish mentionned and I wanted to know if there was any actual documentation to support this. But the core spec, RFC 3261, http://www.rfc-editor.org/rfc/rfc3261.txt , doesn't touch on the topic at all so far as I've ever noticed. Yeah, I've never heard of this in 3261 either. NAT fixup for SIP is a nasty thing and I've seen a number of broken implementations and incompatible solutions. As a hosted IP PBX provider, we've had the best luck using session border controllers at the edge of our network, which are configured to assume that phones are behind NAT. Yeah, we use SBCs in IMS as well. Unfortunately, SIP is nowhere near being a standard where you can assume interop just because you implement a bunch of RFCs. Especially if you mix NAT in. Add to that the 3GPP and OMA additions for IMS and it gets even wilder. -Martin -- Suburbia is where the developer bulldozes out the trees, then names the streets after them. --Bill Vaughan
Re: Setting up a box to do NAT and Static IPs
On 10/9/06, Patrick - South Valley Internet [EMAIL PROTECTED] wrote: Hi all, I have a box I installed OpenBSD 3.9 on. I'm trying to get this box to function as our office firewall. Here's the catch - we have VOIP phones that contact an external VOIP server outside of our firewall. I've been doing some research and found out that VOIP phones don't do NAT very well, and because of that you need to put them on their own static IPs. I've tried the sip proxy route, and honestly it was entirely over my head and I just couldn't understand how to get it to work. You are really asking for alot of work to try and do this with two NICs. Here's how we do it as a service provider: 1 vlan for data, 1 vlan for voice stuff. One device/router with essentially three interfaces: one that serves as a wan connection and two ethernet interfaces, one for each vlan. Firewall the data vlan however you want, and give each phone the equivlanet of a static address.
Re: Setting up a box to do NAT and Static IPs
On 11/10/06, Martin Gignac [EMAIL PROTECTED] wrote: Yes, I've tried siproxd, but my lack of knowledge has caused me to fail to get this working properly. Then using your available public IPs should be the ticket. -Martin Yah, it's becoming clearer. Use whatever is cleaner and easier to implement. If ALG/siproxd is actually **more** complex than NAT -- use NAT with VLANs and public IPs for the IP phones, as Martin said. OTOH, if you do have enough public IPs to play with, I'd still consider bridging and using only public IPs (then you don't need to do VLANs or NAT). And speaking of that, I just re-read your (Patrick's) earlier emails: Patrick wrote: Technically, we don't need NAT, but I want to free up some IP addresses in our company so we can use them elsewhere. That's why I wanted to put all the computers behind NAT. I guess I could assign an entire class C to our office computers, but IMO that isn't really efficient. Sorry if I'm asking stupid questions, but you know all about VLSM/CIDR, right? You know that you don't have to choose between assigning a whole class C subnet or NAT, right? You know that you can apportion any number of bits for your subnet, right? I was just playing with the details you gave earlier (mostly to practice and teach myself): Your friend suggested IPs like 216.139.44.142 and a 255.255.255.192 subnet mask: last octet for IP 216.139.44.142/26: 128 64 |32 16 8 4 2 1 1 0 | 0 0 1 1 1 0 + From 216.139.44.128/26 (x.y.z.1000) through 216.139.44.191/26 (x.y.z.1011), that's 64 IP addresses in total. How many hosts do you have, including the IP phones? How much room for future growth do you need to reserve? If you can steal enough bits off that last octet, then the easiest way may still be a bridge, which has the added advantage of being transparent to the end user. And it can be changed, substituted and removed in the future without so much as an interruption in service (as long as you have a switch with free ports both before and behind the firewall).
Re: Setting up a box to do NAT and Static IPs
Hey Jens, On 10/11/06, ropers [EMAIL PROTECTED] wrote: OTOH, if you do have enough public IPs to play with, I'd still consider bridging and using only public IPs (then you don't need to do VLANs or NAT). To satisfy my own curiosity, what are the advantages in your view that bridging offers between the internal and external interface compared to using typical ip fowarding? (Note: I've never worked with bridging on an OpenBSD firewall, so I'm a newbie at it.) -Martin -- Suburbia is where the developer bulldozes out the trees, then names the streets after them. --Bill Vaughan
Re: Setting up a box to do NAT and Static IPs
On 11/10/06, Martin Gignac [EMAIL PROTECTED] wrote:
Hey Jens,
On 10/11/06, ropers [EMAIL PROTECTED] wrote:
OTOH, if you do have enough public IPs to play with, I'd still
consider bridging and using only public IPs (then you don't need to do
VLANs or NAT).
To satisfy my own curiosity, what are the advantages in your view that
bridging offers between the internal and external interface compared
to using typical ip fowarding?
(Note: I've never worked with bridging on an OpenBSD firewall, so I'm
a newbie at it.)
I have limited expertise myself --while I do claim some OpenBSD
experience, that experience is has its limits and I can't code. So
here's my understanding, but if I'm wrong anywhere I would be very
happy to get corrected:
Let's assume I have am OpenBSD box with adapters $ext_if and $int_if,
and $ext_if is connected to a switch on a WAN, and $int_if is
connected to a switch that a number of hosts are connected to. Let's
say on the WAN IP subnet 123.0.0.0/8 is being used. Now I somehow want
to provide firewall protection to the hosts on the $inf_if side.
I could use NAT and give both the $int_if and $ext_if NICs IP
addresses. That way I sould make the part on the $int_if side into a
subnet using eg. 192.168.0.0/16. I could assign 123.1.2.3 to $ext_if
and 192.168.1.2 to $int_if. I would not use bridging and none of the
NICs would be in promiscuous mode.
Or maybe I have gotten a small chunk off of that big fat 123.0.0.0/8
network to play with. So let's say I have been allocated
123.123.123.0/24. I would put the external interface in promiscuous
mode (echo up /etc/hostname.if) but assign an IP to the internal
one, say 123.123.123.123. This IP would be my default gateway on the
internal hosts. They need to know where the heck to send packets that
aren't for hosts on what's now their own local subnet. Apart from the
fact that I'm using IP addresses of the same type (public in this
case) on both sides of the firewall, and that those IPs have to be
properly assigned to/subnetted by me, I'm still king in my castle --
my 123.123.123.0/24 subnet can be fairly independent.
Finally, I could use bridging. This puts both NICs in promiscuous
mode, even if I assign an IP address to one of them, which is a good
idea to allow remote administration (I could assign IPs to both but
there's prolly no good reason to). Also I could decide to only allow
local/serial console administration, and on purpose don't give IPs to
either NICs. With bridging, both sides are logically on the same
network segment, it's as if the network parts in front and behind the
firewall were just one physical network segment. This is transparent
bridging. Neither host on either side needs to even know that that
bridge is even there. And indeed it would be largely useless (well,
useful for range extension beyond max cabling lengths) as long as it
weren't also filtering. Once you packet filter on the bridge it
becomes a magic cable that's just part of a larger segment, but for
some reason doesn't allow garbage through. Good if you have to share a
subnet with undesirables.
I have a setup where there's a switch that's directly connected to the
Internets, that's outside of my control, and that my Windows Server
2003 Domain Controller has to share with third parties. Yeuch! So I
put that box behind an OpenBSD nanny^Wbridging firewall. Trouble is,
there are all these other hosts outside that firewall who are directly
connected to the switch, and these all need to talk to the DC and
expect it to be on the same subnet. Also, I want to put more hosts
behind the firewall. No problem with bridging.
I hope this makes sense.
What I don't really understand is where bridging actually takes place,
and what happens in case of a filtering bridge. I thought that
bridging per se happened at the data-link layer of the OSI model,
while packet filtering happened at the network layer.
Neither do I understand what really goes on during IP forwarding as
opposed to bridging, or, for that matter, why I needed to enable
net.inet.ip.forwarding=1 in /etc/sysctl.conf for the bridge to work.
Cheers,
--ropers
PS: What was quite interesting to learn about is how to enable DHCP
requests (inclusive DHCPDISCOVER messages) from certain hosts to
traverse this firewall:
pass on $ext_if proto udp from { 0.0.0.0, goodoutsiders } port 68 to
$dhcpsrv port 67
pass on $ext_if proto udp from any port 68 to 255.255.255.255 port 67
pass on $ext_if proto udp from $dhcpsrv port 67 to { 255.255.255.255,
goodoutsiders } port 68
PPS: OT, but according to MS' official documentation, you can't turn
on the Windows Firewall on a DC (or if you do turn it on, the DC won't
work. But since putting the OpenBSD box in I've also learned that
there are additional solutions to the unprotected Win 2003 DC problem:
Core Force, building your own Windows firewall with IPsec and mmc,
hax0ring the registry of all DCs in the forest to constrain their use
of dynamic ports and then configuring exceptions
Re: Setting up a box to do NAT and Static IPs
On 2006/10/12 01:15, ropers wrote: Or maybe I have gotten a small chunk off of that big fat 123.0.0.0/8 network to play with. So let's say I have been allocated 123.123.123.0/24. Normally, you get a separate address _as_well_. Let's say 123.4.5.6/30. Say you don't run a dynamic routing protocol you would set the default route to 123.4.5.5. The internal network 123.123.123.0 is yours to play with and carve up as you like, say you take 123.123.123.1 and tell the other hosts in the subnet that's their default gateway. Provider receives packets for 123.123.123.123; their route table has 123.4.5.6 as the destination for 123.123.123/24 and sends the packets along. No promiscuous interfaces, this is just plain ordinary IP routing. I have a setup where there's a switch that's directly connected to the Internets, that's outside of my control, and that my Windows Server 2003 Domain Controller has to share with third parties. Yeuch! So I put that box behind an OpenBSD nanny^Wbridging firewall. Yes, bridging firewalls are useful where you don't have IP traffic for the whole subnet forwarded to your router by normal IP routing. The situation you describe is one. ISPs giving a `managed router' where they can't be bothered to manage it enough to add routing-table entries for you is another. What I don't really understand is where bridging actually takes place, and what happens in case of a filtering bridge. I thought that bridging per se happened at the data-link layer of the OSI model, OSI is just a model (-: Neither do I understand what really goes on during IP forwarding as opposed to bridging with forwarding(routing) tcp/ip packets have a destination IP address which isn't bound to an interface on the router but the MAC address _is_ the address of the routers (destination address is not ARP'd for because the previous router knows it's not a directly-connected destination). with bridging, the MAC address is of the final destination, and is learned by the previous router by ARPing for it (ethernet broadcasts cross the bridge unaltered). see tcpdump -e or, for that matter, why I needed to enable net.inet.ip.forwarding=1 in /etc/sysctl.conf for the bridge to work. I'm not sure you do, but I think you need it for PF. If it was a bit more sensible time of day I'd double-check (-:
Re: Setting up a box to do NAT and Static IPs
Hi again Jens, On 10/11/06, Stuart Henderson [EMAIL PROTECTED] wrote: On 2006/10/12 01:15, ropers wrote: Or maybe I have gotten a small chunk off of that big fat 123.0.0.0/8 network to play with. So let's say I have been allocated 123.123.123.0/24. Normally, you get a separate address _as_well_. Let's say 123.4.5.6/30. Say you don't run a dynamic routing protocol you would set the default route to 123.4.5.5. The internal network 123.123.123.0 is yours to play with and carve up as you like, say you take 123.123.123.1 and tell the other hosts in the subnet that's their default gateway. I think what confused my about your suggestion of using bridging is because I'm used to having setups like the one Stuart mentioned: that is, having an ISP assign an IP for the external interface of my firewall (a /30 one in the case of a point-to-point link) and giving me a range of public IPs for which the next hop router will be configured as the IP assigned to the external interface. This info will be configured in the ISP's router (the default gateway from my firewall's point of view) and I'll use the range of public IPs on the internal interface. In these types of cases I wouldn't use bridging; simply IP forwarding. Yes, bridging firewalls are useful where you don't have IP traffic for the whole subnet forwarded to your router by normal IP routing. The situation you describe is one. ISPs giving a `managed router' where they can't be bothered to manage it enough to add routing-table entries for you is another. I've never had to deal with the cases mentioned in the paragraph above, which explains why I've never looked into bridging. Also, I am a bit concerned about having the phones and the office computers on the same subnet: some of these brands of VoIP phones (at least the Cisco 7940s) have a TELNET interface on them and can boot off of a TFTPd server. I think it'd be safer to have the phones on their own subnets, protected by the OpenBSD firewall, so that some curious office worker armed with nmap doesn't start trying to figure out the IPs of all the phone and begins trying to access them just for the fun of it. Also, by separating the phones from the PCs in two different subnets you save a bit on broadcast and possible multicast (if your switch is not IGMP-aware) traffic. Anyway, I guess that's how I'd do it. -Martin -- Suburbia is where the developer bulldozes out the trees, then names the streets after them. --Bill Vaughan
Re: Setting up a box to do NAT and Static IPs
On Wed, Oct 11, 2006 at 12:22:06PM -0400, Martin Gignac wrote: On 10/11/06, Girish Venkatachalam [EMAIL PROTECTED] wrote: If my memory serves me right, SIP actually has ALG built into the standard itself and www.opensip.org might already give you what you want. Hmm, wasn't aware of that. Do you have any specific RFC or 3GPP spec number that I could check out concerning this? -Martin You could have easily googled for SIP RFC. That is what one would expect from OpenBSD crowd... Anyway I can certainly provide you with more info. But the problem is, I worked on VoIP more than two years ago and I never really worked on SIP. I read the RFC, that is all. Check out http://www.faqs.org/rfcs/rfc3261.html Pay particular attention to the various components of the protocol. In particular, focus on proxy server and user agent. SIP I believe is quite popular in the VoIP world and it has a simple text protocol very similar to HTTP. I am sorry, I can't help you any further. I wish I had more experience implementing real world VoIP solutions but I don't have. All the best! regards, Girish
Re: Setting up a box to do NAT and Static IPs
On Thu, Oct 12, 2006 at 09:26:21AM +0530, Girish Venkatachalam wrote: On Wed, Oct 11, 2006 at 12:22:06PM -0400, Martin Gignac wrote: On 10/11/06, Girish Venkatachalam [EMAIL PROTECTED] wrote: If my memory serves me right, SIP actually has ALG built into the standard itself and www.opensip.org might already give you what you want. Hmm, wasn't aware of that. Do you have any specific RFC or 3GPP spec number that I could check out concerning this? -Martin You could have easily googled for SIP RFC. That is what one would expect from OpenBSD crowd... Very Sorry Martin. I was not in a good mood this morning and I also got angry since I didn't know enough to help you out. Because VoIP has always fascinated me and even my attempts at hacking Asterisk fizzled out. I hope to play with these things soon. Please don't mind it. I had a dream last night and could not get proper sleep. Have a nice day! Hope you don't take it to heart. regards, Girish
Re: Setting up a box to do NAT and Static IPs
On 10/12/06, Girish Venkatachalam [EMAIL PROTECTED] wrote: Very Sorry Martin. I was not in a good mood this morning and I also got angry since I didn't know enough to help you out. Have a nice day! Hope you don't take it to heart. No sweat. :-) -- Suburbia is where the developer bulldozes out the trees, then names the streets after them. --Bill Vaughan
Re: Setting up a box to do NAT and Static IPs
On 10/11/06, Girish Venkatachalam [EMAIL PROTECTED] wrote: On Wed, Oct 11, 2006 at 12:22:06PM -0400, Martin Gignac wrote: On 10/11/06, Girish Venkatachalam [EMAIL PROTECTED] wrote: If my memory serves me right, SIP actually has ALG built into the standard itself and www.opensip.org might already give you what you want. Hmm, wasn't aware of that. Do you have any specific RFC or 3GPP spec number that I could check out concerning this? -Martin You could have easily googled for SIP RFC. That is what one would expect from OpenBSD crowd... Anyway I can certainly provide you with more info. But the problem is, I worked on VoIP more than two years ago and I never really worked on SIP. I read the RFC, that is all. Check out http://www.faqs.org/rfcs/rfc3261.html Pay particular attention to the various components of the protocol. In particular, focus on proxy server and user agent. Yeah, I'm familiar with 3261. However the SIP proxy that 3261 talks about has a completely different function than what an ALG/SBC does. Maybe I shouldn't have used the term SIP proxy in my previous e-mails. My bad. -Martin -- Suburbia is where the developer bulldozes out the trees, then names the streets after them. --Bill Vaughan
Re: Setting up a box to do NAT and Static IPs
On 10/12/06, Martin Gignac [EMAIL PROTECTED] wrote: Yeah, I'm familiar with 3261. However the SIP proxy that 3261 talks about has a completely different function than what an ALG/SBC does. Maybe I shouldn't have used the term SIP proxy in my previous e-mails. My bad. I don't know if it'll make things any clearer (I doubt it), but you could compare the SIP proxy in RFC 3261 as a combination HSS/CSCF in 3GPP IMS (IP Multimedia Subsystem) parlance whereas the ALG/SBC performs the function of an I-BCF/I-BGF (man, who thinks up all of these acronyms). http://en.wikipedia.org/wiki/IP_Multimedia_Subsystem http://www.dataconnection.com/sbc/imsarch.htm -Martin -- Suburbia is where the developer bulldozes out the trees, then names the streets after them. --Bill Vaughan
Re: Setting up a box to do NAT and Static IPs
We currently have a Cisco PIX firewall that we are using for our office firewall and our VOIP phones. The guy who was here before me only gave the office computers 32 available DHCP addresses, and set all the VOIP phones (Cisco 7960 and Grandstream phones) on static ips. What other information can I provide you to help me come up with a solution? Thanks for the responses! Patrick Martin Gignac wrote: On 10/9/06, Patrick - South Valley Internet [EMAIL PROTECTED] wrote: 1) Get two NICS for the OpenBSD box. 2) Give the first NIC an external routeable IP address, ex. 216.139.44.142 subnet 255.255.255.192 3) Give the second NIC an internal IP address, ex. 10.30.1.1 subnet mask 255.255.255.0 4) Give the second NIC an external IP address as well, ex. 216.139.44.143 subnet mask 255.255.255.192 5) Enable the gateway option in OpenBSD Oops, read too quickly. I hadn't noticed that the subnets at #2 and at #4 are the same. Before installing the OpenBSD box did you already have a firewall or have the VoIP phones been directly on the Internet all this time? -Martin
Re: Setting up a box to do NAT and Static IPs
What other information can I provide you to help me come up with a solution? A quick ASCII diagram of the PIX and the subnets in front and back might help (I'm the visual type). The only subnet you mention with public IPs in your first e-mail is 216.139.44.142/26, in which the IPs mentioned in suggestions # 2 and #4 lie. Maybe I'm missing the point here but you obviously won't be able to route between the two interfaces if they're on the same subnet. Either you *do* want to perform bridging, as ropers suggested, or then maybe I just don't have a clear picture of what's where (hence the request for a simple ASCII diagram). -Martin -- Suburbia is where the developer bulldozes out the trees, then names the streets after them. --Bill Vaughan
Re: Setting up a box to do NAT and Static IPs
Thanks for the response Martin. Maybe I wasn't clear enough. Let me rephrase everything in this email: We currently have a firewall using a Cisco PIX server. Everything on this firewall is using a static ip of some sort. There is a range of IP addresses inside the PIX firewall that are being used for DHCP. These IP addresses aren't important since I will be using entirely new IPs for the new firewall, and will be manually configuring all the machines and IP phones to use different IP addresses. Some of the computers are using DHCP, others are using IP addresses that are hardcoded into the computers and phones. Everything gets an IP address. I want to change this. My thoughts were to put all the computers in the office behind NAT and just give them internal IP addresses using 10.30.1.0/24 with subnet of 255.255.255.0. Since the IP phones don't do NAT very well, I wanted to give them static IP addresses. I could just assign a class C to the firewall, but I think that is a waste of IPs. The office computers only are used for email and web browsing, so they don't require any ports to be forwarded to them for any reason. Given this information, what is the best route to go to set this up? A friend suggested giving the first NIC an external IP address, and giving the second NIC both an internal address (10.30.1.1, since it will be the gateway for the office computers) as well as an external IP address, and then enable the gateway option in OpenBSD. Patrick Martin Gignac wrote: What other information can I provide you to help me come up with a solution? A quick ASCII diagram of the PIX and the subnets in front and back might help (I'm the visual type). The only subnet you mention with public IPs in your first e-mail is 216.139.44.142/26, in which the IPs mentioned in suggestions # 2 and #4 lie. Maybe I'm missing the point here but you obviously won't be able to route between the two interfaces if they're on the same subnet. Either you *do* want to perform bridging, as ropers suggested, or then maybe I just don't have a clear picture of what's where (hence the request for a simple ASCII diagram). -Martin
Re: Setting up a box to do NAT and Static IPs
We currently have a firewall using a Cisco PIX server. Everything on this firewall is using a static ip of some sort. There is a range of IP addresses inside the PIX firewall that are being used for DHCP. Just to make sure: you say everything on this firewall is using a static IP of some sort, yet you mention a range of IPs inside the PIX are used for DHCP? Which is it? All static or some static and some DHCP? I have to admit I'm a bit confused. Could it be that you are using the term static IP when in fact you mean to say public IP? For example, I'm thinking that you currently have all public IPs configured on your network (by public, I mean non-RFC 1918 addresses). Now I believe what you want to do is start using some *private* IP addresses (one of the ranges defined in RFC 1918) and dispense them using a *dynamic* means, such as DHCP. Am I understanding it better? I do agree with you that you should have a subnet (or multiple subnets) of DHCP-assigned private IP addresses for all the office computers that will be web surfing and such. To save on bandwidth you could install a web proxy such as Squid -- unless you already have one -- and automatically redirect all outbound traffic destined for ports 80 and 443 towards the Squid proxy using the redirect function of pf (you wouldn't even have to explicitly configure any web proxy in the users' browsers as the firewall would do all interception and redirection for you). You should then have a separate subnet (or subnets, if you'll be splitting your class C) for your phones. If you're using VLAN-capable switches then you'll put the PCs on one VLAN and the phones on another. If you're lucky enough to have a whole class C network assigned to you by your ISP (such as 216.139.44.0/24), then you can put all of that class C *behind* the firewall, much like you'll put your private network 10.30.1.0/24 behind it as well. If you only have two NICs on the firewall though, you'll need to create two VLAN interfaces on the internal NIC so that this single NIC can see the two VLANs, have a unique IP for each of them, and be able to filter discreetly on each. Your physical NIC won't even have to have an IP address itself; only the VLAN interfaces will need to. All you'll need is for the physical NIC to appear as UP with 'ifconfig'. You can then create your pf filters using 'vlan0' and 'vlan1' interfaces instead of something like 'fxp0'. If your ISP gave you a whole class C they probably also gave you a public IP address outside of the 216.139.44.0/24 subnet to be used as the external IP of your firewall device. They are then telling their router to forward all IP traffic with a destination of 216.139.44.0/24 to that public IP address they gave you. Given this information, what is the best route to go to set this up? A friend suggested giving the first NIC an external IP address, and giving the second NIC both an internal address (10.30.1.1, since it will be the gateway for the office computers) as well as an external IP address, and then enable the gateway option in OpenBSD. Your friend basically suggested what I'm mentioning above, although he didn't mention VLAN tagging and trunking, which is what you'll need if you want to run two different IP subnets on the same physical interface. I've done this kind of setup before, but I only had one NIC with many VLANs going through it (this kind of setup is usually called router-on-a-stick http://www.gurulabs.com/goodies/routeronastick.php) -Martin -- Suburbia is where the developer bulldozes out the trees, then names the streets after them. --Bill Vaughan
Re: Setting up a box to do NAT and Static IPs
On 10/9/06, Patrick - South Valley Internet [EMAIL PROTECTED] wrote: 1) Get two NICS for the OpenBSD box. 2) Give the first NIC an external routeable IP address, ex. 216.139.44.142 subnet 255.255.255.192 3) Give the second NIC an internal IP address, ex. 10.30.1.1 subnet mask 255.255.255.0 4) Give the second NIC an external IP address as well, ex. 216.139.44.143 subnet mask 255.255.255.192 5) Enable the gateway option in OpenBSD Can you tell me why you want to give the second NIC IP addresses that are *not* in the same subnet? I'm going to assume that you 10.30.1.X subnet is for normal PCs, while the 216.139.44.X subnet is for the VoIP phones, am I right? If that's the case, then I assume you have a separate subnet for your VoIP phones and for your user PCs, right? With that kind of setup I think you'll need a third NIC, or else you'll need a switch than can do VLAN tagging and you'll have to create two subinterface on your second NIC so that each subnet is on its own subinterface. From there you can enable NAT for all 10.30.X.X traffic towards the 'Net and use plain old IP routing for your 216.139.44.143. Make sense? -Martin -- Suburbia is where the developer bulldozes out the trees, then names the streets after them. --Bill Vaughan
Re: Setting up a box to do NAT and Static IPs
On 10/10/06, Patrick - South Valley Internet [EMAIL PROTECTED] wrote: Hi all, I have a box I installed OpenBSD 3.9 on. I'm trying to get this box to function as our office firewall. Here's the catch - we have VOIP phones that contact an external VOIP server outside of our firewall. I've been doing some research and found out that VOIP phones don't do NAT very well, and because of that you need to put them on their own static IPs. I've tried the sip proxy route, and honestly it was entirely over my head and I just couldn't understand how to get it to work. A friend suggested that I should do the following: 1) Get two NICS for the OpenBSD box. 2) Give the first NIC an external routeable IP address, ex. 216.139.44.142 subnet 255.255.255.192 3) Give the second NIC an internal IP address, ex. 10.30.1.1 subnet mask 255.255.255.0 4) Give the second NIC an external IP address as well, ex. 216.139.44.143 subnet mask 255.255.255.192 5) Enable the gateway option in OpenBSD I can successfully give the first NIC its external IP, and for the second NIC, I'm having troubles getting it to recognize both IPs on the 2nd NIC. I can get one IP address, or the other, but not both working at the same time. Now, after I get the NICs set up, and after I enable the gateway option in OpenBSD, I'm a little confused as what to do from there. Am I going about this the right way? Is there an easier way to do what I am trying to accomplish? Do you need NAT? Have you considered running your Firewall as a bridge(4)? Read the NOTES section of the bridge(4) man page though, because there's a catch when it comes to writing rules.
Re: Setting up a box to do NAT and Static IPs
On 10/10/06, ropers [EMAIL PROTECTED] wrote: On 10/10/06, Patrick - South Valley Internet [EMAIL PROTECTED] wrote: Hi all, I have a box I installed OpenBSD 3.9 on. I'm trying to get this box to function as our office firewall. Here's the catch - we have VOIP phones that contact an external VOIP server outside of our firewall. I've been doing some research and found out that VOIP phones don't do NAT very well, and because of that you need to put them on their own static IPs. snip / Am I going about this the right way? Is there an easier way to do what I am trying to accomplish? Do you need NAT? Have you considered running your Firewall as a bridge(4)? Read the NOTES section of the bridge(4) man page though, because there's a catch when it comes to writing rules. Also, wouldn't this be a case for rdr? http://www.openbsd.org/faq/pf/rdr.html
Re: Setting up a box to do NAT and Static IPs
On 10/9/06, Patrick - South Valley Internet [EMAIL PROTECTED] wrote: 1) Get two NICS for the OpenBSD box. 2) Give the first NIC an external routeable IP address, ex. 216.139.44.142 subnet 255.255.255.192 3) Give the second NIC an internal IP address, ex. 10.30.1.1 subnet mask 255.255.255.0 4) Give the second NIC an external IP address as well, ex. 216.139.44.143 subnet mask 255.255.255.192 5) Enable the gateway option in OpenBSD Oops, read too quickly. I hadn't noticed that the subnets at #2 and at #4 are the same. Before installing the OpenBSD box did you already have a firewall or have the VoIP phones been directly on the Internet all this time? -Martin -- Suburbia is where the developer bulldozes out the trees, then names the streets after them. --Bill Vaughan
