> > Can you perhaps describe exactly what you're trying to get working, and > > perhaps there's a better network architecture (ie safer & easier to > > impliment) to do what you want. You can e-mail me directly if this is > > sensitive info you don't want on-list... > > We have a client that insists on exposing a critical internal server to > the Internet ;< > > They want their internal application and file server to also host their > Exchange server and -- god help us all -- possibly IIS, as well ;<
<sigh> > I didn't feel so bad when considering the server's masq'd address can > only be accessed from the Internet insofar as we port forward to it. > Actually, they asked us to put this server on the dmz ;> Hmm...so you're not looking to port-forward anymore? That should make things much easier. If it's sitting on the DMZ, access is configured like any other system to the DMZ. WARNING: The internal nets are masqueraded to the DMZ 'net. This isn't a problem for most things, but it will coufuse MS Networking to no end (assuming you can get your MS systems talking across a router in the first place...no small accomplishmet). > So, for the Internet to find this server via DNS on the customer's > domain, how else might we accomplish this? This part is the same regardless of what you setup. Just make an A record for the hostname that points to it's IP. The IP will either be the systems "real" IP on the DMZ, the IP being port-forwarded to the system, or the IP being static-NAT'ed to the system. > What do you think? Sorry to hear about your net connection problems :< Reading between the lines, I think you're going to have to setup a static-NAT from a DMZ IP to the internal system. Without going to a 2.4 kernel and iptables, where you can specify the source IP for outbound masquerading, there's no simple solution for getting a port-forwarded system running with a DMZ public IP. The two other options I can think of are: A 'two-step' process, where a DMZ IP is port-forwarded to the internal server, with all return packets routed out to the DMZ net, where a box masqerades them to look like their source IP is the DMZ ip. This is ugly, and requires lots of advanced routing configuration. Just port-forward the service from the public IP of the firewall (the near end IP of the T1 link). The reverse masqerade rules will do the right thing, and everything should work fine. There are also hooks in place to do this already, so no custom forwarding and static-NAT rules, making the system easier to maintain. The public IP of the server system will fall outside the DMZ range, but unless your customer has their own IP range (unlikely, since you mentioned it's a /26), they're using 'borrowed' IP's from the ISP anyway...might as well make effective use of ALL the IP's you've been given, and save yourself some trouble in the process... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) _______________________________________________ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
