My organization is using Windows 2003/Exchange 2003.
The domain is MYOWN.COM. All mail in and out is handled through our Exchange 2003 server.
We are going to join a secure network called SECUREWAN.COM.
SECUREWAN.COM already has other organizations joining it like HEROWN.COM and HISOWN.COM.
SECUREWAN.COM has their own DC/DNS/Exchange 2003.
SECUREWAN.COM runs on a 10.10.x.x subnet and each organization has a dedicated line to it.
This is what we're trying to get happen...
When users in MYOWN.COM tries to email anyone that is part of the SECUREWAN.COM networks like HEROWN.COM, it will get routed through the SECUREWAN.COM network... and not through the Internet.
The kick is this... we only want email that will be sent to the organizations part of SECUREWAN.COM to go through their dedicated line. Any other email we send from MYOWN.COM... say to SOMEONE@GOOGLE.COM will be routed through our other Internet connection.
We COULD manually set DNS entries to every organization part of SECUREWAN.COM to go through the dedication line, but that is a very dirty solution.
SECUREWAN.COM is purely routing the email... the organizations should never be able to see the other organizations directory service.
Our firewall has the capability to route SMTP traffic based on FROM domain/address.
Optimally, if the SECUREWAN.COM link is down, outgoing messages could be queued. Perhaps an SMTP relay inside the network?
SECUREWAN.COM has a DNS server. Could we possibly leverage this in some way?
A detailed answer is welcome for a DNS dummy :)
Simple diagram: http : //img124.imageshack.us/my.
[ Remove Spaces From Link ]
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Save solutions to your questions, answers you’ve discovered through searching plus helpful articles in your personal knowledgebase for easy future access.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.
Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
In the SMTP virtual server's properties -> Delivery -> Advanced -> configure, enter SECUREWAN.COM's DNS server first, then a regular DNS server.
and if SECUREWAN respond with a 10.10.x.x address, your firewall or gateway should already know how to go directly to HISOWN.COM or HEROWN.COM without hitting the internet first.
if routes for 10.10.x.x do not exist yet, then it's just a matter of adding them into your gateway.
so 2 things can happen...
1. SECUREWAN.COM's dns is not available, your exchange moves on to the next
DNS to resolve.
2. SECUREWAN.COM's dns is available, but the domain name being looked up does not exist, your exchange will also move to the next DNS to resolve.
in both cases, you will most likely receive the publicly availlable version of the MX records (assuming HISOWN.COM is properly and publicly registered to the outside world)... at which time, your exchange server will just forward the mail to that public IP address. This is where your router can still "modify" what route it takes.
one more quick comment... I see this alot in Multiple Dwelling Units where many small businesses in a building shares the same set of infrastructure... so if SECUREWAN.COM is in the same building as all the other domains, and they are all technically sharing the same firewall and/or internet access... then you shouldn't even care about how mail is routed, as all the traffic will stay local to the building and never leave your internet circuit.
hope i make sense
You could also force hisown.com to use itself for DNS, and in your DNS setup you could add the securewan domain name and all the associated records, and MX records, then add the forwarders. That way if securewan's dns isn't available, it rolls to itself to use it's own local DNS records to find securewan, then it could roll to the internet DNS Servers.
Make sense?
Hmmmm this works yet we are looking for minimal impact. So...
1. That is, should there be any more organizations that join SECUREWAN, we don't need to modify anything on our end (hence somehow relying on the SECUREWAN DNS)
2. ** Mail that goes to any of the organizations within the SECUREWAN can NEVER be routed across the internet. I should have made this more clear and is my error. If for some reason SECUREWAN is down, mail would optimally be queued to be sent rather than going through their publically routable way.
While it doesn't HAVE to be a DNS type solution, it just seems to be the most simple if it's actually possible. Hope this clears up a bit more... we're probably on the right track but I'm too dense to fully realize for clarity, point #2.
That's a tough thing to do with out a) Managing your DNS, or b) sending all mail through secure WAN.
What about just hosting your OWN DNS Server in one location, then you have ONE DNS Server to manage. Then have all your mail servers use that to route mail?
I will have to try this today, but couldn't you create an SMTP Connector in exchange that routes all e-mail for securewan.com through that connector which is a fwd'er to the securewan Exchange, and then have all other e-mail go through a second smtp connector.
Then as you add more nodes, you just add more servers to the SMTP Connector?
One more key...
We have our own T1. Mail NOT destined for orgs in the SECUREWAN should ALWAYS go through there and their line. All other mail should NEVER go through that line but rather go through our T1. As before, SECUREWAN orgs will never fallback to T1 internet. Its SECUREWAN or nothing (queued?).
The for me I think the best thing and easiest thing to do would then have the securewan server be your front end server an all mail goes through it.
That way when that connection is down all mail is queued. That is your simplist solution from my knowledge level.
From my standpoint is it appears that a list needs to be made on exactly what is needed and what priority is what. It seems as if the list i have seen from there you can't do everything, but if there is a must have then work with that.
See what I'm getting at?
My apologies for fractionally adding concerns, but they only come up as I dig into this further.
Again, it is imperative that any org that is part of the SECUREWAN now or future get mail through that route. Although you may be correct in saying adding more sites to the connector, it brings up accountability (executives are fickle people). If we forget to add them or add them incorrectly, mail to those orgs will be sent through the internet which is now told prohibited. So that's why I was reliant on the SECUREWAN DNS as it is the only thing that will dynamically update the orgs I presume. Also why I think we can leverage the fact that the orgs in there will all have private non-routeable addresses on that DNS. The solution may stem with a general configuration of the router/firewall as well.
Hopefully I've clarified the scenario sufficiently in all the comments.
Again, thank you ALL for attending!
AaronIT, yes, having them as a front-end is simple. The only problem with that is we absolutely do NOT want any mail other than those to the SECUREWAN orgs to pass through them. They should not ever touch non-SECUREWAN related email.
You see, IT is simple. It's the business and operations that hold us down. Valiant effort, Aaron!
LOL it definately is.
Let me try the multiple SMTP Gateway's and see what I can do on that front. It may be possible, I have just never tried it :)
The other thing I thought of, is I will check with my router, I believe I can create a rule in my router to forward any traffic to a domain through a specific connection in my Load Balancing, I'm sure you could do the same by creating a special SMTP Proxy for anything going to SecureWAN to go out this connection (Your Secure Wan Connection) and anything else out over the internet.
Give me a bit and I will try that and see what I come up with.
Thanks AaronIT and ENCOSE!
So to recap...
----------------
SITUATION:
- Multiple organizations are part of SECUREWAN (not in same building)
- Each org including us have routable domains.
- Each org has a dedicated line to SECUREWAN with a private IP part of their network (eg 10.10.x.x)
- Each org also has their own Internet connection (T1 or otherwise)
- See simple config diagram in original post (I neglected to show each org has its own internet line as well)
----------------
STIPULATIONS:
- ALL mail going to orgs belonging to the SECUREWAN MUST go through the SECUREWAN network
--- no ifs ands or buts. If org belongs to SECUREWAN, mail to them is never routed over the other Internet line
- ALL NON-SECUREWAN mail will NEVER go through that network
--- this is most likely because of security and privacy issues... only related and relevant email on that network
- If SECUREWAN is ever down, mail going over that should optimally be queued and not discarded
- We do not have control of any SECUREWAN systems, but we can use their DNS
- We need to automatically handle email to SECUREWAN orgs
--- that is, there may be 10-100 changes every other week, we don't know so manually adding routes or rules to each of them is administratively difficult
- We cannot put any SECUREWAN systems in our own network
--- probably again, security issues... sure they are secure but we don't trust them that much
----------------
MY CRAZY THOUGHT:
- since we can access their DNS, can we somehow leverage the response that if we ask for an org inside SECUREWAN, it will return a private address... versus if we asked for say GOOGLE.COM from them, they would OPTIMALLY return an Internet routeable address OR have no idea and fallback to another DNS
what if you ONLY use SECUREWAN's DNS for mail delivery? then you will never get the public version of the MX records.
this would work if:
1.SECUREWAN will reply with other domains (other than all the HISWON, and HEROWNs)
2 SECUREWAN's DNS server is reliable enough for you, because this would halt other regular outbound mail as well if their DNS goes down
I've followed that logic too, ENCOSE. We cannot be certain that:
1. they will provide external DNS resolution (not going to assume at this point)
2. relying on their DNS infrastruture over their dedicated line (unproven reliability)
Am I living a pipedream? As an alternative, THEY have suggested hey... just forward all your mail to us and we will route it in the SECUREWAN or out to the Internet. This of course is unacceptable because we cannot have all mail going through them.
I have tested the following in my enviorment. (Which is, a watchguard firewall and Exchange 2003 server).
Lets assume the following for my explanation, that my AD domain is mydomain.com, and that my Internet Connection is referred to as Internet Connection and my Secure Wan Connection is referred to as Secure Wan.
I go to my domain controller for "mydomain.com" where my DNS is running. I place in my 2 ISP Forwarders, and then I add a zone for hisown.com and herown.com both of which include their secure wan ip address' (Both A records and MX Records on a 10.x.x.x network)
Then on my Exchange 2003 Server for mydomain.com I refer my SMTP Connector to the DNS of my local DNS server for MyDomain.com (which now has zones for hisown and herown).
I then go to my watchguard firewall and create my SMTP Proxy rule where I allow all outbound port 25 traffic on my INTERNET CONNECTION Except to hisown and herown.com's.
I then repeat the process in the other 2 locations, only difference being is when i'm at hisown.com i set it up for mydomain.com and herown.com And when I'm at herown.com i set it up for hisown.com and mydomain.com.
At this point any SMTP Traffic I send from any of the 3 locations to any of the other 2 refer to the SECUREWAN Connection. If for some reason of god my dns goes down and it tries to go out the internet connection, my proxy will block that traffic therefore keeping the messages in my que until my dns server or securewan connection comes back up, however still allowing all e-mail to anyother domains to go through my internet connection.
I got that to work... what do you think about that.
Similar setup here... Exchange and a Watchguard for my testing. I follow you on that except it misses one prereq...
The domains/orgs part of SECUREWAN are or may be unknown to us. Also there may be 10-100 changes every other week, we don't know so manually doing anything for them administratively difficult...
...or has your design addressed this and I missed it?
I didn't catch that before so it didn't address that.
Now that makes me think you are pooched.
I know the ISP we have chosen for our point to points gives us Public IP Address' for our point to point so they work both sercurely and on the net. For instance if I'm going from our main location with Public IP 1 to our remote location Public IP 2 even though they are both public IP's since we have the same ISP it only travels on their network. Is it possible for Secure WAN to do that for you as well. Because if they did that then you could use normal DNS and through your watchguard create an ip range rule to force it over the point to point connection versus your other internet connection.
Out of curiousity which is also why I am probably bewildered by this... even though I understand what you are trying to do, I'm curious of the actual situation you are trying to do. Webhosting, buying of companies so forth. Is there a need for the traffic to go over the Securewan for HIPPA reasons or SOA or? Just curious.
Yes for compliance. Let's say theoretically...
We are BANK1, we are part of SECUREWAN. BANK2/3/4/5/6 is as well. We all have outward facing domains.
If we ever send mail to each other, it must be through the SECUREWAN, or nowhere at all for privacy/security/etc. Anything else that is not related or personal will just dump out our own respective ISPs.
We don't know who participates in SECUREWAN. Well, we probably do but it will fluctuate so administratively it is difficult to manually do routes.
The kicker is that SECUREWAN MANDATES that all comms between the orgs pass through them. Again, the original plan was for all mail to go through them and they will handle internet facing or between the orgs. This is unacceptable to the orgs involved as mail not going to other orgs in SECUREWAN belong to us. They (SECUREWAN folks) should never touch it.
So this is the pickle we are in then... we need to look for a happy medium. One where they can still see that all mail going to SECUREWAN orgs actually go through the SECUREWAN, but we still retain control of all other email comms.
Which then comes to the lynchpin. I was just thinking that if we can show we point to them to resolve names somehow, we can say hey SECUREWAN DNS server... BANK2 is 10.10.x.x. Cool, send through SECUREWAN. Of course this means that Exchange looking for BANK2 should NEVER see that hey... BANK2.COM is also 63.24.71.9 (example), route it through the ISP or whatever. The two problems is if we solely rely on them to provide resolution for internet AND internal, our mail outbound mail will stop flowing if their DNS hicks.
So, there needs to be some mechanism to split it up. It's wracking my brain.
Oh an extension to that is if we manually do routes or entries of any kind, it puts the accountability on us to make sure it's always right and up to date... this is something not allowed by SECUREWAN. So again this goes around to... the only effective means to tell what is what is their DNS... or so I believe.
The minor minor point to this is I'm thinking of some sort of relay to be setup so that should SECUREWAN be down, messages can be queued. Perhaps redundant links, but that's another can of worms.
Arh.
I figured it was something like that.
There is one other options. You could have 2 e-mail address's with 2 SMTP connectors. 1 for secure bank traffic and 1 for personal use and thus by domain name could control which link it went out on. Only thing there is then your users have to be smart enough to make that happen. That's how we handled it in the Military was we had a classified network and a normal network. You logged on to one for the secure stuff and another for non secure and the two didn't intertwine.
Doesn't Secure WAN have a dns server on that 10.10.x.x network? And if it's just for point to point the only Domains that should belisted should be those part of the Securewan secure network.
This would leave you with two options.
option 1. Have your own internal DNS Server that updates off of the 10.10.x.x DNS server from Secure WAN and forward all your mail through that, then if the link goes down, your queues would build up and you would have some control.
option 2. I forgot what my other option would be.....when i think of it I will add it ;)
I should make this question worth 1000 points for education.
Yes, SECUREWAN has a DNS with all the orgs involved.
"users have to be smart enough to make that happen." Heh. Sure, I'm clueless on DNS, but end users? Nah.
So for option #2, we would need to have a secondary zone for them to update I presume. If that is so, having that zone makes lookups to say BANK2 take precendence over ISP lookup? How is that setup... hmmm. Oh wait, set us as a caching only for SECUREWAN's DNS. Ok. Still, my question above applies.
Can we flesh out how things would work? It's a good high level conceptual thought right now. For example, where we may need to set things... don't need to get into detail for example go to DNS panel, right click and add record. Just remark to add an (A RECORD) for BANK2 on MYOWN DNS... not that this is part of the solution.
in your DNS, setup the SECUREWAN's DNS as a forwarder, and that's it.
every query against your DNS will be obtained from SECUREWAN'S server, and cached on yours... all HISOWN, HEROWN lookups will yield only the private mx.
and during whatever potential intermitten outages, you should have cached entries left... and if cache entries had expired, or does not exist... mail will just sit in queue.
Encose explained my point, if yours is updating from theirs and caching, and it's the only forwarder then it will resolve the hostnames and if the connection is down queue them, if it's up it will send them.
See what I'm saying? But that means that SECUREWAN's DNS needs to be on the 10.10.x.x format and and not the public ip DNS, which it should have since it's on internal network.
I see. So color me ignorant then... what happens when someone from our network asks for a non-SECUREWAN org domain... say emailing hello@google.com? What is the DNS and mail flow then? Is the SECUREWAN DNS doing all name resolution? If so, the hitch is that:
1. we cannot assume that their DNS will resolve anything other than the orgs part of them
2. if we assume they resolve external names, then if the link to their DNS server is down, any other external outgoing mail from us will halt as well
Have I missed something crucial?
The solution proposed does satisfy that minimum administrative effort is needed...
That the onus is on them to ensure records are up to date and we will use them...
That mail belonging to the SECUREWAN orgs will be routed to them only and not the internet...
Either the question has been fully answered and I'm missing a crucial configuration point or we are so annoyingly close!
Hmmm so if in the above example... our DNS sees GOOGLE.COM and forwards it to SECUREWAN DNS... they have no idea who GOOGLE.COM is. What happens then? Does is come back to our DNS and walk the root hints? I'm just not clear of what would happen. And as above, in the case the SECUREWAN DNS is down and we need to resolve other domains... hmmm
I think you have missed something cruicial.
Most importantly your DNS server will be doing everything. It's just updating and caching ip's from SecureWAN.
In that case with GOOGLE what your DNS Server will be doing is the following in this order.
1. It checks the DNS to see if it matches any zone that it has, an example if your domain is mydomain.com, Exchange would search the DNS For results of mydomain.com and see that it doesn't need to go to the internet that it is the domain it's on.
2. After it checks that it also looks at any other zones that are listed in DNS. So in the above example if your DNS Server is updating from Secure WAN, it will check the list of ZONES that securewan's DNS Server has sent to your DNS Server. If the domain matches it is done, and assuming that it is a 10.10.x.x record it then sends it over your secure wan connection.
3. After DNS Checks it's domain, it's zones, the last thing it does is search it's forwarders. This is where you would put in you ISP's DNS Servers. This will resolve any hostnmames that weren't applied by step 1 or 2.
If it doesn't get a response between 1-3 you get an NDR.
Only downside to me on this set it up is 2 things. 1) Does Securewan give you 10.10.x.x DNS and 2) You have to manage your DNS a bit, but once it's set it's set.
Ok so it's set. The only minor, minor caveat is then we rely on SECUREWAN to be always up to date... which is fine. Because the only failing scenario is that they don't have and entry for say BANK3 or DNS isn't yet up to date and our DNS goes out and fetches elsewhere. Neat. Ok I'm going to review this entire thread once more ;)
I'm in Canada. Ok.. so really, we can only specify SECUREWAN DNS as forwarders and can't have ISP because we can't have failover to work 100%. Otherwise we could end up querying an Internet based DNS for a secure mail server by mistake... no?
If that's the case, then how can we get real Internet based domains to work... ok I'm confusing myself.
correct on only using SECUREWAN, because any additional forwarders will result in the public version of the MX.
and not that i know of, you can't transfer zones if we don't even know the zone names.
quick question... is there anyway for SECUREWAN to have a redundant DNS server out on the internet? that will make your life a lot easier, along with all the other HISOWN and HEROWN 's IT dept.
I'm afraid not. Ok so it's laid bare then. MYOWN will have forwards to SECUREWAN for everything... for Exchange anyway. This will ensure SECUREWAN maintains control... while we giving up a bit on our end.
What are you thinking about with the question of redundant DNS? If it's feasible we can push it.
since SECUREWAN is kind of in charge, they should have an offsite DNS server that sits on the internet, which hosts HISOWN, HEROWN's private MX records... and everyone will use that as a second DNS forwarder, or just as a second DNS server... so even if your questionable private link goes down, their 2nd DNS will still be reachable via the internet
Sorry I disappeared got busy on my own right.
If I was securewan I would have 2 sets of DNS Servers, one that as an ISP that housed my internet traffic and public ip network, then I would have one that housed my in house Virtual Network. If I did that then what I could do is put all my DNS records for those members of the "Secure Network" on the VPN DNS Server with local address like 10.x.x.x and then have my public DNS Server replicate everything else via zone transfer. This would allow SECURE WAN to provide the following,
A SECURE e-mail solution over VPN to those who are members, but if you aren't a member they would just be using the Public DNS Records and doing a bit of DNS hosting for you but not actually seeing the traffic across their line.
Here in chicago we have 2 "Canopy" networks that are set up 2 different ways.
Way 1. You use "Company" as your ISP, and also use them for your point to point tunnel to an offisite location. The same setup is on the offsite location. We then have 2 IP Address' listed on our Satelittes, one that is a Public Internet IP for all internet traffic. Then we also have a 10.x.x.x ip address' for our point to point. We plug both into our Watchguard's as 2 external ip's. (One labled Internet, one PTP).
Our ISP has 2 DNS Servers, 1 Private for uses of their connection, and 1 for Public DNS Use. The public one is updated like every other ISP DNS Server, the Private one is maintained by them. They input all the private IP's, MX records, A Records, and all that stuff so that when you are trying to access an address that is part of their network, you never actually hit the internet, it's like one big LAN.
How we manage that through our Watchguard is this, we have a DNS Proxy rule to require all DNS lookups to go out the PTP connection to the Private DNS Server. We have 2 other rules created, anything that is 10.x.x.x also goes out that connection, and anything else goes out the "External" port of the watchguard.
This allows our ISP to manage their "internal PTP Secure network" and decide how traffic is handled. Which is how it should be since we pay them for the Secure Network.
Way 2: (the original way that we changed because no one felt 100% safe with it) was to do all the same stuff but with Public Internet IP's and hope that none of the traffic left the network. It never did becuase they managed all their switches and routing tables but it was a pain in the a$$.
Way 1 is how they should be creating a secure network. That's how we set up our M ilit ary networks so that we knew traffic was always routed correctly.
If you want bunny, we can chat via phone if that makes life easier.
Business Accounts
Answer for Membership
by: SpottedBunnyPosted on 2007-07-12 at 18:53:51ID: 19477817
I believe the key lies in that the SECUREWAN.COM DNS has records for all the dedicated links to all the other organizations... therein we can somehow set our Exchange server to query the SECUREWAN.COM DNS... if it returns a 10.10.x.x address, then route mail here. Otherwise, route it through the Internet. That's a concept, but how, if possible, can it be executed? Other ideas?