Basic Routing

To act as a router, where a box has two NIC's, and is connecting a LAN with 192.168.0.0/24 to the Internet - is SNAT required? Or can this be accomplished without NAT?

Daniel

192.168.x.x is private space IP. You cannot route private space IP's on the internet: you need NAT to give internet access to your clients (or a proxy if you only need protocols for which proxies are available). This can be done with SNAT, MASQUARADE (some people need this instead of SNAT) and I've read somewhere it can also be done using "ip" but I'm not familiar doing that.

Grts,
Rob

Thanx. I'm still not sure of the vocabulary with which to phrase my "true" question - so I'll try it with more words (although I think you've already answered me - I'm just looking for confirmation).

Given:
1. A linux box "router" that has ip-fowarding enabled, and no restrictions via iptables.
2. This box has a routing table that lists two or more networks

If another host on network 'A', lists the box "router" as its default gateway, and tries to contact network 'B' through the router - will the router automagically pass along the packets? Or this simply doesn't work, because of a basic networking concept I haven't grasped - and NAT is the technique to accomplish this?

I guess part of my difficulty lies in a lack of experience configuring non-linux routers. Behind-the-scenes, as it were, do all/most routers use NAT to accomplish the goal of linking networks? It always seemed to me NAT was a 'kludge' that was somehow unnecessary when "more expensive?" equipment was involved.

Daniel

If network A is your LAN and network B is "the internet", the packet might be routed onto the internet but even if it reaches the destination IP (which it may not because of the configuration of other routers and firewalls), you'll never get a reply packet because a reply packet for a private IP will most likely be routed to their own DMZ or LAN. So, you can't setup a full connection like this.
However, if you were using public IP's (not in 192.168.x.x, etc) on your LAN then you could just route the packet.

Yes, one way or another, some form of NAT is the technique to be used. As Grant explained you can also use ebtables. I'm writing about NAT using iptables.

Normally you'd only encounter NAT situations when connecting a host/network to the internet and you're using private space IP's on the network.

No, NAT is a necessary kludge because not every computer that must be connected to the internet can have a public IP: there just aren't enough IP's to do that. That's why home networks and corporate networks (well, those I know of) mostly use private IP's on their LAN and use NAT (and/or a proxy) to get to the internet.

NAT is not/should not be necessary between networks if you have something like this:

-------------  -------  -------------
| Network A |--| RTR |--| Network B |
-------------  -------  -------------

Here, the router knows the route to each network and can just route packets to each other. No need for NAT here.

Maybe you find this tutorial useful in understanding things. The history says it's not updated since 2006, but the information still holds for at least the large part.
http://iptables-tutorial.frozentux.net/iptables-tutorial.html

Grts,
Rob

Thanks - I'll be reading through it.

Daniel

Note: Because of the length of my reply I'm going to split this reply in to two parts. The first (this) part will be on routing in general and the second (next) part will be on NATing.

Eh... What Daniel said is true, but your (mis)understandings are not quite right. You are actually trying to understand some lower level functionality by observing some higher level functionality that causes you to misconstrue the underlying functionality. It's sort of like trying to grab something under water while looking at it from out of the water if you don't know that water changes the angle you need to look at.

Yes and no.

NATing, or Network Address Translation, is a special technique to alter (possibly hide) either the source and / or destination address the traffic is coming from and / or going to. (I say "and / or" because it is possible to NAT both the source and destination if need be, which is called double NATing and even more complex.)

First let's say that a /Default Gateway/ is nothing more than a catch all route to be used when there are no other better routes to use. In essence, use the /Default Gateway/ as the last resort to fall back on if nothing else works.

Now, routes in general are just a way of saying that if you want to go to this particular destination, you need to go by way of here to get to your ultimate destination.

Now, let's consider your scenario above:

+---+         +--------+         +---+
| 1 +---(A)---+ Router +---(B)---+ 2 |
+---+         +--------+         +---+

We configure host 1 on network A to use the Router as its default gateway and similarly we configure host 2 to use the Router as its default gateway.

Now, host 1 can ping any thing on network A directly because it is local and with in it's (sub)net(work). However if host 1 wants to ping any thing out side of network A it will have to find a route to get to the destination. Knowing that host 1 only has one route, the /Default Gateway/ all traffic not going to the local (sub)net(work) will go to the /Default Gateway/. So, host 1 sends its traffic to the /Default Gateway/ of Router. Now it is up to Router to handle the traffic.

Router now has traffic from host 1 that it needs to deliver to host 2. So Router looks in its routing tables and finds that host 2 is in network B and that it is directly attached to network B and as such is able to send the traffic directly to host 2 in network B.

When host 2 receives the traffic and is ready to reply to host 1 it goes through a similar process as host 1 to send the reply traffic. Likewise Router handles the traffic in reverse.

Thus hosts 1 and 2 are able to talk to each other by way of Router.

When hosts 1 and 2 are talking to each other, they both know that that traffic originated from the other because of the source IP address in the packets they received.

Now, let's elaborate the network connection a bit more to further explain routing.

: :
| |

+---+         +--+--+           +--+--+         +---+
| 1 +---(A)---+ Bob +===(XXX)===+ Tom +---(B)---+ 2 |
+---+         +-----+           +-----+         +---+

Here we have two friends that have their home network, each with their own internet connection. However, considering that they are friends, they have some sort of connection between their homes to allow them to use each others network resources. This connection could be a VPN across the internet, or it could be a wireless network connection, or if they are close enough to each other, it could be an ethernet connection between their routers.

In this scenario, both hosts 1 and 2 use their local routers (Bob and Tom respectively) as their /Default Gateway/.

Now let's re-consider host 1 pinging host 2 in this new network. Like before, when host 1 wants to pint host 2 it finds that host 2 is not with in its network and thus must have a route to get there. Like before host 1 will send the traffic to its /Default Gateway/ (in this case) "Bob". Bob will then have to find a route to get to host 2. This time Bob has a default gateway of the internet connection (going out the top) -AND- Bob has a route to network B by way of "Tom". So Bob will send the packet on to Tom. Tom will then as you would expect see that host 2 is directly connected to network B and send the packet on to host 2.

Similarly when host 2 replies, it's traffic will go to it's /Default Gateway/ (in this case) "Tom". Tom will then find that it has a route to network A by way of "Bob" and as such will send traffic to network A to Bob. Bob will then see that the traffic is to a system on network A and send the traffic accordingly.

In both of the above scenarios hosts 1 and 2 used the /Default Gateway/ to send their traffic and did not need a routing table with any thing more than their /Default Gateway/. The following scenario is a bit different.

: :

   |                                             |
+--+--+         +---+           +---+         +--+--+
| Bob +---(A)---+ 1 |           | 2 +---(B)---+ Tom |
+-----+    |    +---+           +---+    |    +-----+
           |                             |
           |    +---+           +---+    |
           +----+ 7 +===(XXX)===+ 8 +----+
                +---+           +---+

Here things are more than a bit different. In this configuration, we still have Bob's and Tom's houses, except this time the connection between the two networks is not through their /Default Gateway/ but rather the respective systems 7 and 8.

In this scenario, when host 1 wants to ping host 2, host 1 will again consult its routing table. However this time there will have to be an entry that says that network B is accessible by host 7 in addition to the /Default Gateway/ entry. Thus when host 1 sends its packet it will find that it needs to send the packet to host 7 rather than the /Default Gateway/ of "Bob". Host 7 will then receive the packet and find that it needs to send the packet on to host 8. Host 8 will then find that it can send the packet directly to host 2 on the local network B.

Similarly host 2 will have to have a route in its routing table so that it knows that it reaches network A by way of host 8. Thus host 2 sends its reply packet to host 8 which sends the packet on to host 7 which then sends the packet directly to host 1.

Quickly, *NO*, routers in general do *NOT* use NAT. Look at my next email for an explanation as to what NAT is for.

Grant. . . .

Note: Because of the length of my reply I'm going to split this reply in to two parts. The first (previous) part will be on routing in general and the second (this) part will be on NATing.

No, routers in general do *NOT* use NAT.

In all the above scenarios, all systems in the path see the real source and destination IPs of host 1 and host 2. NAT is a way to change source and or destination address for some reason.

To understand NATing you need to understand that there are some IP address ranges that are *NOT* suppose to be seen on the global internet and thus have to be changed (translated) in to something that is more acceptable on the global internet. Similar is also done with in complex networks, especially when tyeing multiple businesses together for some reason.

Usually the reason is that most networks use RFC 1918 Addresses reserved for Private Internets, which are *NOT* suppose to be on the open globally routable internet. In fact, RFC 1918 addresses are typically filtered out as soon as they hit the internet, or at least the ISP /should/ filter them and not pass them.

Despite the fact that routing can handle these addresses with out any problem there are agreed upon rules / guidelines that have been agreed to that impose that these (RFC 1918) addresses are not to be in use on the internet.

Thus to allow systems that are on these RFC 1918 private IP addresses to reach the internet, their source address IP /Network Address/ has to be changed or /Translated/, thus we have /Network Address Translation/, or NAT for short.

Let's consider this very simple scenario where I have my home network and a router and a simple ADSL internet connection.

:
|

+--+--+         +----+
| RTR +---(A)---+ Me |
+-----+         +----+

Let's suppose I have a source IP of 192.168.1.2 and I want to search the web using Google, so my computer talks to 74.125.95.99 (one of the IPs that www.google.com resolves to).

My packet with a source IP address of 192.168.1.2 and a destination address of 74.125.95.99 leaves my computer and goes to my router (because of my /Default Gateway/).

My router then sees that it has to send the packet to its /Default Gateway/, my ISP's router. However my router knows that it has to /Translate/ the source IP of the packet to something that is internet friendly. So, my router alters the source IP of the packet to its own external globally routable IP address A.B.C.D, which is not an RFC 1918 private IP address. So now the packet with a source IP address of A.B.C.D and a destination address of 74.125.95.99 leaves my router and goes to my ISP's router.

My ISP's router chooses one of its upstream connections and sends the packet with a source IP address of A.B.C.D and a destination address of 74.125.95.99 to one of its upstream router. My ISP's upstream router will then choose a route and send the packet with a source IP address of A.B.C.D and a destination address of 74.125.95.99 on down the line until it reaches the destination 74.125.95.99.

Google will then process my packet and reply back to me. Thus Google sends a packet with a source ip of 74.125.95.99 and a destination address of A.B.C.D back through the internet to my ISP's ISP, and my ISP, and to my router.

My router will then see the packet with a source ip of 74.125.95.99 and a destination address of A.B.C.D and realize that it is actually a reply packet that needs to be un/Translated/. So my router will change the destination IP address of A.B.C.D back to my real IP address of 192.168.1.2 and send it on to my computer.

My computer sees the packet with a source IP address of 74.125.95.99 and a destination address of 192.168.1.2 and realizes that it is the reply to the packet I sent moments earlier and hands it up through the network stack to my web browser.

As you can see the only place that /Network Address Translation/ (a.k.a. NAT) took place is where my private network connected to the global internet.

I had to use NAT because there are rules on the global internet that say that the IP addresses that I chose to use are not allowed on the global internet. Recalling the previous diagram(s) where Bob and Tom connected their networks, they /could/ have /chosen/ to use NAT if they did not want to have to set up routes between each other.

Another use of NATing is to allow two completely independent networks to inter operate. Below is an example of double NATing that I like to refer to as a "Customer Interface Router", typically used when a business is subscribing to a service and / or support form a larger entity that supports multiple individual customers all with varying and possibly conflicting network configurations. An example of which might be a big wholesale book distributor or local / state / national government agency that is offering some sort of service to the small entity that has the Customer Interface Router (a.k.a. CIR). Typically in such scenarios both entities only want to allow connections for the services needed with out having to re-configure their network to support connections to far flung parts of the others network, or in the case of the larger provider deal with potential overlapping IP address spaces of smaller networks.

:
|

+--+--+         +---+
| RTR +---(A)---+ T |
+-----+    |    +---+
           |
           |    +-----+
           +----+ CIR += = =
                +-----+

So in this case, the Customer send a packet with a source IP of T and a destination IP address of CIR from their terminal T to the Customer Interface Router CIR.

The Customer Interface Router will then /Translate/ the source IP address to be it's own IP of the interface facing the providers network as well as /Translating/ the destination IP to be what ever the provider wants with in their own network. Ultimately the Customer Interface Router sends a packet with a source IP of <IP of CIR's provider interface> and a destination IP address of <something with in the providers network>.

The packet will then pass through the providers network to the real end point equipment (AS/400, mainframe, video surveillance system, what ever) and be processed and a reply packet will be sent.

The reply packet with a source IP of <something with in the providers network> and a destination IP address of <IP of CIR's provider interface>.

The Customer Interface Router will receive the packet with a source IP of <something with in the providers network> and a destination IP address of <IP of CIR's provider interface> and /Translate/ the source IP address of CIR on the customers network as well as /Translating/ the destination IP to be T. Ultimately the Customer Interface Router sends a packet with a source IP address of CIR and a destination IP address of CIR back to the terminal T.

Thus through the use of double NAT on the Customer Interface Router we have allowed two completely separate and independent network structures to communicate and inter operate with out any regard as to what the others network structure is.

In short, NATing is used when you need to cross two conceptually unique networks that do not necessarily play well with each other.

Grant. . . .

I'm going to read these two mails a few times - I sincerely appreciate the thorough answer - hopefully it'll penetrate my skull soon enough.

I do understand that the private address ranges were not to be directly exposed to the Internet. I guess what I was looking for was for a router to perform the following:

1.  Host 'A' realizes Host 'B' is not on its network
2.  Host 'A' contacts Router 'C' and asks it to get the information out and bring back the response.
3.  Router 'C', via whatever magical method (DNS/hosts/etc.) figures out the router responsible for Host 'B's presence on the Internet.
4.  Router 'C' contacts Router 'D', sends along the information, and tells Router 'D' to send any responses to ROUTER C, not Host A
5.  D, goes to B, comes back to D, and back to C
6.  Router C, on receiving a response from D, remembers that Host 'A' was waiting for this information and sends it on.

In essence, I believe I'm correct in this summary - however the tool used by Router C for "remembering" that Host A asked for the information, and that responses from Router D should come back to Router C, is NAT?

So does this mean that ANY connection of a private address space to the Internet MUST be performed via NAT?

Daniel

*nod* You are welcome. It's my way of giving back to the community that has given me so much. :)

If you have any more questions, please reply, either to the mailing list or directly to me off list, which ever you prefer, and I'll do my best to answer.

*nod*

This is what the net mask and subnets are all about in the IP stack and has nothing to do with a router. (Other than the fact the router has its own IP stack and (sub)net mask(s) too.)

(As long as you are not talking about any form of proxying...)

This is what routes are all about, with the /Default Gateway/ route being special in such as it is the one used when no other routes match.

Eh. Now you are sounding more and more like a proxy. Routers only pass IP packets based on routes. Any DNS operation is the responsibility of the application that generated the packet that is now being routed by the router.

It's not so much that routers ""contact each other as it is that each router hands off the IP packet to the next router for it to route to the next and the next ... and you get the idea. There is not really a request that something be done.

You could be talking about IP packets flowing through networks or proxy requests flowing from clients to the proxy and ultimately to the destination server and back in reverse.

This is is probably what you are thinking NAT does, which in some / most ways is correct. However, the same can be said about a proxy.

Eh, not really.

I'm going to go out on a limb here and think that you are thinking of a network like this:

+---+
| B |
+-+-+

:

:

+-+-+       +---+
| C +---+---+ A |
+---+   |   +---+
        |
        |   +---+
        +---+ D |
            +---+

I believe this is the sequence of events you are trying to make happen:

- Client A is trying to contact the server B by way of router C.
- Router C intercepts the request and hands it off to system D.
- System D then initiates the request to B by way of router C (and
many other intermediary routers).
(C does not intercept the request because it is from system D.)
- Server B replies back to D by way of (many other intermediary
routers and) router C.
- System D then replies back to router C.
- Router C then replies back to client A.

Is this close to what you are wanting to happen? (Let me know before I explain how to make this happen.)

Yes. In the scenario above (presuming that my picture above matches what you have) Router C does NAT to convert the internal IP addresses used on the internal LAN to that of the internet side of Router C so that the packets will cross the internet. Refer to the "Simple Scenario" in my previous reply about NATing.

Grant. . . .

*dumbly nodding* Ok.

*dumbly nodding - slight eye glazing* Um....ok.

*significant eye glazing - jaw slack* Um...er...maybe...
Rephrase - "Router C checks it's list of routes, figures out it's clueless with regard to the route for Router D, and passes the buck to Router C's default gateway"

*Excitedly* - That's it! That's the part we need to talk about! Router "hands off the IP packet to the next router to the next to the next" -

Router C has a route table -
192.168.0.0/24 dev eth0
2.3.4.5 dev eth1
default gateway 2.3.4.4

Router 2.3.4.4 (premise equipment from mysterious ISP) mysterious routing table

Router 5.4.3.1 (premise equipment from other ISP)
more mysterious routing table

Router D has a route table -
10.0.0.0/8 dev eth0
5.4.3.2 dev eth1
default gateway 5.4.3.1

Does the above communication involve NAT? No "hosts" or private networks involved - all public IP's between them (unless of course the packets traverse private IP ranges within the ISPs' networks before coming back out.

*Sheepishly* Assume for sake of argument I'm expressing myself poorly - no proxies involved in this discussion. That would make it too simple.

*Assertively* No proxy.

Um...no. Too complicated.

A==>C<==Internet==>D<===B

Two offices on opposite sides of the world linked via Internet.

So the world's most expensive super-duper whatchamacallit (fill in the blank here with router, firewall, bridge, modem, magic cauldron), placed between giant corporate's network (using private address space) and the Internet - will perform NAT? Somewhere somehow NAT (in particular, source NAT for outbound access from the private and destination NAT to provide services to Internet) must be performed?

Daniel

Now that we're discussing that - let's change gears and talk about it differently.

No Internet - but still private networks. So Router C has a route for the network 'A' 192.168.0.0/24 and route to reach router 'D'. Router 'D' knows about network 'B' 192.168.1.0 and router 'C'. D and C talk to each other, just because, on their own network of 172.16.0.0/16.

Is any NAT required for this conversation? In particular - do Linux routers require SNAT lines for this? Or just routing tables?

Daniel

(Note: I'll read and reply to your previous message later this evening when I have more time.)

Ok...

*nod*

Correct.

+---+         +---+         +---+         +---+
| A +---(x)---+ C +---(y)---+ D +---(z)---+ B |
+---+         +---+         +---+         +---+

Thus we have three networks, x, y, and z. x 192.168.0/24
y 172.16.0/16
z 192.168.1/24

A will have one IP address of x.A.
C will have two IP addresses of x.C and y.C. D will have two IP addresses of y.D and z.D. B will have one IP address of z.B.

A will have the following routes:
x is directly attached
y is reachable by way of x.C
z is reachable by way of x.C

C will have the following routes:
x is directly attached
y is directly attached
z is reachable by way of y.D

D will have the following routes:
x is reachable by way of y.C
y is directly attached
z is directly attached

B will have the following routes:
x is reachable by way of z.D
y is reachable by way of z.D
z id directly attached

In this scenario, none of the systems really have to have a default gateway at all. However all of the systems will have to have one or two routes set up. You /could/ use default gateways if you wanted to. A and B would probably use C and D (respectively) as their defaults. However it is really up to you to decide what you want to be the defaults for C and D.

No. NAT is not required.

Remember that NAT is a way to change addresses so that connections appear to be to and / or from a different address than they actually are. You could do the above configuration with NAT, but it will actually make things more difficult.

If you were to use NAT, you would have to decide a few things. What address do you want A and B to talk to. Is A going to talk to z.B on a remote network or is it going to talk to x.C on its local network (similarly is B going to talk to x.A or z.D). This determines if you will have to have any routing set up at all.

If you do not have routing set up, and choose to use NAT you will have to do a fair amount of NATing on all systems. I.e. C will have to forward any traffic that comes in to x.C on to y.D. Likewise D will have to forward any traffic that come sin to y.D on to z.B. Similarly in reverse, D will have to forward any traffic that comes in to x.D on to y.C. As you would expect C will have to forward any thing that come sin to y.C to x.A.

+---+         +---+         +---+         +---+
| A +---(x)---+ C +---(y)---+ D +---(z)---+ B |
+---+         +---+         +---+         +---+
              |------------->                     x.C -> y.D
                            |------------->       y.D -> z.B
                  <-------------|                 z.D -> y.C
    <-------------|                               y.C -> x.A

As you can see this is fairly complex and could easily and quickly get WAY out of hand. Where as with traditional routing things are much simpler.

+---+         +---+         +---+         +---+
| A +---(x)---+ C +---(y)---+ D +---(z)---+ B |
+---+         +---+         +---+         +---+
    <--------->   <--------->   <--------->

As an added benefit of routing, any system can talk to any other system on any network (presuming nothing is put in place to stop it). Where as with NATing, the only thing that A will be able to talk to remotely is B it self. If you want A or B to talk to other systems on the respective remote networks, you will have to set up even more NATing.

So, no, you do not /have/ to have NAT. But you /can/ use NAT if you have some specific reason for wanting to do it. (Refer to my Customer Interface Router description in a previous email.)

Grant. . . .

I guess here's a Linux specific question - as opposed to the more general IP/routing discussion we've been having.

Given a Linux box with multiple networks on one or more interfaces (192.168.0.1 on eth0, 192.168.5.1 on eth0:0, 172.26.0.1 on eth1, etc.) - and just adding a "1" to /proc/sys/net/ip_forward - will this magic box be able to forward packets between the networks without further configuration? Or will this require NAT statements from iptables (and no, this is NOT an opportunity to tell me about ipchains/ebtables/other-Linux-networking-specialty-program-kernel-interface-I-didn't-mention)?

Ok fine - if you can recommend a tool to make this easier - I'd be delighted to hear about it. Right now my configuration tool is firehol.

Daniel

Grant is doing too good a job... :-)

Since these IP's are all private you do NOT need NAT.
Do NOT use NAT in this situation unless you tried plain routing and for some fancy reason, strange situation or requirement you find out you might actually need NAT here. But in your case I don't think you will come to that conclusion unless there's something you haven't told us yet (again: I don't think so).
Just enable and allow all forwarding, add the routes you need and your magic box will shine like a magic lantern. :^)

So, like:

iptables -P FORWARD ACCEPT
iptables -F FORWARD
echo 1 > /proc/sys/net/ipv4/ip_forward
route add -net [...etc...]

No, this is not secure, but that's not what we're talking about here. This way, your box will effectively be a router. No fancy filtering, NAT-ing, whatever.

No, it will NOT.

Have a look at http://www.fwbuilder.org/.
I'm not using it, I'm not endorsing it, don't know anything of how it builds it's ruleset, etc. It just looks nice if you're coming from MS ISA and you might actually find it handy.

Grts,
Rob

Thank you. :)

Agreed.

Agreed.

Um, mostly agreed.

The part that I want to point out is that the routes that you add will not be on the Linux router, but rather the systems on the networks.

Let's look at this example.

         :
       +-+-+         +---+
       | C +---(z)---+ 3 |
       +---+    |    +---+
                |
  :             |             :
+-+-+         +-+-+         +-+-+
| A +---(x)---+ R +---(y)---+ B |
+---+    |    +---+    |    +---+
         |             |
+---+    |             |    +---+
| 1 +----+             +----+ 2 |
+---+                       +---+

Let's say that this is three independent networks (x, y, and z) with their own internet connections (A, B, and C) that you are trying to tie together with the Linux router (R). Each host (1, 2, and 3) will use their own internet router (A, B, and C respectively) as their default gateway.

One of two things will happen when host 1 wants to talk to host 3.
1) Host 1 will not have a route to network z that host 3 is on, so
host 1 will send the traffic to its default gateway A which would have to have a route to send the traffic to router R.
2) Host 1 will have a route to network z by way of router R and send
traffic directly to router R which will then send the traffic to host 3.

Correct. However that is not to say that filtering and / or NATing can't be added if you want to, because they can when you are ready / want to do something like that.

With out having ever used (but have heard of) FWBuilder my self I can't comment on it. However considering how Daniel is asking how things work and appears to be trying to learn, I don't think jumping directly in to some sort of application that hides this knowledge from him is that good of an idea.

Grant. . . .

You're welcome.. Heheh.

You mean you don't agree to the shining part?

Yes, well, in the basic example I was refering to (A <-> C <-> D <-> B), routers C and D already know the routes to the networks they're connected to (and I assume that hosts in A and B have a (default) route to C and D resp) so they don't need extra routes. But they do need forwarding set to ACCEPT and allowed. In a more complex situation things are different.

No, I don't think so too. I already pointed him to Oskars iptables tutorial which I think still mostly holds and I hope he'll read (and understand) it. Writing your own script is still more flexible and you learn more about what you're doing and dealing with.

Grts,
Rob

Oh, no, the shine part is fine. I was more thinking about where the routes were.

Um, very close but not /quite/.

+---+         +---+         +---+         +---+
| A +---(x)---+ C +---(y)---+ D +---(z)---+ B |
+---+         +---+         +---+         +---+

A knows about network x.
C knows about networks x and y. D knows about networks y and z. B knows about network z.

C does /not/ know about network z. D does /not/ know about network x.

So either C and D have to use each other ad default gateways or they have to have routes to networks x and z. (That's the "not quite" part.)

We have already covered the IP forwarding in another email. As far as the firewalling is concerned, you are correct. However I believe Daniel said that there was no firewalling (yet).

Agreed. I think both are likely good ways to learn about firewalling, specifically IPTables. Seeing as how this discussion is about routing...

Grant. . . .

Yes you're correct.. I should stop assuming things that I already figured out in my head but don't write down when replying. (Actually, a "few" emails ago I wrote an email that describes the exact same as the above -including art- but I discarded it when I saw your answer which was even more complete.)

Nope, there was no word about firewalling, just NAT and routing.

We started with NAT, which is something that netfilter can do and what the tutorial also describes, and routing. I was hoping that Daniel would see why he didn't need NAT by reading it.

Daniel, this is getting lengthy and I think everything that needed to be said has been said about NAT and routing. I hope things are (more) clear now.

Grts,
Rob

'k

The simple act of enabling IP forwarding (/proc/sys/net/ipv4/ip_forward) will allow your Linux box to forward or route traffic between said networks (as long as there is no IPTables / etc. to block it).

The problem that you will run in to is whether or not systems on said networks will know how to get to systems on the other said networks. Will they have a route (default or other wise) that tells them to use the Linux router, or will you have to establish routes manually.

Just because you can get a packet somewhere does not mean that you will be able to get the reply.

You need to enable IP forwarding (like above) and make sure that each system knows that it can reach the other subnets via the Linux router.

So if all the systems are using the Linux router as the /Default Gateway/ then things are fine. If they are not, you need to establish a route. You can either establish routes on all systems, or put one on the /Default Gateway/ of each subnet. Putting the route on the /Default Gateway/ in each subnet will cause systems to send traffic to their /Default Gateway/ (because the packet is not to their local subnet) which will then send it to the router which will then send it to the appropriate system. (This is somewhat sub-optimal, but it will work reliably.)

In the end it really comes down to systems /knowing how/ to reach the other systems, which is what routing, specifically routes do.

Grant. . . .

Daniel,
lets cut this right back to the basics and answer your original question:

1) NAT is needed to change private IPs (192.168.0.0/16) to Internet
IPs. It does not in itself send packets anywhere.

2) everything else just uses straight routing.

puddles of NAT around the rest of the internet are invisible and
completely ignored by your systems.

NAT is different to routing. All it does is change the private IPs back-n-forth. plain old routing is still needed to get the private packets to the NAT place and then the public packets out across the Internet.

Lets follow that sequence:

A creates a packet(A->D) and 'routes' it to C.
C takes the packet(A->D). NATs it packet(C->D). then routes it to B B takes the packet(C->D). NATs it packet(B->D). then routes it to D. D takes the packet(B->D).

D replies with packet(D->B).
B takes the packet(D->B) and NATs it packet(D->C). then routes it to C. C takes the packet(D->C) and NATs it packet(D->A). then routes it to A. A gets reply packet(D->A)

Far too complicated than it needs to be yes?
So NAT only happens when one of the IPs needs to be changed (ie from a private IP to a 'public' one, or from one private to another private)

If you really have different 192.168.*.0/24 networks at A and B. AND also control the network C-D. You should be able to get away without NAT. By simply setting the route table of C to route B network through D.
And D route table to route network A through C.

AYJ

(Now that I have time *AND* internet, DSL was out at the house last night... *GR!!!*)

Ok as in "Dough!" or ok as in "???"?

Remember that a system will decide where to hand the packet(s) off to (which router) by looking through its own routing table sequentially. The first route that is found that matches the destination that you are trying to reach is the route that is used to send the packet(s).

The /Default Gateway/ is a special route in such as it is the last resort at the end of the routing table. So if no other routes (if there are any) match then the /Default Gateway/ route will match any destination, thus sending any packet(s) that did not match any other routes out through the /Default Gateway/. Another way to think of the /Default Gateway/ is as a 'Catch All' route.

(Are you having fun yet?)

Much closer. Try this on for size. "Router C checks it's list of routes, figures out it's clueless with regards to the route to host B, and passes the buck to Router C's default gateway." (Remember that Router C knows how to reach Router D because they share the common connection.)

Ok. I think it's time for a quick segway in to how a packet(s) are passed around ethernet networks.

Remember that IP addresses /cross/ network boundaries and that MAC addresses are /confined/ with in network boundaries. So we talk IP addresses across multiple different networks. When two hosts with in the same network talk they really talk MAC address to MAC address.

Let's take your fairly simple diagram below.

+---+         +---+         +---+         +---+
| A +---(x)---+ C +---(y)---+ D +---(z)---+ B |
+---+         +---+         +---+         +---+

This is what the sequence of events will be for host A to send an IP packet to host B.

- A sends an ethernet frame with a source MAC address of x.A and a
destination MAC address of x.C, containing an IP packet with a source IP address of x.A and a destination IP address of z.B.
- C sends an ethernet frame with a source MAC address of y.C and a
destination MAC address of y.D, containing an IP packet with a source IP address of x.A and a destination IP address of z.B.
- D sends an ethernet frame with a source MAC address of z.D and a
destination MAC address of z.B, containing an IP packet with a source IP address of x.A and a destination IP address of z.B.

Notice how each pair of locally connected hosts (on the same network) talk to each other with their own MAC addresses to work together to pass the IP packet containing the actual message that is to be sent.

Ok. You just indicated that routers C and D are not directly connected to each other on the same ethernet network but rather are in different subnets, likely using different ISPs. This complicates things a bit.

Possibly, at least for general internet access. There will be NAT between the private LAN IP address space (192.168.0/24 and 10/8) and the internet.

That being said, if you establish a VPN between Router C and Router D across the internet (which I'm going to assume will be done), you can have LAN to LAN traffic with out NATing in between them. This can happen because the VPN will encapsulate the traffic leaving the 192.168.0/24 network going to the 10/8 network. This encapsulation raps the packets and uses the globally routable IP address of Routers C and D as the source and destination IPs for the /VPN/ traffic. When the VPN traffic reaches Router D, it will decapsulate it and send it out to the LAN on its end.

So, yes NAT is used to send normal traffic to the internet and no NAT is not used (VPN encapsulation is) to send LAN to LAN traffic.

Ok. I just had to double check, you understand why. :)

*nod*

(See my email from yesterday afternoon.)

*nod*

This means that you will most likely be dealing with VPNs

Correct. The word you are looking for is usually a router that does firewalling, or sometimes knows as a firewalling router. (Remember that firewalls really /filter/ traffic while routers /route/ traffic, sometimes altering it along the way.)

Even IBM and Microsoft (presuming they are using private class IP address space) are either running NATing routers between their internal corporate networks. (As an alternative they could be doing proxying, but it is most likely that they are using NAT.)

Grant. . . .

*Head bouncing on desk* You just had to do it. You just HAD to throw something else in, didn't you? Ok - no VPN during these discussions!!! That's next thread.

Once again - I'm using language that's too ambiguous. I actually probably inferred that - but I didn't intend to. The INTENT was to illustrate a clumsy, inefficient, amateurish connection between Internet connected sites using non-VPN capable home-office consumer-grade firewall routers - the under $20 kind.

You're assuming a level of capability and courtesy for the sysadmin I am not - nor am I talking about higher-level protocols. So from Los Angeles, they'll have to type in the public IP address of the New York router to reach that office.

*Exasperated shrug* Now that I've typed that - it really doesn't make too much sense. All right - fine. I guess a VPN was needed somewhere. But darn it - the VPN operates at a higher level - somewhere along the line the VPN server/router needs to translate the virtual IP's to something the rest of the world understands - and that means NAT!

Again with the proxy (what's the matter with you? Trying to give me a complete answer that accounts for the exceptions? Geez....)

I think my confusion stems from my own introduction to IP, which was via WindozeNT 4.0. Somewhere along the line NAT was referred to in some documentation as a "poor-man's solution" to doing "proper" routing - and that concept has carried forward with me to where I keep thinking NAT is somehow an inferior solution to the "proper" way of doing things. If the only "proper" (read: other) way of connecting LAN's to the Internet is by assigning public IP's to workstations (and of course purchasing/reserving/controlling such IP's) - then I can drop the inferiority complex I've held with regard to NAT.

Daniel L. Miller, VP - Engineering, SET
AM Fire & Electronic Services, Inc. [AMFES]
[email protected] 702-312-5276

Perhaps the problem is that the good people on this list know just too much about the finer points of routing and the caveats and wrinkles that you occasionally need to avoid special purpose problems.

For the most part, though, it's actually quite simple. And I know that
some of the things I will say are wrong in some cases and I would hope that someone will explain to me where they're wrong and maybe we'll all be enlightened.

Anyway, routing first. For a given machine it's pretty
straightforward. You have an IP address to which you want to send a
packet (routing is per-packet, not per-connection). Type "route -n"
and run your finger down the list of routes from top to bottom. Use
the "genmask" to mask off the bits in the IP address that you have (that is, "and" it -- eg an IP address of 192.168.2.5 and a genmask of 255.255.255.0 will give you 192.168.2.5). If the result is the same as the destination column then you send the packet to the gateway and device indicated.

There are two special cases in the routing table: a gateway of 0.0.0.0 means "this machine" which means, basically, that you're on the same LAN
as the destination IP. A destination of "0.0.0.0" (and similar mask)
is usually called the default route: if you take the conjunction ("and") of any IP address and 0.0.0.0 you'll get 0.0.0.0 and so any address not previously matched will go to the indicated gateway.

You may notice that the routing table is sorted by the number of zeroed bits in the genmask column: 255.255.255.0 comes before 255.255.240.0 which comes before 255.255.0.0 and so 0.0.0.0 is always last. That's why you can run your finger down the routing table from top to bottom to find where a packet will go and that, of course, is exactly what the kernel does.

Most machines only have a single NIC and are connected to a single network and have a default route so the routing table has only two
entries: the local LAN and the default route. Machines with more than
one network device will have more routing entries -- you need at least two network devices (real or virtual) to have any need for more complex routing.

I slipped in "(real or virtual)" there for a reason. When you set up a VPN connection from home to the office then it is exactly as though you have put an extra network card in your machine and run a very long cable
to the office. You now have two network devices, one connected to the
local LAN and one connected to the office network and a routing table to
match. Actually, there's one small difference between a virtual
private network and a real private network (apart from miles of cat-5 cable): there is a route with a genmask of 255.255.255.255 that is used to route traffic to the machine at the other end of the vpn link. Apart from that, think of a VPN has just another NIC that happens to be called (usually) tun0 instead of eth1.

Right. NAT.

NAT is completely different to routing. In routing a packet is sent
to a gateway machine completely unmodified (apart from some housekeeping
things that you don't need to worry about right now). NAT is different
because it modified the IP packets. For most people, NAT modifies the
source IP address and port -- that means that when you're at home surfing the net behind your Netgear firewall/router/ADSL modem then the source IP address isn't 192.168.0.2, it's whatever IP address your ISP gave you. Your partner/children/cat surfing the net on a machine whose local IP address is 192.168.0.3 will also have the IP source address of their IP packets rewritten to that same IP address that your ISP gave you -- you will appear to be using the same computer as far as any web server is concerned.

Some organisations, like the one I work for, use network 10 for internal IP addresses but any external connections appear to originate from a
public IP address in exactly the same way. There are a couple of
thousand people on this site all sharing one external IP address, all, apparently crowded round one screen sharing the same keyboard.

An organisation I used to work for had a class A subnet all of its own, network 15 and I had a machine whose address was 15.145.139.57 (well, I might have, I don't remember exactly what it was). In principle that machine was able to connect to the external network without any sort of NAT and, equally, machines from the outside world could connect to it. In practice, of course, there were (and presumably still are) firewalls that prevented such traffic. Access to the Big Bad Internet was (and maybe still is) through a proxy: this is different to NAT: routing happens at the IP packet level; NAT happens at the TCP (or UDP) connect level; proxying happens at the application protocol level. You point Firefox at an HTTP proxy that can either return a page it has prepared earlier or run the HTTP request on your behalf. It's a lot more complicated than that but that's because it's happening at the protocol level and so involves all kinds of icky details that TCP and IP neither know nor care about.

And finally, just to round things off, there's a class of proxy called a transparent proxy. As far as firefox (or anything else) can tell it's connecting to the outside world directly, but in practice connections are redirected to a proxy by some messing by iptables or some similar
cleverness in a Cisco router. Transparent proxies are quite cool.

Does that help or has it left you even more confused?

jch

*nod* (guilty) *nod*

I don't see any thing wrong with what you have said. I might have used different wording, but we are two different humans. :)

<snip>

I do have a quick comment to add about the routing table though. The routing table is ordered with the most specific match first (what you were getting at by the number of zeros). So when the routing table is searched, the first route to be found, the most specific one, is the proper one. The reason you might have a more specific route and a less specific route is if you have a fast high latency satellite connection to and a slow low latency dial up or leased line connection back to corporate. You would want the bulk of (non interactive) traffic to go through the faster high latency connection for most things but still have smaller interactive (think terminal type) traffic go over the slower lower latency dial up / leased line. To be able to do this you would put the destination server equipment for the interactive traffic be in a smaller ""special part of the larger address range. Then you tell the router that it has access to the smaller range over the dial up and the rest of the address range across the satellite.

The more specific routes can be used to override less specific routes.

I'm guessing that it left Daniel with more to think about and to formulate more questions. Which is in and of it self a good thing as that is the normal process of learning. :)

Grant. . . .

Once upon a time I asked this list some routing questions. I've almost got it - I swear I've ALMOST got it. One more little push and I think I'm there.

Given the specific architecture:
Windows Workstation 192.168.5.100, default gateway 192.168.5.1
Linux Gateway/Router/VPN node 192.168.7.2, 192.168.5.1, 192.168.0.90, default gateway 192.168.7.1 DSL Modem 192.168.7.1

Linux Server/Router/VPN server/Virtual Server 192.168.0.71, 192.168.56.1, default gateway 192.168.0.1 Virtual Machine 192.168.56.20, default gateway 192.168.56.1

What is the "easiest" way of "achieving routing" between the Windows Workstation and the Virtual Machine? Is this an instance where NAT would make administration simpler instead of "pure" routing? The cumbersome-but-working method I have employed at the moment includes;

add 192.168.56.0/24 via 192.168.0.71 route to Workstation add 192.168.56.0/24 via 192.168.0.71 route to Linux Gateway add 192.168.5.0/24 via 192.168.0.90 route to Linux Server

I almost understand the need for the 192.168.5.0/24 entry on the Linux Server side - because otherwise the router doesn't know how to reply, and the same goes for the 192.168.56.0/24 entry on the Gateway side - otherwise the Gateway doesn't know how to reach that subnet in the first place. But, if the Gateway is defined as the default for the Workstation, why is a routing entry required for the Workstation?

Daniel

graph {
	windows -- lxgateway;
	lxgateway -- dsl;
	lxgateway -- vserver;
	vserser -- vm;
};

NAT wouldn't fix anything.

That won't work because
- 192.168.0.71/32 is a nonexisting route on Workstation (at least I suppose that this is the case currently)
- 56.0/24 via 0.71 is redundant because you've got a default route through lxgateway anyway
- You don't really need the .0.0/24.

Do:

lxgateway:
- addr: 192.168.5.1/24 dev ethwork
- addr: 192.168.5.1/32 dev ethvserver
- route: 192.168.5.0/24 dev ethwork (automatic)
- route: 192.168.56.1/32 dev ethvserver
- route: 192.168.56.0/24 via 192.168.56.1
Workstation:
- addr: 192.168.5.X/24 dev eth0
- route: default via 192.168.5.1
vserver:
- addr: 192.168.56.1/24 dev ethvms
- addr: 192.168.56.1/32 dev ethmain
- route: 192.168.56.0/24 dev ethvms (automatic)
- route: 192.168.5.1/32 dev ethmain
- route: default via 192.168.5.1
vms:
- addr: 192.168.56.X/24 dev eth0
- route: default via 192.168.56.1

It is in fact not required.

*chuckle*

Here's a *nudge* to help you get there. ;-)

It sounds like your Windows workstation (192.168.5.100) uses your Linux router (192.168.5.1) as its default gateway and that your Linux router (192.168.5.1, 192.168.7.2 and 192.168.0.90) uses your DSL modem (192.168.7.1) as its default router.

(Windows)---(Linux)---(DSL)---(Internet)

Correct?

It sounds like your virtual machine (192.168.56.20) uses your Linux router (192.168.56.1) as its default gateway and that your Linux router (192.168.56.1, 192.168.0.7) uses <something> (192.168.0.1) as its default gateway.

(VM)---(Linux)---(<something>)---(Internet)

Correct?

I'm not sure what the <something> is that has the IP address 192.168.0.1.

Further, I can't tell if the 192.168.0.x networks on the two Linux routers is the same network (or VPN) or not. - For the sake of conversation (and demonstration) I'm going to continue as if they are.

If the above two system share the 192.168.0.x network, we end up with a topology that might be depicted like this:

               +---(DSL)---(Internet)
               |
(Windows)---(Linux)---+
                      |
                      +---(<something>)---(Internet)
                      |
     (VM)---(Linux)---+

Or via IP:

                                      +---(192.168.7.1)---(0.0.0.0/0)
                                      |
(192.168.5.100)---(192.168.5.1, 192.168.7.2, 192.168.0.90)---+
                                                             |

+---(192.168.0.1)---(0.0.0.0/0)
                                                             |
            (192.168.56.20)---(192.168.56.1, 192.168.0.71)---+

(I'm not sure if that's going to work wrap properly or not.)

I'm going to take a stab and presume that the what you are calling "Linux Gateway/Router/VPN node" is a VPN client that is connected to what you are calling "Linux Server/Router/VPN server/Virtual Server" and that it is being bridged in to the 192.168.0/24 network.

Correct?

For the sake of conversation (and demonstration) I'm going to continue as if I am correct.

Add a route to the "Linux Gateway/Router/VPN node" so that it knows that it can get to the 192.168.56/24 network via the "Linux Server/Router/VPN server/Virtual Server" (192.168.0.71). And vice versa, add a route to the "Linux Server/Router/VPN server/Virtual Server" so that it knows that it can get to the 192.168.5/24 network via the "Linux Gateway/Router/VPN node" (192.168.0.90).

No. NAT is seldom a better solution than "pure" routing.

The workstation doesn't need to explicitly have a route because it's default gateway has one.

That's all you should need to do.

I am curious, why do you consider this to be "cumbersome"?

No, the routing is not required on the Windows workstation or the virtual machine because their respective default gateways know the routes for them.

You did find your answer, but hopefully this will help you understand why the answer you found works.

It might not be obvious, and seem to complicate things, but I don't think I would bridge the VPN client in to the VPN server's network. I would rather set up a small network between the VPN client and the VPN server and set up routes on the VPN server to what is on either end. (In your case, it would be a matter of changing the next hop gateway / router that the "Linux Server/Router/VPN server/Virtual Server" used.) Doing this will help prevent spurious traffic from the 192.168.0/24 network from going through the VPN to the "Linux Gateway/Router/VPN node". Further, you will have the capability for more security on the "Linux Server/Router/VPN server/Virtual Server" in such as you can use IPTables to firewall (based on network) the VPN traffic. Also, your (completely) "Linux Gateway/Router/VPN node" is dependent on the configuration of the 192.168.0/24 network, where as if it was routed, you would simply need a route referencing the "Linux Server/Router/VPN server/Virtual Server", with out caring what is on the other side of the "Linux Server/Router/VPN server/Virtual Server", there by separating the networks. As it is (using bridging) you can't change things (addresses / network config / etc.) on the 192.168.0/24 network with out re-configuring the "Linux Gateway/Router/VPN node".

Setting up the additional routed VPN may seem like extra work, but it allows for abstraction / isolation / simplification of things for changes later. - Comparing things to the internet, think what would happen if you had to re-configure your internet connection every time your ISP made changes (additions / removal) to their back haul providers. Routing allows you to simply rely on your ISP's upstream (gateway) IP, and let them worry about what is beyond that. ;-)

Grant. . . .

Ok... I only brought VPN up because you will want that to tie two offices across the internet together. But if you want to pretend for the sake of discussion that you have a really long ethernet cable (or a legacy WAN using T1s which use basic routing) I'm ok with that.

Ok.

Be aware that the simple facts that you are using private IP addresses and that you want to take them across the internet, where they can not go, means that you will have to use NAT. Remember that the internet only caries globally routable IP addresses.

Eh. I'm not so much assuming that as I'm trying to lead a horse to water that is safe to drink that will also solve the problems that you unknowingly are going to have. If you would prefer to discuss things and then get a "That will not work because of..." and then have to re-discuss things, we can do that. :) Just let me know how you want the conversation to go. In short you are asking questions and providing some details of your needs (which keep admittedly by you changing) and I am trying to answer them and get you to understand along the way.

No. VPN's don't /NAT/. VPN's /encapsulate/. Think of a VPN as taking a letter you wrote to someone and putting it inside of another bigger envelope and sending it to someone who opens the outer envelope and takes the smaller envelope out and sends it to the proper department on their end.

+-----------+    +-------------------+    +----------+
| IP packet | -> | VPN packet        | -> | Internet |
+-----------+    |     +-----------+ |    +----------+
                 |     | IP packet | |
                 |     +-----------+ |
                 +-------------------+

+----------+    +-------------------+    +-----------+
| Internet | -> | VPN packet        | -> | IP packet |
+----------+    |     +-----------+ |    +-----------+
                |     | IP packet | |
                |     +-----------+ |
                +-------------------+

The (IP packet) has host 1 as its source and host 2 as its destination and does not change any where in transit.
The [VPN packet ...] has the one VPN gateway as its source and the other VPN gateway as its destination. These packets have the globally routable IP addresses in them.

Sorry. :P

Up until recently what you have presented could be solved by basic routing and / or NATing -OR- by proxying. Seeing as how I started off indicating that either could be used I was just continuing the concept in discussion. I'll drop it and let you pick it up later if you want to inquire about it. :)

Ugh. Forgive me if I believe just from the statement about where you learned about routing (not even taking in to consideration this discussion) that you were not taught hardly any thing (if even that) about routing. It has been my experience that /most/ information that Microsoft has provided on routing was the smallest amount that they could to even thing about stepping up and playing with the big boys. It is my opinion that Microsoft network was and still is to a large part NetBIOS based, even if it is on top of TCP/IP. Even that, the TCP/IP is simply a happenstance as a carrier protocol that could just as easily been IPX or DECNet Phase IV.

There was a time that (in my opinion) /most/ Windows technicians would have thought that the only two ways to get a Windows machine to access the internet was with live globally routable IPs assigned to all the workstations using ""proper routing -OR- to use NAT. However there was / is this other seldom used technology that I'm no longer mentioning. ;)

At this point I don't really see any questions, just comments on things, so I'm going to let you lead the conversation by asking some other questions, which I'll respond to. :)

Grant. . . .

You have to have some form of NAT for the aforementioned reason. However it is possible to do this on a layer 2 device via EBTables / IPTables with bridged netfilter traffic enabled.

It is my (mis)understanding that Cisco PIX /Firewalls/ (All /PIX/es are firewalls NOT routers) do the ""routing with the layer 2 NATing and thus appearing as routers.

In essence from L2 you watch for any traffic coming from the L3 IP address space in question and then NAT the L3 addresses with (on L2) to be the actual L3 address you want to appear as. The same thing happens in reverse and you tend to have what appears to be a L3 ""router, but in actuality it's purely an L2 device pretending to be / doing the function of an L3 router.

(Though at this point it is debatable what it actually is. I choose to say it's an L2 device b/c it operates on L2 and looks to higher layers in the stack where as normal L3 routers operate on L3 and /may/ look down if at all.)

IPTables uses what is considered /stateful/ NAT. Remember when IPTables introduced connection tracking and the state match extension in 2.4 years ago? Previously IPChains did not have such state. The (older ?) installs of the IP (ip) command could do /stateless/ NAT. I say older because I'm not sure that the stateless NAT provided by IP exists any more. ... (checking) ... According to the IP man page, stateless NAT is no longer supported: "Warning: Route NAT is no longer supported in Linux 2.6."

Grant. . . .

Hello,

Ebtables, are you sure ? AFAIK ebtables does only layer 2 MAC address translation, not IP address translation. Don't you mean bridge-nf aka bridge-netfilter instead of ebtables ?

It's far from being that simple. Doing stateful IP address translation at layer 2 requires other operations such as fragment reassembly because stateful NAT operates at the datagram level, not at the packet level, and rerouting and ARP lookup when the destination IP and MAC addresses change. IMO these are definitely not layer 2 operations.

Ipchains did not have a state match extension, but it had some connection tracking for its NAT features (masquerading and port forwarding).

Actually the IP_ROUTE_NAT option enabling the old stateless NAT aka "fast NAT" or "route NAT" support in the kernel has been removed since kernel 2.6.9 only. But a new stateless NAT was added in kernel 2.6.24. See option NET_ACT_NAT in the "QoS and/or fair queueing" menu (yeah, I guess the location may seem misleading). I have not dug into it, but I think it can be set up with the "tc" tool from the iproute package. It requires iproute2-2.6.24-rc7 at least.

Hi.

It's been too long so I can not say for 100% sure, but it may have been with bridge-nf. However, even if you are using bridge-netfilter and using IPTables to operate on the layer 2 bridged traffic, this is still done on layer 2, not layer 3. I know it's starting to get ambiguous, but... I.e. I could have one subnet split in half and be NATing the traffic as it passes through, say .3 can automagically become .4.

You have some good points about where NAT operates. With out going back and reviewing my notes and old config, I believe it /is/ possible to do, just very much of a kludge and difficult to do.

Could be that NAT had some connection tracking. I did not really mess with IPChains that much, more IPTables, so I don't know for sure.

*nod*

I may have to dig it out and look at it some time. I'm glad to know that they brought something back that offered the stateless NAT functionality.

Grant. . . .