Re: RE: Ip Forwarding

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thanks for the reply, I'd like to say that you're right I do need






To read up more about IP routing.  Did you know these protocols






Come in layers?(just a little joke.) Anyway I thought I would explain






My situation in case any one else needs to do what I did. Frankly I






Wouldn’t find this situation obscure at all as long as you're using






A vital windows system behind a dedicated firewall box.






The key was not netfilter at all, though netfilter is amazing and






Should be used for ip filtering on the box.  The key was bridge-utils.






Bridge-utils makes your box into essentially a transparent switching






device.  A link to an article I found on the home page's site made it






so easy to set up that I don't know why I didn’t find out about it






sooner.  






Anyway as long as you set the default gateway of the bridge box to the 






original gateway that your computers were using, and the internal 






network gateway to the virtual device's IP, then youre ok. If you do use 






bridge make sure you upgrade to at least the 2.4.20 kernel and run the 






latest bridge patch, even if its for an earlier kernel(2.4.19 etc) itll 






work.  It's about the most transparent setup without having to buy more 






hardware.






Will Olbrys






for any Win2k Active Directory boxes, the client computers will have to 






rejoin the domain.  I know it has something to do with IP routing but I 






cant explain other than to say that it works.






----- Original Message -----






From: Bjorn Ruberg <bjorn@ruberg.no>






Date: Saturday, February 22, 2003 10:43 pm






Subject: RE: Ip Forwarding






> On Sat, 2003-02-22 at 15:57, William Olbrys wrote:






> > Was this too complicated? Heh that's why I wrote such a generic






> > questions






> > 






> > -----Original Message-----






> > From: netfilter-admin@lists.netfilter.org






> > [mailto:netfilter-admin@lists.netfilter.org] On Behalf Of 






> William Olbrys






> > Sent: Friday, February 21, 2003 7:48 PM






> > To: netfilter@lists.netfilter.org






> > Subject: RE: Ip Forwarding






> > 






> > Well I want to put a windows 2000 domain controller behind my






> > iptables-enabled redhat 8 box. The domain controller had a 






> static ip






> > before it went behind the firewall and for Active Directory to work






> > correctly it HAS to stay that way. I spent days and days trying






> > otherwise but windows is far too stubborn. AD plus legacy 






> support for






> > WINS makes nat translation a living hell. So I simply set up all my






> > rules as default accept and let it fly, hoping that the 






> forwarding would






> > take care of itself. Essentially it did! I could perform simple 






> function> like connecting to the internet but I couldn't do more 






> important> functions like cruise the windows network or have 






> things join/leave/see






> > the domain behind this iptables enabled box.  I thought it had 






> something> to do with routers not seeing the right ip address as 






> it leaves the






> > iptables box or the routers not being able to find its way back 






> to this






> > box behind the firewall.






> > 






> > It struck that while I wrote this complicated email I may have 






> come up






> > with a solution. Since the static IP of the win2k box is the 






> same and






> > only the gateway has changed, then the data it sends will be 






> legitimate> concerning it's IP address(not an internal IP). Could 






> I create an alias






> > at the outbound NIC level for the win2k's IP address and SNAT 






> packets> leaving the outbound NIC that originated from the win2k box?






> 






> Generic questions get generic answers, and that is not what you need.






> 






> Your questions are not complicated (and the email is definitely not),






> just obscure.






> 






> To cut to the chase:






> 






> You do not say anything about what kind of network you use behind your






> Linux firewall.






> 






> If we assume you use a private network (192.168.*.*, 172.16.*.*,






> 10.*.*.* or similar) of course nothing on the outside will be able to






> connect to your Windows server - simply because they don't know they






> need to connect to it through your Linux server. This is a routing






> issue. A significant fact about NATed networks is that there are 






> no way






> anything on the outside will know that given resources are behind the






> NATing firewall.






> 






> If you are still using an IP dedicated to your Windows server but on






> another IP network, consider it pure luck that anything works at all.






> 






> If you want to get serious answers from this list, you need to 






> distinctbetween what matters (e.g. your IP network and your 






> routing tables) and






> what does not matter at all (e.g. how many days you tried beating 






> senseinto Microsoft products). Provide a network diagram 






> explaining your






> configuration and any problems related to it. Trying to parse your






> message, however, makes me think that you need to read up on IP 






> routingbefore you try anything more complicated.






> 






> And, by the way, please read the netfilter documentation. It's 






> availableon http://www.netfilter.org/documentation/.






> 






> Bjørn






> 






> 






> 






> 






> 






> 






> E2-I: The presence of this footer indicates the message has been 






> scanned for viruses by the WebShield e500.






> 






> 






> 






> 






 E2-O: The presence of this footer indicates the message has been scanned for viruses by the WebShield e500.





[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux