# How does masquerade know the interface?

## tommy_fila

Quick and simple question about iptables.

When specifying "-j MASDQUERADE", how does iptables know which interface it should obtain the IP from. In other words, lets say I have a dynamic internet IP, and use DHCP for my local network, how does iptables know which IP to use?

For example, I read the following in a how-to:

```
iptables -t nat -A POSTROUTING -p TCP -j MASQUERADE
```

What would it do? Even if I add an interface, what exactly would it do? Change the source address?

Thanks for the help.

----------

## DaveArb

Change the source address is correct, to the IP of the outgoing interface. Iptables maintains internally information to allow it to return the response packets to the machine that originated the message.

Dave

----------

## Anarcho

I would really change the iptables command to this:

 *Quote:*   

> iptables -t nat -A POSTROUTING -p TCP -o ppp0 -j MASQUERADE

 

Then it only uses Masquerading on the ppp0 Interface, which should do the job.

You can also drop the -p TCP as it will prevent you from using udp with masquerading.

----------

## tommy_fila

 *DaveArb wrote:*   

> Change the source address is correct, to the IP of the outgoing interface. Iptables maintains internally information to allow it to return the response packets to the machine that originated the message.
> 
> Dave

 

But how does it know which one is the outgoing interface? Lets say I have a computer set up as my firewall, and it has one LAN interface going to the internet and one going to the local LAN. How would MASQUERADE know which IP to take?

----------

## IHC

this is in the default route 

try    ip route

it should list your device

----------

## DaveArb

 *tommy_fila wrote:*   

> But how does it know which one is the outgoing interface?

 

As IHC wrote, the default route indicates which is the public interface.

Excerpt from iptables man page:

"Masquerading is equivalent to specifying a mapping to the IP address of the interface the packet is going out"

Dave

----------

## tommy_fila

Ok, let me see if I understand this the right way.

Take the example I had with a computer acting as a firewall -- it's connected to the LAN and the internet.

So a packet comes in, gets DNAT'ed to one of the LAN computers. At the same time, I want it SNAT'ed using MASQUERADE. So MASQUERADE knows which IP on the firewall computer is connected to the LAN and which one to the internet?

You said that MASQUERADE assigns the IP of the default route. But how does it know which outgoing route and incoming packet will eventually take?

Now I have another question:

NAT also works without any specific DNAT or SNAT chains. Right? If I'm browsing the web from a computer on the LAN, it has to go through the firewall computer in order to get to the internet. Does iptables just remember where to packet came from on the LAN and use that address to DNAT incoming packets?

As you can see I'm a little confused. But thanks for all the help so far.

----------

## DaveArb

It is a little confusing when you don't explicitly name the interface, that's the source of Anarcho's comment earlier. It still works, but it's confusing.

 *Quote:*   

> So a packet comes in, gets DNAT'ed to one of the LAN computers.

 

Comes in from where? I think this is the source of your confusion, because it's the part that I have to think twice about. Let's look at some examples.

(1) Some random packet shows up on your Internet interface. It hits your firewall. This packet isn't going to be translated through NAT, because it isn't addressed for a computer inside your network* It has your firewall's IP as destination, and that's where it terminated.

(2) A packet is originated in your LAN, addressed for an IP on the Internet. It hits firewall's LAN, and the routing system sees it goes to the Internet. The NAT is hit, and the packet is masqueraded.

(3) Similar to (1), a packet shows up from Internet, but it is a response to a packet listed in (2). Iptables has kept track of these packets, and changes its address back to the LAN machine to which it belongs. It then is routed normally out the LAN interface, and all it good.

(4) A random packet shows up on your Internet interface, like (1), -but- it is addressed for a computer on your LAN. This will not happen, because the ISP's router you are connected to wouldn't have delivered it to you in the first place (I think this is the scenario that many people get confused over?)

Does this help clarify how it works?

 *tommy_fila wrote:*   

> NAT also works without any specific DNAT or SNAT chains. Right? If I'm browsing the web from a computer on the LAN, it has to go through the firewall computer in order to get to the internet. Does iptables just remember where to packet came from on the LAN and use that address to DNAT incoming packets?

 

As in (3), yes iptables keeps state on these. MASQUERADE is a SNAT target, though.

Dave

*I'm deliberately disregarding port forwarding as a different discussion.

----------

## tommy_fila

Great explanation. It really helped clear up many of my questions.

One last confusion.

To the best of my knowledge, NAT doesn't work by itself. Computers inside the LAN have the firewall computer set as their gateway. But how does the firewall handle the requests? Is there a specific chain to forward all incoming packets from the LAN on to the internet?

Once again, thanks for helping me out. I hate being confused, and now it finally seems like I might understand the iptables enigma.

----------

## DaveArb

 *tommy_fila wrote:*   

> Great explanation. It really helped clear up many of my questions.

 

Thanks, glad to help.

 *tommy_fila wrote:*   

> Computers inside the LAN have the firewall computer set as their gateway. But how does the firewall handle the requests? Is there a specific chain to forward all incoming packets from the LAN on to the internet?

 

This isn't part of NAT at all. Network address translation is changing the IP addresses, making them look to the outside world as if all the requests come from one computer, the firewall computer. If you had a large public IP allocation, you could give each computer on the LAN a publicly-addressable IP and never do NAT at all. Aside from the expense or impossiblity of getting such an allocation, this has serious security implications, because my earlier paragraph (4) would then be feasible, computers on your LAN become visible from the Internet.

The firewall computer's ability to forward packets from its LAN port to public, based on destination address, is routing. This is a standard part of *nix networking. The way your firewall knows what interface to route to is by its own IP addresses, and its network masks.

Dave

----------

## tommy_fila

 *DaveArb wrote:*   

> 
> 
>  *tommy_fila wrote:*   Computers inside the LAN have the firewall computer set as their gateway. But how does the firewall handle the requests? Is there a specific chain to forward all incoming packets from the LAN on to the internet? 
> 
> This isn't part of NAT at all. Network address translation is changing the IP addresses, making them look to the outside world as if all the requests come from one computer, the firewall computer. If you had a large public IP allocation, you could give each computer on the LAN a publicly-addressable IP and never do NAT at all. Aside from the expense or impossiblity of getting such an allocation, this has serious security implications, because my earlier paragraph (4) would then be feasible, computers on your LAN become visible from the Internet.
> ...

 

Now I'm stumbling into confusion again. Am I completely mixinfg oup routing and NAT?

You say that changing IP addresses to make them all look the same is part of NAT. Isn't this also routing? A computer from the LAN makes a request to its gateway (the firewall computer). So the firewall computer needs to change the IP address of the request and forward it on to the internet. Isn't that NAT?  How would you configure iptables to get this setup (LAN ===> Firewall (Gateway) ===> Internet) to work?

----------

## DaveArb

 *tommy_fila wrote:*   

> You say that changing IP addresses to make them all look the same is part of NAT. Isn't this also routing?

 

At least the way I look at it, no. Routing is deciding which network device a packet needs to be placed upon to get to its destination. Big fancy routers like ISPs use are a little different (IIRC, read up on stuff like BGP if interested), but a simple machine like a gateway router/firewall works this way.

 *Quote:*   

> the firewall computer needs to change the IP address of the request and forward it on to the internet.

 

It's a little more like (a) determine where the packet needs to go (routing), (b) change the IP address (NAT), (c) forward to Internet (transport.)

 *Quote:*   

> How would you configure iptables to get this setup (LAN ===> Firewall (Gateway) ===> Internet) to work?

 

Assuming Internet on eth0:

```
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
```

-t nat: Add to the nat table

-A POSTROUTING: in the postrouting (note postrouting, the destination of the packet having already been determined by routing) chain.

-o eth0: leaving the eth0 (Internet) port

-j MASQUERADE: Use the MASQUERADE target, which is NAT with a little special processing for dynamic IPs.

That's all that is required for NAT. Everything else in a typical iptables script is port forwarding and security dropping, logging, etc. Be sure when you go "shopping" for iptables scripts that you're looking at ones intended for a gateway firewall application, the ones used for a personal (desktop) computer look quite a bit different.

Dave

----------

## tommy_fila

So a Gentoo install can automatically function as a gateway? I thought the computer had to be configured a certain way in order for it to act as the gateway. From my Windows days, I remember using a program (e.g. Sygate) for my gateway computer. Gentoo knows when it's a gateway? Or do you need to enable some kernel options? (I remember reading about some kernel option about IP forwarding).

One more thing. Do I need to run a DNS server on my firewall computer? From what I've read, it seems like I need to install one.

Thanks again for sticking with me on this one.

And one more. I don't understand the following command. The command is supposed to block all telnet conncections:

```
iptables -A INPUT -s 200.200.200.1 -p tcp --destination-port telnet -j DROP
```

Shouldn't it be source port? I thought iptables would have to check where the packet came from. And if it's source port is a telnet port, then it would block it. Why destination port? The client can run on any port? Or not?

----------

## DaveArb

 *tommy_fila wrote:*   

> So a Gentoo install can automatically function as a gateway?

 

For some versions of "gateway", yes, it's pretty automagic. We've discussed the NAT part, which isn't really inherent to a gateway router but is common and easy. Routing itself is pretty much inherent. In some configurations there's a magic file in /proc that needs to have a '1' poked into it to enable forwarding between interfaces. I'm doggoned if I remember the name of it right now, and I'm not sure it is used in current configurations.

 *tommy_fila wrote:*   

> Or do you need to enable some kernel options? (I remember reading about some kernel option about IP forwarding).

 

There are a bunch of options regarding iptables and forwarding and the like. Best I can tell, they are defaulted to a state that works. I haven't set up a gateway/firewall with any very recent kernels to be sure (I just looked and the gateway here was last restarted 454 days ago.)

 *tommy_fila wrote:*   

> One more thing. Do I need to run a DNS server on my firewall computer? From what I've read, it seems like I need to install one.

 

It isn't required. It is handy if you want to DNS/rDNS your internal machines. This might make some reports and logs look nicer, and occasionally some program might get picky or slow about allowing connections from machines without rDNS. I run BIND on our network for these reasons. BTW, it doesn't have to be on the same machine as the gateway.

If you don't want to run a DNS server, just open outbound port 53 for UDP -and- TCP (an occasional mistake is made in thinking that DNS runs on UDP only, but large responses are sent by TCP) to either your official DNS provider, or just in general.

 *tommy_fila wrote:*   

> And one more. I don't understand the following command. The command is supposed to block all telnet conncections:
> 
> ```
> iptables -A INPUT -s 200.200.200.1 -p tcp --destination-port telnet -j DROP
> ```
> ...

 

That command will drop telnet packets addressed to the machine iptables is running on, originating from IP address 200.200.200.1 only. Any other IP address in the world isn't affected. If you have telnet forwarded to another machine via DNAT, this rule won't apply. If your /etc/services file gets borked, this rule might not match (in other words, I'm not a fan of using the 'telnet' name, but rather blocking by explicit port number.)

Source vs. destination port numbers is probably the most misunderstood part of matching. The well-known port number of a service is the one the server, the machine that is connected -to-, uses. The client machine will use some randomish high-numbered port. So, blocking is nearly always done on destination ports.

A better block rule, version 1, would be:

```
iptables -A INPUT -p tcp --destination-port 22 -j DROP
```

Which will drop all inbound connections to the telnet port.

A better block rule, version 2, would be:

```
iptables -P INPUT DROP

iptables -A INPUT -p tcp --destination-port <whatever_you_want_to_allow> -J ACCEPT

...
```

This establishes the policy (-P) for the INPUT chain as drop. Any packet that is not matched by a specific rule will be thrown out. Then, the following lines establish acceptance for the specific services you wish to allow. This way, if a service is accidentally started on the box, it still is not available to the Internet until you open connections to it explicitly.

Dave

----------

## tommy_fila

I really can't tell you how much you've helped me. Thanks again.

I'm still not 100% clear on the destination and source port deal.

You mentioned that the client side of telnet picks a random high number port. So, when an outside computer sends a telnet packet to my computer, it sends it to a random high port. So how would port 22, on the INPUT chain ever be touched? I don't understand

----------

## DaveArb

 *tommy_fila wrote:*   

> I really can't tell you how much you've helped me. Thanks again.

 

No trouble, it's like a refresher course remembering some of this stuff.  :Wink: 

 *tommy_fila wrote:*   

> You mentioned that the client side of telnet picks a random high number port. So, when an outside computer sends a telnet packet to my computer, it sends it to a random high port. So how would port 22, on the INPUT chain ever be touched? I don't understand

 

I didn't explain well enough. The client and the server each use a port number, and they are different. The source port is the one that the client uses, it's the random high numbered one. The destination port is the one the server listens on, it needs to be the one recognized by the server or nothing (correct) happens.

In every case I can think of off-hand, you match on destination port. This is whether you're blocking (or accepting) inbound requests, or blocking your users from connecting to unwanted services. Want to block all your users from a web site, for example, you block them from connecting to destination port 80 on the unwanted web server. Want to block all users of a particular outside network from connecting to your web site, you still block on destination port 80, this time on an inbound chain.

Dave

----------

## jamapii

I think a few examples would help. Suppose you sit at a computer, directly connected to the internet, not using a router. You surf the web. You connect to port 80 of many webservers. Your external interface (the one connected to the internet) is ppp0.

These iptables rules will match:

```

iptables -A OUTPUT -p tcp -o ppp0 --destination-port 80 -j ACCEPT     # handles the outgoing packets

iptables -A INPUT -p tcp -i ppp0 --source-port 80 -j ACCEPT     # handles the incoming answer packets

```

But today, most use the "stateful matching" feature:

```

for i in INPUT FORWARD OUTPUT; do

  iptables -A $i -m state --state ESTABLISHED,RELATED -j ACCEPT      # accept all established connections

done

# ...

iptables -A OUTPUT -p tcp -o ppp0 --destination-port 80 --syn -j ACCEPT     # accept the initial packet

```

But you possibly don't want to restrict outgoing connections at all, so you would catch all possible TCP connections by dropping the "--destination-port 80" part.

If you are at a computer behind the router, you must do SNAT on the router (using the POSTROUTING chain of the nat table). Then, the INPUT FORWARD OUTPUT chains don't see anything strange, they see packets traveling directly between the internal and the external computer. The packets match in the FORWARD chain:

```

iptables -A FORWARD -p tcp -i ! ppp0 -o ppp0 --destination-port 80 -j ACCEPT     # handles the outgoing packets

iptables -A FORWARD -p tcp -i ppp0 -o ! ppp0 --source-port 80 -j ACCEPT     # handles the incoming answer packets

```

or 

```

iptables -A FORWARD -p tcp -i ! ppp0 -o ppp0 --destination-port 80 --syn -j ACCEPT     # accept the initial packet

```

In my own scripts, I write shell functions to make this easier.

Again, to allow all possible outgoing connections, drop the --destination-port.

If you are running a webserver on the router, it is:

```

iptables -A INPUT -p tcp -i ppp0 --destination-port 80 -j ACCEPT     # handles the incoming packets

iptables -A OUTPUT -p tcp -o ppp0 --source-port 80 -j ACCEPT     # handles the outgoing answer packets

```

or

```

iptables -A INPUT -p tcp -i ppp0 --destination-port 80 --syn -j ACCEPT     # accept the initial packet

```

To disallow the mentioned traffic, use REJECT or DROP instead of ACCEPT. In my own scripts, I mention at least all servers I run and either allow or disallow them for incoming connections. Then, I add a catchall to disallow all possible remaining connections (I call it "close all remaining ports"). I do the same for UDP, I don't trust the "stateful matching" to do the right thing there. And last, the default policy "DROP" kicks in.

To run the server behind the router, use a DNAT rule and allow traffic in the FORWARD chain. I would add the server's IP address in "-s" and "-d" options here.

Warning, don't copy this blindly, it contains typos etc. - I only meant to clarify by example.

----------

## tommy_fila

I'm going to be honest here. Even after the two lengthy explanations, I'm still not exactly sure how things work. To me it seems like the two posts actually say the opposite.

 *Quote:*   

> These iptables rules will match: 
> 
> ```
> iptables -A OUTPUT -p tcp -o ppp0 --destination-port 80 -j ACCEPT     # handles the outgoing packets 
> 
> ...

 

In this case, the chain with "--destination-port" handles outgoing packets.

The other post has the following:

```
iptables -A INPUT -s 200.200.200.1 -p tcp --destination-port telnet -j DROP
```

This rule is supposed to drop incoming packets.

I don't understand. I'll try to set up a simple example.

My computer is directly connected to the internet. I want to drop all incoming telnet traffic. So I add the following rule.

```
iptables -A INPUT -p tcp --destination-port 22 -j DROP
```

I fire up a telnet client, and try to connect to a remote server. The telnet client opens a random, high numbered port on my computer. A request is sent out to the telnet server (I'm assuming that my firewall configuration allows all outbound traffic). The request hits the telnet server on port 22. The server replies. This is the part where I get confused. In order for it to reply, it would use the random high numbered port as the destinaton port, and 22 as its source port. So when the reply hits my firewall it would not have 22 as a destination port. It would have the high numbered port the client is running on.

Do you see where I'm getting confused? Why would the telnet reply have 22 as it's destination port? I see how the initial request has 22 as its destination port, but the incoming reply should not.

Edit:

I think I might have the answer to my problem. We're talking about different things. I'm talking about telnetting to a different computer (and blocking the reply from the telnet server), while you're talking about someone else telnetting into my computer. For incoming request from other people I understand the above mentioned chain. Is that what you meant? 

If this is so, how would I block telnet servers from replying to my requests? Would I have to block all outgoing telnet requests? (This seems to make sense to me.)

We're getting closer and closer! :Very Happy: 

----------

## DaveArb

 *tommy_fila wrote:*   

> I think I might have the answer to my problem. We're talking about different things. I'm talking about telnetting to a different computer (and blocking the reply from the telnet server), while you're talking about someone else telnetting into my computer. For incoming request from other people I understand the above mentioned chain. Is that what you meant? 
> 
> If this is so, how would I block telnet servers from replying to my requests? Would I have to block all outgoing telnet requests? (This seems to make sense to me.)

 

There you've got it. You initiate a connection, using for example port 23456, to a server's port 22. When it responds, it originates on port 22, back to your 23456. If you wanted to allow outbound telnet connections, but throw away responses to them (which would be a pretty odd thing to do), you could:

```
iptables -A OUTPUT -p tcp --destination-port 22 -j ACCEPT

iptables -A INPUT -p tcp --source-port 22 -j DROP
```

Blocking outbound connections to telnet would, of course, make a lot more sense.

Do remember that all these examples accept only the computer actually connected to the Internet. INPUT and OUTPUT aren't used in a firewall role by packet moving from LAN to Internet.

Dave

----------

## tommy_fila

Great. Finally I understand. Thank you again for helping me get through this.

On an unrelated note, would you recommend regulating outgoing traffic? I'm the only one who uses the computer, so I'm just wondering if there are security risks associated with allowing all outgoing traffic (e.g. I connect to a a malicious service which then responds and the response is not caught by the firewall because I allow established, related traffic to come in).

----------

## DaveArb

I don't regulate outbound, except in very unusual circumstances. I'm responsible for a corporate network, and trying to outguess what's going to happen next is more work than I'm able to put in. And yet, everything ends up working fine. I see a lot of talk onforum about security measures that are way more than I'd ever be able to try. It's probably fun to do as an exercise, but my experience is, it isn't needed.

I connect to a a malicious service which then responds and the response is not caught by the firewall because I allow established, related traffic to come in

So, let's say you connect to port 80 of an evil web site. It then tries to connect back on port 31337. Unless your computer is already infected with Back Orifice, nothing happens because there's nothing to answer that connect request. Something has to listen on a port before the port can receive a connection. You're in more danger by evil.web trying to exploit security issues in your browser, something a packet filter isn't going to be able to help with.

Dave

----------

## jamapii

 *tommy_fila wrote:*   

> On an unrelated note, would you recommend regulating outgoing traffic?

 

If you have possibly virus-infested computers behind the router, it may make sense. This actually happened in 2003 on the network I was at the time.

----------

## tommy_fila

 *DaveArb wrote:*   

> So, let's say you connect to port 80 of an evil web site. It then tries to connect back on port 31337. Unless your computer is already infected with Back Orifice, nothing happens because there's nothing to answer that connect request. Something has to listen on a port before the port can receive a connection. You're in more danger by evil.web trying to exploit security issues in your browser, something a packet filter isn't going to be able to help with.

 

The questions continue... :Very Happy: 

I connect to port 80 of an evil website. In order to connect in the first place, I have to open a port on my computer. So the web server replies back to the port I opened. Everything correct so far? Wouldn't the web server be able to send something through the open port? Or does the port know if the incoming traffic is actually not a response from the webserver, but a malicious file.

----------

## sschlueter

 *tommy_fila wrote:*   

> 
> 
> You said that MASQUERADE assigns the IP of the default route. But how does it know which outgoing route and incoming packet will eventually take?
> 
> 

 

I hope I won't contribute to the confusion but let me try to clarify that when you execute the following iptables command

```
iptables -t nat -A POSTROUTING -j MASQUERADE
```

where no outgoing interface is specified, netfilter does not automatically change the source IP to the IP of the interface of the default route. Instead it changes the source IP to that of the interface that the routed packet is about to go out, which can be any interface since no specific one was specified. 

The page How Packets Traverse The Filters of the Linux 2.4 Packet Filtering HOWTO maybe useful in order to understand what the mentioned iptables command does.

This diagram is even more detailed.

(And let me add that an iptables command like above is probably not what most people want. Most people probably want to do masquerading only if the packet is about to leave the public interface.)

----------

## sschlueter

 *tommy_fila wrote:*   

> 
> 
> I connect to port 80 of an evil website. In order to connect in the first place, I have to open a port on my computer. So the web server replies back to the port I opened. Everything correct so far? Wouldn't the web server be able to send something through the open port? Or does the port know if the incoming traffic is actually not a response from the webserver, but a malicious file.

 

Netfilter does not even know anything about http, let alone anything about the content that is being transfered. It mainly operates at the ip, icmp, tcp and udp levels. It does not look into the bodies of the tcp/udp packets.(*)

That means that malicious servers can exploit vulnerable clients and malicious clients can exploit vulnerable servers without netfilter ever noticing anything about it.

There are some proxy servers that can validate the protocol they handle. But even such proxy servers cannot tell whether the content that is being transfered is malicious or not.

But one could attach a virus scanner to the proxy server so that the data is scanned for viruses before it is delivered.

One could also attach something to the proxy (or to the server to be protected) that scans the data for known exploit code fingerprints or more general anomalies.. Such a thing is usually called intrusion detection system. An IDS can work in a passive mode by only logging suspicious traffic, but it can also work in an active mode where it blocks suspicious traffic. The later class is also categorized as "intrusion prevention systems".

An IDS can also work in a standalone mode by intercepting network traffic at a lower level. 

A popular example of an IDS attached to a servive is ModSecurity for Apache. A popular example of a IDS that intercepts network traffic at a lower level is Snort.

Edit: Patching vulnerable services/systems is more important than updating exploit code fingerprints!

(*) Yes I know that there are NAT helper modules for nat-unfriendly protocols like ftp that have to look into and change the bodies of the packets but they don't implement the full protocol specification and are not suitable for protocol validation.

----------

## DaveArb

 *tommy_fila wrote:*   

> I connect to port 80 of an evil website. In order to connect in the first place, I have to open a port on my computer. So the web server replies back to the port I opened. Everything correct so far?

 

Reasonably correct, although the word I've bolded in your text is an unusual use. Generally, if someone says they have opened a port, they mean that the port is allowed to be connected -to-. In this case, the port is not open to be connected to by any incoming request, it is a port that is in use for a current connection.

 *tommy_fila wrote:*   

> Wouldn't the web server be able to send something through the open port? Or does the port know if the incoming traffic is actually not a response from the webserver, but a malicious file.

 

Yes, in fact if it cannot respond to that port, your web browsing is going to consist purely of timeout messages.  :Wink: 

Example:

You request to connect to a web server, forums.gentoo.org. You do this with the Firefox browser. It picks a port (ex: 15241), creates a connection request to forums.gentoo.org's port 80 (technically, the OS may do some things listed under "it", it makes little difference for this example. ) Once connected, you effectively have a direct connection between Firefox on your computer and Apache (probably? I haven't bothered to check) on one of the forum computers. What the forum computer sends, barring vulnerabilities, is going to be received by Firefox. If you watch the vulnerabilities list and update accordingly (or just update), you're as safe as reasonable, IMHO. Going any further requires setting up things like virus-checking proxies like sschlueter mentioned, which in my experience is quite expensive in processing power if nothing else.

Dave

----------

## tommy_fila

Great responses just keep coming in. Thanks to both DaveArb and sschlueter for giving me light in the vast darkness of computer networking.

Since programs like Snort and anti-virus software seem like an overkill, I'm going to be happy with my iptables setup. It's nice to finally understand what all the chains actually accomplish.

Thanks again!

----------

