«

Hey guys, I will be setting up a new 2811 router as our border router
to Qwest. We currently have a single IP address that is linked to our
domain, i.e. abcd.exchange.org for our exchange server. I would like
to use this router as our firewall as well since it will be installed
with the Security bundle IOS.

exchangeSvr------2950SWITCH--------2811ROUTER------------T1Qwest
x.x.x.7 e0x.x.x.1 S0216.x.x.28
file/intranetSvr----switchAbove
x.x.x.3

1. How can you configure the 2811 router to forward infomation to the
exchange server? Port forwarding??? So that when an email client uses
our domain name, it will communicate with our exchange server.

2. The 2811 router has the new security bundle. Ha anyone configured
the intursion detection, and new security features. If so, would you
please enlighten me with sample code and strategies.

3. I will be eliminating our ISA firewall from this network and have
the router take on that role. Is this suggested? What would the
consequences be/ or benefits.

4. We currently publish our intranet to outbased employees untill we
move the information and security settings to Kintara. How can you
publish an internal site (Window 2000 server- 10.10.10.3) with this new
router if possible?
Any information would be greatly appreciated. Thank you!!

Jimmy

wrote:
> Hey guys, I will be setting up a new 2811 router as our border router
> to Qwest. We currently have a single IP address that is linked to our
> domain, i.e. abcd.exchange.org for our exchange server. I would like
> to use this router as our firewall as well since it will be installed
> with the Security bundle IOS.
>
> exchangeSvr------2950SWITCH--------2811ROUTER------------T1Qwest
> x.x.x.7 e0x.x.x.1 S0216.x.x.28
> file/intranetSvr----switchAbove
> x.x.x.3
>
> 1. How can you configure the 2811 router to forward infomation to the
> exchange server? Port forwarding??? So that when an email client uses
> our domain name, it will communicate with our exchange server.
>
> 2. The 2811 router has the new security bundle. Ha anyone configured
> the intursion detection, and new security features. If so, would you
> please enlighten me with sample code and strategies.
>
> 3. I will be eliminating our ISA firewall from this network and have
> the router take on that role. Is this suggested? What would the
> consequences be/ or benefits.
>
> 4. We currently publish our intranet to outbased employees untill we
> move the information and security settings to Kintara. How can you
> publish an internal site (Window 2000 server- 10.10.10.3) with this new
> router if possible?
> Any information would be greatly appreciated. Thank you!!
>
> Jimmy
>

Hi Jimmy,

I don't see any drawbacks with using the ISR for all of the above, after
all they were built to do all these 'integrated services' at wire speed
and the IOS security feature set is good to excellent!

1) The ISR needs first to be set up to do NAT overloading:

ip nat inside source list NAT-ACCESS-LIST interface Ethernet0 overload
interface e0
ip nat inside
interface s0
ip nat outside

The named standard access-list NAT-ACCESS-LIST just contains a list of
your hosts.

You can then achieve port forwarding to your exchange server, say for
SMTP, with the following:

ip nat inside source static tcp x.x.x.7 25 interface Serial0 25


2) I haven't used IDS but I have used CBAC (context-based access
control) extensively. This is basically a simple but effective stateful
firewall. It will allow (and audit) any 'connections' you specify
(including udp and icmp) originating on the inside network, but block
connections originating on the outside.
You can of course specify what connections are always allowed (using
access-lists). For example, you will need to explicitly allow SMTP
connections to be initiated from outside the network for your port
forwarding or CBAC will block it.

Good link on CBAC here (may need a CCO login):
http://www.cisco.com/en/US/partner/p...0800ca7c5.html

3) As mentioned IOS is well featured for security and the ISR perfectly
positioned to implement those features. So as long as you configure it
right it's pretty good.
There may be some things the ISA firewall can do that the IOS can't that
I am unaware of, but considering how important security is to Cisco I'd
be surprised if there was anything critical.

4) Easily solved with port forwarding:

ip nat inside source static tcp x.x.x.3 80 interface Serial0 80

External hosts will need to use 216.x.x.28 to access the web-server.

Hope this is of assistance.

regards,

Ben

Ben,

Thank you so much it makes sense now!!! haha
I currently have my CCNA, and this is actually my first position as an
System/Network Admin...and it seems that everything I learned in class
needs a little push to remember. Thank you very much again for your
time and knowledge. =)

Jimmy

Hi,

During my past work experience the only benefit that ISA Server could
provide better and safer then IOS FW feature set is web server publishing.
With ISA Server web publishing rule you can publish specific internal web
sites to the Internet without publishing the whole host to the Internet. In
that way on single web server you may have sites that are not exposed to the
Internet and sites that are exposed. With static NAT you can't do it, as far
as I know...But, I never publish my internal web servers intended for
corporate employees to the Internet. I rather use VPN...

B.R.
Igor



"Ben" <> wrote in message
news:m8ayd.84593$...
> wrote:
>> Hey guys, I will be setting up a new 2811 router as our border router
>> to Qwest. We currently have a single IP address that is linked to our
>> domain, i.e. abcd.exchange.org for our exchange server. I would like
>> to use this router as our firewall as well since it will be installed
>> with the Security bundle IOS.
>>
>> exchangeSvr------2950SWITCH--------2811ROUTER------------T1Qwest
>> x.x.x.7 e0x.x.x.1 S0216.x.x.28
>> file/intranetSvr----switchAbove
>> x.x.x.3
>>
>> 1. How can you configure the 2811 router to forward infomation to the
>> exchange server? Port forwarding??? So that when an email client uses
>> our domain name, it will communicate with our exchange server.
>>
>> 2. The 2811 router has the new security bundle. Ha anyone configured
>> the intursion detection, and new security features. If so, would you
>> please enlighten me with sample code and strategies.
>>
>> 3. I will be eliminating our ISA firewall from this network and have
>> the router take on that role. Is this suggested? What would the
>> consequences be/ or benefits.
>>
>> 4. We currently publish our intranet to outbased employees untill we
>> move the information and security settings to Kintara. How can you
>> publish an internal site (Window 2000 server- 10.10.10.3) with this new
>> router if possible?
>> Any information would be greatly appreciated. Thank you!! Jimmy
>>
>
> Hi Jimmy,
>
> I don't see any drawbacks with using the ISR for all of the above, after
> all they were built to do all these 'integrated services' at wire speed
> and the IOS security feature set is good to excellent!
>
> 1) The ISR needs first to be set up to do NAT overloading:
>
> ip nat inside source list NAT-ACCESS-LIST interface Ethernet0 overload
> interface e0
> ip nat inside
> interface s0
> ip nat outside
>
> The named standard access-list NAT-ACCESS-LIST just contains a list of
> your hosts.
>
> You can then achieve port forwarding to your exchange server, say for
> SMTP, with the following:
>
> ip nat inside source static tcp x.x.x.7 25 interface Serial0 25
>
>
> 2) I haven't used IDS but I have used CBAC (context-based access control)
> extensively. This is basically a simple but effective stateful firewall.
> It will allow (and audit) any 'connections' you specify (including udp and
> icmp) originating on the inside network, but block connections originating
> on the outside.
> You can of course specify what connections are always allowed (using
> access-lists). For example, you will need to explicitly allow SMTP
> connections to be initiated from outside the network for your port
> forwarding or CBAC will block it.
>
> Good link on CBAC here (may need a CCO login):
> http://www.cisco.com/en/US/partner/p...0800ca7c5.html
>
> 3) As mentioned IOS is well featured for security and the ISR perfectly
> positioned to implement those features. So as long as you configure it
> right it's pretty good.
> There may be some things the ISA firewall can do that the IOS can't that I
> am unaware of, but considering how important security is to Cisco I'd be
> surprised if there was anything critical.
>
> 4) Easily solved with port forwarding:
>
> ip nat inside source static tcp x.x.x.3 80 interface Serial0 80
>
> External hosts will need to use 216.x.x.28 to access the web-server.
>
> Hope this is of assistance.
>
> regards,
>
> Ben

B.R.

Eventually I would like to allow vpn access for outbased employees. I
do not have experience implementing VPNs. Can you please give me a
quick run through of setup required, i.e. dedicated server, settings
etc...

1. What is needed in the router config to allow VPNs to connect.

2. What do you need to setup VPN on a server, and is there a preference
as to which or type of server to implement this on.

I think I'm still a little confused as to how VPNs interact with the
network, and how access is granted.
Thanks for all the help you guys have given.

Jim

In article < .com>,
<> wrote:
:Eventually I would like to allow vpn access for outbased employees. I
:do not have experience implementing VPNs.

:I think I'm still a little confused as to how VPNs interact with the
:network, and how access is granted.

There's more than one way to impliment VPNs ("Virtual Private Network"
is the generic concept and there are several different ways to
achieve it.)

Some of the implimentations require special setup or equipment
from the service provider between the endpoints (remote users, remote
offices, home offices, whatever) and the central location. Such
setups tend to be more secure but more expensive, and they can be
impractical if the remote locations move (e.g., salesman traveling
around and needing to access the order database.)

The common methods that do not require special intervention by the
ISPs, is to use any one of several security protocols that involve
using software or hardware that takes a plain original packet,
encrypting it, wrapping a new packet around the encrypted data
("encapsulating" the packet), and addressing the encapsulated packet to
the security gateway device at the main office (e.g., router with
firewall feature set, VPN Concentrator, PIX firewall, or similar). The
encapsulating packet travels over the insecure Internet, but all the
interesting information in the packet is encrypted, making it difficult
for any intruder to gleen anything useful out of it. When the
encapsulating packet reaches the security gateway, the security gateway
removes the wrapping packet and decrypts the packet that was enclosed.
It then takes the packet that was enclosed and puts it onto the LAN --
usually with the IP source and IP destination that was originally
written into the packet.

What the destination sees is a plain packet, just as if the two
networks were directly connected. The destination device (e.g., server)
often does not need any special setup at all: as far as it is
concerned, it is just talking to yet another device on the LAN.
Sometimes, though, it is desireable for the destination to
react differently to local requests than to remote requests; those
cases can be handled by looking at the source IP address and
by knowing what source IP address ranges need to be handled in which
way. On the other hand, if one has configured a web server to
do IP based authentication, then it may be necessary to add the
potential remote address ranges to the list of authorized addresses.
This would be most common on a web server that is set up to be
both an Internet server (content to the public) and an Intranet
server (content only visible to the organization.)

When the LAN device (e.g., application server) replies, the
IP addresses get flipped around as per usual, and normal
routing rules apply. Those routing rules must be set up to direct
the outgoing reply packets back to the security gateway -- that
happens automatically if your security gateway is your WAN router or is
a firewall that is interposed between the WAN and your LAN, and
extra internal routing configuration is mostly an issue when you
are using a VPN concentrator. When the outgoing reply packet
makes it to the security gateway, the security gateway will notice
that there is a VPN tunnel between that particular source and
destination, and instead of sending the packet out raw to the
network, it will encrypt the packet, encapsulate it, and send the
encapsulating packet back to the public IP of the original device
[which it has kept track of.] When it gets to the other end,
the remote software or hardware will strip off the encapsulating
packet, decrypt, and inject the packet into the remote LAN as if
it had always been local to there.


This description of the general workings of VPN tunnels applies
to at least four of the most common tunneling protocols:
IPSec, PPTP, L2TP, and GRE. These protocols differ in the variety
of encryptions offered; in the ability to detect attempted misuse
of the tunnel (e.g., by recording encrypted packets and "playing them
back"); in the level of assurance that the packet really came from
where it says it did; and in the methods used to authenticate
a remote site or user when the remote site connects to the
security gateway and asks to be trusted. GRE tends to use a fixed
"shared secret". IPSec can use fixed shared secrets for Lan-to-Lan
connections. PPTP and L2TP tend to use username and password
combinations; those usernames and passwords might be registered
with the security gateway itself, or might be registered with
a database (a RADIUS or TACACS+ server.) IPSec can also use
public key encryption authentication methods; PKE is usually
too much of a nuisance to bother with if you only have a small number
of offices, but it is the only practical way to go if you have
a large number of offices that might need to talk directly to
each other without going through a central security server.


A further note about authentication and special configuration for
remote access:

In some situations (particularily in larger organizations), it is
important to be quite restrictive about who can access what, and about
what access methods they can use, and about when they can undertake
that access. For example, it may be prudent that the master override
system for a bank only be useable by a small number of people during
regular office hours and only from one or two designated systems. Or
secret military information should only be accessible by those who can
"prove" they have the right of access. In cases like these, it isn't
good enough for a security gateway to just pop decapsulated packets
onto the network: someone else (e.g., "an inside job") could get onto
the same network and push those packets on instead, and intercept the
replies before the replies went out.

If your security requirements are such that relying on IP address
is not good enough, and HTTPS or SSL or ssh do not provide fine-
enough grained controls, then you may need to get into
comprehensive security layers that go far beyond the facilities
provided by IPSec and similar protocols. One particular security
framework that gets used for those more demanding purposes is 'DCE'.
DCE is big and complex, and requires that the applications themselves
be written to be DCE aware.

You don't want to impliment DCE if simpler methods are "good enough":
you don't even really want to read more than a brief overview of it
unless you have strict security procedures that you must follow. If you
need DCE, then you need DCE; and if you don't, then, in the immortal
words of Monty Python, "Run away! Run away!!"
--
'ignorandus (Latin): "deserving not to be known"'
-- Journal of Self-Referentialism

Hmmm, now remotely don't you have to configure a vpn client, and have
a server on your central LAN authenticate this link?

In article < .com>,
<> wrote:
:Hmmm, now remotely don't you have to configure a vpn client, and have
:a server on your central LAN authenticate this link?

As I wrote, the different VPN protocols differ

in the methods used to authenticate a remote site or user when the
remote site connects to the security gateway and asks to be
trusted. GRE tends to use a fixed "shared secret". IPSec can use
fixed shared secrets for Lan-to-Lan connections. PPTP and L2TP tend
to use username and password combinations; those usernames and
passwords might be registered with the security gateway itself, or
might be registered with a database (a RADIUS or TACACS+ server.)
IPSec can also use public key encryption authentication methods;

All four of those protocols require that the remote security gateway
(which could be VPN client software or could be a router or a firewall
or a VPN concentrator) be configured at least as far as knowing the IP
address or hostname of the central security gateway.

If you are using a GRE or IPSec shared secret, then the remote security
gateway has to be told what the shared secret is. That might require a
"hard" configuration at the remote router or firewall, but in the case
of VPN client software that is using IPSec underneath, it might take
the guise of a pop-up window asking for a "group name" and password,
possibly with an option for remembering the information between
sessions. The central security gateway would have to be specially
configured with the remote IP and shared secret only if the shared
secret is to be unique to that particular remote host. It is possible
to configure the central security gateway to accept and trust -any-
connection that knows one of the shared secrets, so you could, if you
wished, configure the central security gateway with just one shared
secret that was then reused by all the remote locations. Of course, the
more widely spread a secret gets, the more the risk that the secret
will become known to an unauthorized person...

If you are using PPTP or L2TP, or are using VPN client software that is
using IPSec underneath, you can often configure the names and passwords
right on the security gateway itself, without needing any kind of
server on the central LAN to provide authentication services. There
will usually be a pop-up window in which to enter this information,
rather than hard-configuring it like you would for a GRE shared
secret. For these protocols, you can usually instead configure a
central RADIUS or TACACS+ server to handle the authentication of the
names and passwords; using a RADIUS or TACACS+ server can be easier to
manage, and it is less risky than reconfiguring the security gateway
itself each time you wish to add or alter a name or password.

If you are using IPSec with Public Key Authentication, then it is
uncommon for the security gateway to be able to perform the
authentication itself, so you would configure the central security
gateway with information about how to reach the PKE authentication
server. That PKI authentication server could be an "in-house" one, or
could be a commercial service.

When you are using PKI, you may run into significant overhead in
establishing and maintaining appropriate trust -- you have to establish
that the person requesting the creation of the PKI certificate is who
they say they are, and you have to find a secure way of distributing
the generated PKI keys to them, and you have to ensure that their PKI
certificate stays secure... e.g., that they don't just leave the PKI
certificate permanently installed on their hard drive with the username
and password fields helpfully automatically remembered by Windows.
Unfortunately, people do tend to store their certificates insecurely,
and do tend to leave their userids and passphrases automatically
remembered, so spouses, children, or theives can often take advantage
of PKI.

The other, non-PKI authentication methods have similar problems, but
PKI tends to be used by bigger organizations where there is more at
stake, so the potential impact of illicit access is usually higher at
an organization that impliments PKI. Because of this, when PKI is used,
it may be accompanied by a hardware security assistance device such as
a "smartcard" challenge/response system. Such devices seldom allow
passwords to be automatically saved, so when such a system is in use,
you have a higher level of trust that it is an authorized user. Of
course, if the authorized user tells the response algorithm or
passphrase to someone else or someone "shoulder surfs" then you have a
problem.


Anyhow, the short answer to your question is that IPsec, PPTP, and L2TP
-permit- a authentication server to be used, but usually also permit
the authentication information to be stored on the security gateway
itself.


As a practical example: we have a few remote offices, and we
are using Cisco PIX firewalls (but not VPN client software)
to connect the sites. We have configured the devices to
use unique shared secrets for each permitted connection --
N-squared divided by 2 unique secrets for N total sites.
These shared secrets are long and would be fairly difficult
for a typical human to remember (at least not without a
fair bit of practice). We have hard-configured the shared
secrets into each of the PIX firewalls, and have restricted each
one to use with fixed IP addresses (i.e., someone who
managed to steal one would not be able to get in unless they
were able to imitate the appropriate IP address as well).
We did not use any authentication server such as RADIUS or TACACS+.

If we were to start allowing VPN client software from employee
home or travelling systems, or if we were to increase our number
of offices much more, then it would become impractical to hard-code
all the necessary shared secrets and we would probably in that case
impliment a RADIUS server to perform authentication.
--
Rump-Titty-Titty-Tum-TAH-Tee -- Fritz Lieber