Anselm, Thank you for you analysis.
> bridge...router I mispoke. Yes, the LTSP server functions as a router where we have different subnets. I do favor turning off NAT if possible in order to reduce the boundary processes where we might "lose" bits of our traffic and become confused about what's happening. While the firewall/content-filter will presently affect only two labs, there is a good chance it will be moved to behind the the external gateway router in a year; at that time it will affect more VIP's so I hope to determine methods and test things now. > apps running on LTSP server including Mozilla... It sounds almost as though the LTSP server does NOT do NAT, but rather directly creates packets w/its own IP address and assigns various high ports to the sessions as needed. ?? In which case there is nothing needing change this time. Good. <G> I guess the answer to my hypothetical question about addressing client sessions from outside the LTSP "subnet" (in a different response message) would be "no, can't do it, not ever". The IP address which the client machine gets at boot time is used _only_ for the GUI traffic, correct? Rufus --- Anselm Martin Hoffmeister <[EMAIL PROTECTED]> wrote: > Am Mittwoch, den 24.05.2006, 19:57 -0700 schrieb > rufus laggren: > > I have too many NAT conversersion happening behind > the > > external router; at the moment the LTSP server is > > planned to live behind a NAT'g router and a NAT'g > > firewall. I want to stop the firewall NAT and the > LTSP > > NAT and allow the external router to provide NAT > for > > all the different subnets. The LTSP server would > in > > affect provide a bridge for it's clients I guess. > The > > subnets won't overlap, the LTSP can still provide > > DHCP. > > In most cases, the LTSP will be a router, not a > bridge. > To get that concept clear: > > If two ethernet networks that are not directly > connected but through a > computer do have the same IP subnet setting, and all > computers can talk > to each other as if they were on the same cable, > then you have a bridge. > > If two computers have different subnet addresses, > you have to setup a > route: > > PC A (10.0.0.11) > VA > Router (10.0.0.1 / 192.168.0.1) > VA > PC B (192.168.0.11) > > Then, you would tell PC A that all addresses > 192.168.0.0/24 live behind > the router "10.0.0.1". In the moment PC A wants to > send an IP packet to > PC B, the ethernet frame is not sent to the PC B, > but to the router. > This router reads in the packet that it needs to > forward to PC B, which > then happens. > > This routing can be enabled/disabled with a single > switch > in /proc/sys/net/ipv4/ip_forward - that should > contain "1", else the > kernel will not do the packet forwarding. > > Now let us see what happens if "Router" also does > NAT. Imagine PC A to > be the "inside" of the NATted network and PC B be > outside. If you enable > nat'ting, the packet from A to B will be modified > while running through > the router (in the case above, routing, only the > ethernet framework > would be changed, but the IP packet should be, > checksum/TTL apart, stay > unchanged). The router will modify the "source > address" to be the > router's IP address, so that PC B will not need a > route telling it where > PC A lives, but it just needs to know the router. > > In case you have a multi-layer-setup, you can either > do multiple > nat'ting (as you seem to do right now), or you > should tell every router > about every IP subnet in your network, and then turn > off nat'ting except > on the "outermost" (directly attached to the > DSL-Modem, or whatever) > device. Especially that device will need to know > router to all IP > subnets, else those devices could reach the router > but not vice-versa, > meaning the internet access would be broken. > > As for LTSP setups, the thin clients if living on a > separate IP subnet > do not need internet access, being able to reach the > LTSP server is > absolutely sufficient (provided you do not do local > apps). All programs, > including mozilla, run on the LTSP server and start > their connections > from there, so if a user logged on to that LTSP > server on the local > screen can in theory surf the web, so will the > terminal users. > > In your case, I would turn LTSP NAT off, as it is > not needed (except for > local_apps). I would also turn firewall NAT off. > Then your external > router and the firewall will need to have routes to > all subnets. > >From the client side, setting a default route to > the firewall machine > (as it most probably is setup currently) should > further be sufficient. > > HTH > > Anselm > > > In this I am assuming that the applications a > client > > is running (from the server) actually issue their > > network requests from the client - ie, the client > is > > running it's own network connection exactly as if > it > > were a fat PC, even though it is using files and > > possibly the display system from the server. > Another > > way to say this - application traffic goes through > the > > clients NIC in exactly the same form as if it were > a > > fat PC, so even though the server is providing > some > > processing and storage, the client machine appears > as > > a "real" host on the net behind the LTSP server if > you > > watched it with a sniffer on the client subnet > (except > > for the extra ports for display and such). The > LTSP > > server normally acts as a NAT router for its > clients - > > this function appears to me to be completely > > independent of its server functions. > > > > If my theory is right, how do I implement it? > Config > > files? Or is there a setup screen. I did not set > up > > the LTSP system and in fact know nothing about it > > except the barest concepts. I am trying to get a > > handle on what is possible here. I have just > finished > > building a simple firewall/content-filter and need > to > > decide the best way to place the LTSP clients > behind > > it. Others familiar with the LTSP server will do > the > > work, but I need some idea what I can ask for. > > > > Thanks, Rufus > > > ------------------------------------------------------- > All the advantages of Linux Managed Hosting--Without > the Cost and Risk! > Fully trained technicians. The highest number of Red > Hat certifications in > the hosting industry. Fanatical Support. Click to > learn more > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 > _____________________________________________________________________ > Ltsp-discuss mailing list. To un-subscribe, or > change prefs, goto: > > https://lists.sourceforge.net/lists/listinfo/ltsp-discuss > For additional LTSP help, try #ltsp channel on > irc.freenode.net > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ------------------------------------------------------- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 _____________________________________________________________________ Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto: https://lists.sourceforge.net/lists/listinfo/ltsp-discuss For additional LTSP help, try #ltsp channel on irc.freenode.net
