Networking Forums

Networking Forums > Computer Networking > Windows Networking > RRAS - Works on internal network, not past DMZ

Reply
Thread Tools Display Modes

RRAS - Works on internal network, not past DMZ

 
 
000Mike000
Guest
Posts: n/a

 
      06-28-2005, 03:55 PM
Here is my setup:
We have a T1 coming into a router that is managed by the ISP. We 'own' a
block of IPs, say, 192.168.1.125 through 192.168.1.200. (altered, of
course). The router connects to the DMZ switch. The firewall connects to
this and the internal network behind that. If I want to put a machine
outside the firewall, I place it on the DMZ switch and assign it one of the
addresses that we 'own' - works like a charm.

So, we've had some serious NAT problems with our firewall. I setup one of
the 2003 servers as a RRAS VPN server, behind the firewall. I could
establish a connection within the internal network without any problems.
Outside the network (from home, for example) the connections would
'occasionally' work. Connections were often dropped or flat out refused. It
was a very unstable environment, and we have approximately 15 road-warriors
that need SOME sort of VPN connectivity.

The idea that we came up with seemed (to me) to be fairly unorthidox.
Basically, the RRAS server sits behind the firewall with
network-interface1(eth0). The second nic is connected to the DMZ and
assigned one of the publically addressable IPs (eth1). The idea was, the
remote client 'asks' for that IP (assigned to eth1) via the MS VPN client, it
connects and then it has authenticated with the VPN, while bypassing the
troublesome firewall. We would depend on port filtering (1723 and GRE) and
our local security policy (strict pw, only authenticated users allowed to
connect, etc) to 'defend' us.

To test this out, I setup the port filters... double checked the security
policy... and put ETH1 on a private switch... then connected a couple of
laptops to the switch (all configured with similar network settings, so they
could communicate) and established VPN connections. That worked like a
charm. I attempted to communicate by other means (ping, telnet, etc) but was
unable. After that, I placed ETH1 on the DMZ switch. I tried to connect
through an outside line (a spotty PCS card) and was unable to... I kept
seeing error 638: The request has timed out.

What should I look for?
Is this type of configuration even recommended? It seems odd to have 2 Nics
configured for completely seperate networks in this manner.
Should I feel secure with just port filtering and a 'strong' security policy?

Thanks so much!
mike
 
Reply With Quote
 
 
 
 
Phillip Windell
Guest
Posts: n/a

 
      06-28-2005, 08:24 PM
"000Mike000" <(E-Mail Removed)> wrote in message
news:21A916A2-B3A9-4CF5-BF76-(E-Mail Removed)...
> Here is my setup:
> We have a T1 coming into a router that is managed by the ISP. We 'own' a
> block of IPs, say, 192.168.1.125 through 192.168.1.200. (altered, of
> course). The router connects to the DMZ switch. The firewall connects to
> this and the internal network behind that. If I want to put a machine
> outside the firewall, I place it on the DMZ switch and assign it one of

the
> addresses that we 'own' - works like a charm.


Part of your confusion is that you don't really have a DMZ. The router that
the T1 comes into is just a Router,...that's it, just a Router. It is not a
Firewall, not a NAT Device, not a Proxy. This is made obvious by the fact
that you place your Public IP#s between it and the actual Firewall and are
able to directly access them from the outside. A DMZ would use Private IP#s
(different than the ones on the Private LAN) and it would use a Firewall on
both the Inner and the Outer edge.

What you really have is a Private Network and a Public Network separated by
a Firewall that is functioning as an Edge Device. The router on the T1 is
just a router (nothing more) and is (almost) irrelevant,..at least it is
irrelelvant to what you are attempting here anyway. You have the same
setup that I have.

> What should I look for?
> Is this type of configuration even recommended? It seems odd to have 2

Nics
> configured for completely seperate networks in this manner.
> Should I feel secure with just port filtering and a 'strong' security

policy?

Your problem is that the Firewall is not properly handling the VPN. The
industry's terminology is in total disarray now-a-days and so "God only
knows" what terminology your Firewall uses in the documentation, but
traditionally the function you are looking for is called "VPN Passthrough".
It is more that just simple "Static-NAT" because it has to handle the GRE
Packets which do *not* fall under TCP or UDP but are their own type of
Layer4 Packet. Some Firewalls are simply not capable, and some just arent'
dependable,...I can't help you with that.

I see your possible options as one of these three:

1. Replace the Firewall with the RRAS box and use it as both the Firewall
and the VPN Server in one box.

2. Place the RRAS box "side-by-side" with the Firewall so they both operate
independently of each other and neither depends on the other to function.
VPN Users would connect directly to the Public interface of the RRAS box.
The Firewall will still handle it normal job but will have nothing to do
with the VPN. The Firewall would need some additional configuration if you
were doing a Site-to-Site VPN, but that does not sound like what you were
doing, it sounded like you were doing a Remote Access VPN which works on
different principles.

3. Forget the RRAS and reduce the Server to one Nic. Use the existing
Firewall as both the Firewall and the VPN Server if it is capable of being a
VPN Server.


--
Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com
-----------------------------------------------------
Understanding the ISA 2004 Access Rule Processing
http://www.isaserver.org/articles/IS...cessRules.html

Microsoft Internet Security & Acceleration Server: Guidance
http://www.microsoft.com/isaserver/t...dance/2004.asp
http://www.microsoft.com/isaserver/t...dance/2000.asp

Microsoft Internet Security & Acceleration Server: Partners
http://www.microsoft.com/isaserver/partners/default.asp
-----------------------------------------------------




 
Reply With Quote
 
000Mike000
Guest
Posts: n/a

 
      06-28-2005, 09:12 PM
"Phillip Windell" wrote:
> Part of your confusion is that you don't really have a DMZ. The router that
> the T1 comes into is just a Router,...that's it, just a Router.

Yeah, I figured I had the terminology mixed up, I'll try and use the correct
terms from here on out.
> 2. Place the RRAS box "side-by-side" with the Firewall so they both operate
> independently of each other and neither depends on the other to function.
> VPN Users would connect directly to the Public interface of the RRAS box.
> The Firewall will still handle it normal job but will have nothing to do
> with the VPN. The Firewall would need some additional configuration if you
> were doing a Site-to-Site VPN, but that does not sound like what you were
> doing, it sounded like you were doing a Remote Access VPN which works on
> different principles.


I believe that I'm attempting to set things up in this scenario. I'm pretty
sure that my problem will be resolved once I figure out this multiple gateway
issue. Let me explain.

On the network connections configuration of the RRAS box, I have the
'inside' network connection set with a default gw of 192.168.1.1, subnet
255.255.255.0 (the firewall). That is the 'private' network that the rest of
the company uses. The 'outside' network connection is set with a default gw
of the router, we'll call it 10.0.0.1. subnet 255.255.255.192. This is the
same setup that I've used in the past to put a machine on the 'public'
network... always worked. We have the IPs from 1 to 65... 1 is the router,
10 is the firewall and we've used a few others for various machines that
aren't part of the private network (image hosts, et al).

If we say that the private interface on the RRAS box is working correctly
(internal clients can access it without a problem) - configured as
192.168.1.20, subnet 255.255.255.0, gw 192.168.1.1... I'll then go to
configure the 'public' interface - as 10.0.0.23, subnet 255.255.255.192, gw
10.0.0.1. As soon as I hit okay, I am met with the error:

"Warning - Multiple default gateways are intended to provide redundancy to a
single network (such as intranet or the Internet). They will not function
properly when the gateways are on two separate, disjoint networks (such as
one on your intranet and one on the internet). Do you want to save this
configuration?"

I hit 'yes' and proceed. Now both interfaces are configured as I think they
should, but the 'multiple gateway' error message has me spooked. This was
last week, I moved past that but am now back to it... convinced that it is
the problem.

It seems that the outside traffic (remote clients) come in... ask for
authentication from 10.0.0.23 (outside RRAS interface)... only get 'so far'
and then attempt to go out via the private interface. That's my best guess.
So, I configured the firewall to allow traffic from the RRAS server through
TCP port 1723 and IP protocol 47... thinking that "traffic was traffic, as
long as the RRAS box can talk to the remote client... who cares how it gets
there?" No dice.

So... here I am. You make it sound like I'm not the first person in the
history of mankind to make this attempt... and that's comforting .
However... what type of configuration is typical? It seems that to have a
'private' network and a truly 'public' one, two gateways are absolutely
necessary... if so, how will RRAS know which interface to use?

The most recent 'success' was when we decided to 'turn off' the gateway on
the private interface. All other settings were kept (private ip, dns,
subnet) but I left the gateway blank. The public interface was kept the
same. The remote test clients (on wireless cards) came RIGHT in. No
authentication problems at all, quicker than I've ever seen them. It *has*
to be this multi-gw problem... right?

Am I barking up the wrong tree?

As for your other suggestions (and they ARE appreciated), number 1 (swap the
firewall with the RRAS box) would be impossible... the firewall was expensive
and it'd be a REALLY hard sell on managment (it works great as a firewall at
least ).

Number 3 (use the firewall as a VPN server) "was" a great solution back when
our remote users were VERY standardized. Everyone was local, simply needed a
way to check email and such. As soon as people wanted laptops... wanted to
travel all over the world... use wireless cards... the VPN software showed
its true colors - buggy as heck. We came up with the idea to use RRAS
'through' the firewall (passed 1723/47)... but you hit the nail on the head
when you said, "Some Firewalls are simply not capable, and some just arent'
dependable." It only worked about 25% of the time and never when I was
trying to sleep!

So... it seems that option 2 was the best idea. I think I'm just in over my
head with the multiple gateways problem.
 
Reply With Quote
 
Phillip Windell
Guest
Posts: n/a

 
      06-29-2005, 03:10 PM

"000Mike000" <(E-Mail Removed)> wrote in message
news3E8360D-C65A-41F2-909A-(E-Mail Removed)...
> "Phillip Windell" wrote:
> > 2. Place the RRAS box "side-by-side" with the Firewall so they both

operate
> > independently of each other and neither depends on the other to

function.
> > VPN Users would connect directly to the Public interface of the RRAS

box.
> > The Firewall will still handle it normal job but will have nothing to do
> > with the VPN. The Firewall would need some additional configuration if

you
> > were doing a Site-to-Site VPN, but that does not sound like what you

were
> > doing, it sounded like you were doing a Remote Access VPN which works on
> > different principles.

>
> I believe that I'm attempting to set things up in this scenario. I'm

pretty
> sure that my problem will be resolved once I figure out this multiple

gateway
> issue. Let me explain.


Very good.
#2 is also the way I do my Site-to-Site VPN.
However a Site-to-Site VPN complicates routing more than what you are doing.

> On the network connections configuration of the RRAS box, I have the
> 'inside' network connection set with a default gw of 192.168.1.1, subnet
> 255.255.255.0 (the firewall). That is the 'private' network that the rest

of
> the company uses. The 'outside' network connection is set with a default

gw
> of the router, we'll call it 10.0.0.1. subnet 255.255.255.192. This is

the
> same setup that I've used in the past to put a machine on the 'public'
> network... always worked. We have the IPs from 1 to 65... 1 is the

router,
> 10 is the firewall and we've used a few others for various machines that
> aren't part of the private network (image hosts, et al).


.....<shortened for space>.....

> "Warning - Multiple default gateways are intended to provide redundancy to

a
> single network (such as intranet or the Internet). They will not function
> properly when the gateways are on two separate, disjoint networks (such as
> one on your intranet and one on the internet). Do you want to save this
> configuration?"


Ok. I think this is enough to work with here without going further.

#1 Rule: Never have more than one Default Gateway.

Frame that and hang it on a wall ;-). That is what that warning/error was
telling you and you should not have continued.

Both the Firewall and the Duel-Nic RRAS VPN Box will use one Default Gateway
each,...they will both point to the current Internet Router that the
Firewall is now using.

On the Internal Side decide which device will serve as the "LAN Router".
Personally I would choose the Firewall in this case assuming you have a
single-subnet LAN. I can't think of a "clean" way to use the RRAS Box at
this point. So the Default Gateway of all the machines (except the RRAS box
and the Firewall itself) points to the Firewall. that should be all that is
needed there *assuming* you do not implement ans Site-to-Site VPN with the
RRAS box.

When VPN Callers connect they are given an IP# from the private LAN (at
least they should be). Since they become part of the Private LAN there is no
routing because they are "already there". They will not be able to come in
through the RRAS box and go out to the Internet via your Firewall. By
nature of Dialup Connections (which VPN is), they will use the Default
Gateway of the "Dialup Server" (RRAS VPN box),...it may or may not work,...I
have my doubts. It would be best if they just used your network for the job
they need to do with it and not use the Internet at the same time,...they
can disconnect from the VPN when they need to go back to using the Internet.
Another option to do both at the same time is to disable the "Use Gateway on
Remote Network" in their VPN Dialup Connection Settings,..but it is
considered a security rist to your LAN for them to do that.

I can't promise I wouldn't have left out a few details, this is a lot to
keep track of off the top of my head, but it should move you in the right
direction.

--
Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com
-----------------------------------------------------
Understanding the ISA 2004 Access Rule Processing
http://www.isaserver.org/articles/IS...cessRules.html

Microsoft Internet Security & Acceleration Server: Guidance
http://www.microsoft.com/isaserver/t...dance/2004.asp
http://www.microsoft.com/isaserver/t...dance/2000.asp

Microsoft Internet Security & Acceleration Server: Partners
http://www.microsoft.com/isaserver/partners/default.asp
-----------------------------------------------------






 
Reply With Quote
 
 
 
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
RRAS Internal interface using APIPA address, ignoring both DHCP an Jacques Assert Windows Networking 5 05-05-2008 02:59 AM
RRAS internal network address Dellboy Windows Networking 2 04-03-2007 09:24 AM
PPPoE fails on RRAS, works on standard connection hjbotha@gmail.com Windows Networking 0 03-08-2007 02:06 PM
Using RRAS to assign an external IP to an internal machine nick.malyon@gmail.com Windows Networking 2 12-23-2006 02:02 AM
Protect RRAS Internal Interface Stanislav Sviridenko Windows Networking 2 06-03-2004 03:51 AM



1 2 3 4 5 6 7 8 9 10 11