VPN design

In article , piertonio wrote: :I have to setup 8 VPN (IPSec) connections from branch offices via ADSL :(where usually works 2 or 3 people with WIN XP clients) to headquarters :whith two servers (SBS2003 and w2003 server).

:I was thinking about this:

:Headquarter: Cisco 1841 :Branch office: Cisco 1721

:Is it a good idea ?? Or I can find some troubles ?

Those sound plausible, but it would depend on the ADSL line rate and upon the sustained rate you need on those lines. The 1721 is not able handle 8 megabits per second of short packets. The fast-switching maximum rate for a 1721 is less than 1 megabits per second (of large packets!), so if you intend putting firewall features on the 1721's then you could easily run out of processing power with even just a

4/1 ADSL line, *if* you had sustained traffic flows.

The 18xx series is able to handle firewalling without using the main CPU -- but my analysis of the 1841 is that it is only suitable up to about 3 megabits per second of sustained short packets. As your HQ is your aggregation point, the 1841 might turn out not to be fast enough for your total load... but a -lot- would depend upon traffic patterns.

I happened to be looking at the Cisco Newroom a couple of days ago, and notice in there an article saying that the CCIE will start adding a 3845 Integrated Services Router to the lab rack as of January, as the 3845 will be replacing the 1600 and 2600 series. The main distinction of the 1700 series is that they have hardware crypto accelaration (which the 1600 and 2600 do not have), but they are otherwise not that different from the 1600 or 2600 in routing speeds, so "the writing is on the wall" that the lower end models of the 1700 line likely do not have a big future.

What functions do you need at the various offices? If your only "routing" function at the branches is to convert between ADSL and ethernet and pass the traffic between the inside LAN and the WAN, then you might want to consider using a plain dump "ADSL modem" to do the ADSL ethernet, and then putting in either PIX or one of Cisco's new ASA 5400 Security Appliances. A PIX 501 (< $US400 street) would be able to handle -about- 3 megabits per second sustained AES-128 encrypted IPSec traffic (rated to 4.5 but you get latency effects cutting your real traffic rate.) A PIX 506E is rated to 30 megabits per second AES-128. (There is some concern at the moment whether the 501 and 506E will be dropped; Cisco said they wouldn't be several months ago, but that was before the ASA 5400 series...)

Thank you very much !!!

Actually the needs of the branch offices of this small company are only to receive e-mails from the Exchange Server and (whenever they need) to connect trough "Remote Desktop" to the W2003 server to execute a Firebird base data base program .... not more for now...

Best regards Piertonio

"Walter Roberson" ha scritto nel messaggio news:dh1ehk$frg$ snipped-for-privacy@canopus.cc.umanitoba.ca...

In article , piertonio wrote: :Actually the needs of the branch offices of this small company are only to :receive e-mails from the Exchange Server and (whenever they need) to connect :trough "Remote Desktop" to the W2003 server to execute a Firebird base data :base program .... not more for now...

Ah, Exchange Server. How will they connect to that?

If they will be connecting via pop3 or imap4 or their ssl equivilents, then the situation is relatively easy.

If, however, they will be needing to authenticate (NT Domain authentication) against a remote server and want use of all of the Exchange facilities (e.g., shared calendars and address book), then as far as I know, there is no -reasonable- way to do that via *any* Layer 3 firewall.

But I could be wrong -- it could be that our HQ just doesn't happen to know all 736 incantations needed to make Exchange firewall-safe.

What I can say for sure is that with the way our HQ has configured Exchange (and there's a team of several people full time on it), that Exchange makes many bad assumptions that are incompatible with stateful Layer 3 firewalls. Some of the bad assumptions could be worked around by turning off expiration out of idle connections -- but, alas, the process of polling for new mail involves a new transient port each time, so if you turn off connection expiration, your connection table will fill up.

There is a fellow over in comp.security.firewalls, who goes by Leythos, who swears that Yes, Absolutely, you can get Exchange working fine over a firewall (and that if you can't, then someone involved must incompetant.) I have substantial doubts about that, but since I don't get to stick my fingers in the Exchange Server itself, I admit the possibility that the problems can all be fixed on the server side.

I've been battling Exchange vs PIX for years, and I am sure that the Exchange server behaviour that reaches here from our HQ *cannot* be configured for on a PIX 6.x without opening large security holes (though one could get closer than I get, if one were willing to give all inside hosts static public IPs.)

Possibly if one were to use a Layer 2 Transparent firewall (PIX 7.0, ASA 5400 7.0, or some quite new IOS versions) then the issues might go away.

I'll step in here and explain how to make this work with Exchange specifically to SBS2003...POP3 and IMAP4 are legacy and not subject of my concern.

Option 1 (for the office).

Do nothing unusual. If VPN is properly established, it works quite fine. It works better if you have XP Pro SP2 and Outlook 2003 (there are enough licenses for everyone provided for Outlook 2003 with SBS). Once the VPN is up and running, and the DHCP server is actually located in HQ whereby your VPN client acts as a DHCP relay agent, from the client workstation run http://whateverserver/connectcomputer and it will automatically join the domain, set up the mail client for the user, and deploy Outlook 2003 if necessary. Make sure that your users are based on Mobile User template so they also get VPN rights from outside the office. Users can then also connect to the terminal server over that VPN.

Option 2 (for home).

Don't bother with VPN at all and setup Outlook 2003 using the RPC over HTTPS feature (new for XP Pro SP1/Windows 2003). Enable remote web workplace (proxies RDP through SBS among other things) and require strong passwords. Remote users will want to be able to work from home, so that's how they'd likely prefer to those clients setup. There is a detailed setup guide available right inside the remote web workplace to set this up. Incidently, RWW is port 444 in addition to 443.

There are many other options...

You can put a gateway box in front of SBS2003 to handle incoming SMTP traffic to reduce its attack footprint.

what about the 800 series, the new models ? They kick PIx-ass

In article , Martin Bilgrav wrote: :what about the 800 series, the new models ? :They kick PIx-ass

The 85x is rated to 5.12 Mbps; the PIX 501 is rated to 60 Mbps cleartext. The 87x is rated to 12.8 Mbps; the PIX 506E is rated to 100 Mbps cleartext.

There is some question about whether the PIX "cleartext" rating would be based upon long packets or 64 byte packets. 60 Mbps of long packets would work out as about 3.3 Mbps of short packets. The 506E is rated to encrypt at 30 Mbps AES-128, 17 MBps 3DES; my recollection is that the 87x does not do hardware acceleration of AES.

So... it's not clear that the 85x or 87x "kick PIX-ass". One would have to try them side by side under the same conditions to figure out which numbers were accurate under which circumstances. On paper, even the PIX 501 is way ahead of the 87x -- if the documents are talking about the same thing.

We have Exchange working just fine here through Checkpoint firewalls. There are numerous (perhaps half a dozen) sets of ports you need to manually lock down on the Exchange servers and GCs. Once thats done, things work like a charm assuming all those ports are open.

With OLK2003 and Exchange 2003, it's much easier though for some sitautions. The new RPC/HTTP requires a bunch of configuration on your Exchange environment, but then you can open 443 to the Internet and people can point the Outlook full client at the rpc/http frontends (can just be your OWA cluster) and it works as well as being in the office (perhaps a bit more latent, of course).

--Brian

Thanks to everybody !!! All the suggestions are welcomed !!! I have to study (and try...) so many things....so if I understand in the right way a good solution could be the following scenario: Branch office: Switch-Pix 501-Cisco 1721--->Internet

Headquarter: Catalyst (with EMI)-Cisco 1841--->Internet

Am I right ???

Thanks again guys !!!

Piertonio

"Walter Roberson" ha scritto nel messaggio news:dh2b8d$mui$ snipped-for-privacy@canopus.cc.umanitoba.ca...

In article , Brian Desmond wrote: :We have Exchange working just fine here through Checkpoint firewalls. :There are numerous (perhaps half a dozen) sets of ports you need to :manually lock down on the Exchange servers and GCs. Once thats done, :things work like a charm assuming all those ports are open.

:With OLK2003 and Exchange 2003, it's much easier though for some :sitautions. The new RPC/HTTP requires a bunch of configuration on your :Exchange environment, but then you can open 443 to the Internet and :people can point the Outlook full client at the rpc/http frontends (can :just be your OWA cluster) and it works as well as being in the office :(perhaps a bit more latent, of course).

In PIX 6.x, according to Cisco, RPC fixup happens only in one direction. If A, behind PIX-A contacts B behind PIX-B for RPC, and B sends back a port number, then one of PIX-A or PIX-B (don't recall which) will open the port and the other won't -- from the perspective of the PIXes, one of the transactions is incoming and the other is outgoing, and the PIX only does RCP fixup in one direction.

But that's a Cisco problem, not a general Exchange problem. PIX 7.0 is supposed to have better RPC handling.

What -is- a general Exchange problem is that once you have talked to an exchange server using a particular IP+port, Exchange will continue to assume that you are available on that IP+port, and might, anywhere from 5 minutes to 3 weeks later, attempt to contact you on that IP+port. If the IP+port that the Exchange server sees is PAT, then Exchange will, for the next few weeks, regularily attempt to contact that port translation that long long since expired.

I have traced this through, and it isn't just UDP: it happens for TCP as well. Your Windows workstation contacts the Exchange server via TCP, a normal conversation complete with FIN ACK ensues (probably lasting less than 2 minutes) -- and Exchange will continue to assume that the port it saw is still valid, even though the connection was completely closed :(

I don't recall at the moment whether I've seen the following for Exchange 2003, but with Exchange 2000 for sure, we saw numerous intances in which the Exchange server attempted to contact the client, using the private internal IP of the client, not the public IP. The clients are talking to a local WINS server in order to be able to resolve the server identities, and either directly that way or indirectly through PDCs, the WINS server is learning the internal IPs. The local WINS server then spills those local IPs over to HQ's WINS server... The PIX for one does not translate the IPs that are deep in the data fields of the NETBIOS transactions, so it's the private IPs that the HQ's WINS server learns and wants to use. :(

There's another issue that comes up on the PIX, especially with Exchange 2003. There's an RPC transaction, the local PCs learn a destination port, the PIX creates a temporary ACL exemption in order to allow outgoing access to the destination. That works fine as long as the subsequent flow stays active, but eventually the TCP connection closes or the UDP flow goes idle and the PIX times out the flow. Later, the local PC wants to send more -- and instead of assuming that the destination port might have changed and so doing another RPC, the local PC just goes ahead and tries to use the destination port. As the temporary ACL exemption is gone by then, the local PC can't get through our outgoing filters. The local PC will try for *days* on the same port, waiting for the remote system to answer, when if it simply did another RPC query it would get through in seconds... The only work-around for this is to open up our outgoing filters to allow outgoing access to a hundred thousand or so ports on every component of every Exchange server component around our (continent-wide) organization. :(

Then there's another Exchange-related problem we see. This one might technically be at the NT Domain Authentication level... it's pretty hard to tell. Anyhow, from time to time, one of our Windows PCs takes a fancy and starts trying to make NETBIOS contacts with 10 to

50 different Windows PCs in other branches of our organization. Each such incident extends for numerous hours (3 - 14 hours, maybe longer); each destination is tried a number of times, but with the exact destinations tending to shift a bit over time. These destinations are sometimes PDCs or BDCs, but it is quite common for them to be just plain Windows PCs with no special attributes. I figure the remote locations must be learned via WINS. The source systems for this are, as best I recall, always Windows XP. When I first started investigating this problem a few years ago, when XP was still relatively new, on one particular run the destinations were also exclusively XP -- but I don't know if that still holds. On some spot-checks, the systems initiating the connections never had a detected virus or spyware.

Now, one important factor in the behaviours we see, is that we control *outgoing* connections as well as incoming. If you do not control outgoing connections, you would never notice half of these problems.