VPN access to LAN using RRAS on W2K *behind* firewall?

[Bo Berglund]

We have used a RRAS server (Windows 2000 server) as a VPN gateway into
our internal LAN for quite some time now. It works good as far as we
could see. In parallel to this is the ordinary firewall used for all
browsing, email and other Internet traffic. This was originally a
Proxy Server 2 server, but it was replaced by a Symantec firewall a
while back when PS2 could not handle all the attacks anymore.

Now the issue has been raised that the VPN server is acting like a
backdoor to our LAN and really should be taken out. A security
consultant tested it and said it leaks while the new FW is tight. But
us remote users *really* need to get in on the internal LAN via a VPN
solution...

So what we are asking now is if it is possible to have a solution
where the VPN traffic coming in to the new firewall can be directed to
the RRAS server, now entirely on the internal LAN (using only one
NIC?). Can such a solution get us authenticated to then use the LAN
resources via the tunnel?
And how can it be set up? We are not experienced in this
(amateurs...).
Maybe the RRAS server should still have two NIC:s, one with an IP on
the internal LAN and one randomly chosen outside that network. Then
the FW would send everything that comes in as VPN packets (on ports
17xx somewhere) to that special address and then it would authenticate
in the RRAS server.
Is this workable?
/Bo

 

[Bill Grant]

This shouldn't be a problem. If your VPN is working OK, you should be able
to transfer it behind the firewall, using only one NIC.

What happens is that the firewall takes the place of your "public" NIC.
Instead of connecting directly to the Internet, the server has its default
gateway set to the firewall's private IP address. The encapsulated and
encrypted data goes to the firewall via the LAN and is delivered as normal
through the Internet.

Because the server now doesn't have a direct connection to the Internet,
the clients have to connect to the firewall. You can forward tcp port 1723
from the firewall to the RRAS server's LAN IP to transfer the incoming VPN
traffic from the firewall to the RRAS server.

You need to ensure that your firewall allows GRE in both directions.
Generic Routing Encapsulation (IP protocol 47) is used by RRAS to transfer
the VPN data. (The encrypted data travels as the payload of a packet with a
GRE header). So GRE must be allowed in both directions by the firewall, or
VPN traffic will fail.

Solutions with two NICs can be used, but they are not really needed in a
setup like this. The one NIC solution should do everything your current
setup does, and have the added protection of the firewall.

 

[Bo Berglund]

This shouldn't be a problem. If your VPN is working OK, you should be able
to transfer it behind the firewall, using only one NIC.

What happens is that the firewall takes the place of your "public" NIC.
Instead of connecting directly to the Internet, the server has its default
gateway set to the firewall's private IP address. The encapsulated and
encrypted data goes to the firewall via the LAN and is delivered as normal
through the Internet.

Because the server now doesn't have a direct connection to the Internet,
the clients have to connect to the firewall. You can forward tcp port 1723
from the firewall to the RRAS server's LAN IP to transfer the incoming VPN
traffic from the firewall to the RRAS server.

You need to ensure that your firewall allows GRE in both directions.
Generic Routing Encapsulation (IP protocol 47) is used by RRAS to transfer
the VPN data. (The encrypted data travels as the payload of a packet with a
GRE header). So GRE must be allowed in both directions by the firewall, or
VPN traffic will fail.

Solutions with two NICs can be used, but they are not really needed in a
setup like this. The one NIC solution should do everything your current
setup does, and have the added protection of the firewall.

To ensure that I unsrestand this:
Does this mean that the following setup is viable?

[Intratet PC:s and servers]
|--[Primary Domain Controller]
|
|--[VPN server] W2000 server with RRAS
|
[Company Intranet]
|
[Firewall] Symantec Raptor FW
|
[Internet]
|
|
[ADSL firewall] NAT to Internet
|
[Home network]
|
|--[Client PC] Win-XP-Pro using PPTP dialup

Can we open up port 1723 on the Firewall and tell it to send all such
packets to the VPN server (on its single NIC)? Or maybe only the
packets conforming to the Internet protocol 47?
Will the VPN server then authenticate the PPTP connection and channel
the network traffic out onto the Intranet through its NIC?

I was always supposing that a VPN server needed to have 2 NIC:s and
channel traffic through from one NIC to the other....

/Bo

 

[Bill Grant]

That is essentially correct. Forwarding port 1723 from the router to
the server's LAN IP effectively means that the firewall doesn't try to
process the packets - it just forwards them through the LAN. So the VPN
server is effectively getting the encrypted data, just as it was before. In
the other direction, the server is doing the encryption and encapsulation as
before, but sends the traffic to the firewall rather than directly to the
client. The firewall sends it on, just as it does any other packet addressed
to a public IP. (The encapsulated packet has the client's public IP as the
destination on the outer wrapper).

The GRE thing is a bit complicated. PPTP (which uses tcp port 1723) only
controls the setup and maintenance of the VPN tunnel. The actual data is
transferred as the payload of an IP packet with a GRE header. So the router
must allow the GRE protocol in both directions, or the VPN data will be
blocked. You will have a VPN tunnel, but no data will go through it, so it
will very soon time out!

This shouldn't be a problem. If your VPN is working OK, you should be able
to transfer it behind the firewall, using only one NIC.

What happens is that the firewall takes the place of your "public" NIC.
Instead of connecting directly to the Internet, the server has its default
gateway set to the firewall's private IP address. The encapsulated and
encrypted data goes to the firewall via the LAN and is delivered as normal
through the Internet.

Because the server now doesn't have a direct connection to the Internet,
the clients have to connect to the firewall. You can forward tcp port 1723
from the firewall to the RRAS server's LAN IP to transfer the incoming VPN
traffic from the firewall to the RRAS server.

You need to ensure that your firewall allows GRE in both directions.
Generic Routing Encapsulation (IP protocol 47) is used by RRAS to transfer
the VPN data. (The encrypted data travels as the payload of a packet with a
GRE header). So GRE must be allowed in both directions by the firewall, or
VPN traffic will fail.

Solutions with two NICs can be used, but they are not really needed in a
setup like this. The one NIC solution should do everything your current
setup does, and have the added protection of the firewall.

To ensure that I unsrestand this:
Does this mean that the following setup is viable?

[Intratet PC:s and servers]
|--[Primary Domain Controller]
|
|--[VPN server] W2000 server with RRAS
|
[Company Intranet]
|
[Firewall] Symantec Raptor FW
|
[Internet]
|
|
[ADSL firewall] NAT to Internet
|
[Home network]
|
|--[Client PC] Win-XP-Pro using PPTP dialup

Can we open up port 1723 on the Firewall and tell it to send all such
packets to the VPN server (on its single NIC)? Or maybe only the
packets conforming to the Internet protocol 47?
Will the VPN server then authenticate the PPTP connection and channel
the network traffic out onto the Intranet through its NIC?

I was always supposing that a VPN server needed to have 2 NIC:s and
channel traffic through from one NIC to the other....

/Bo

 

[Ugo Mangini]

"Bill Grant" <bill_grant at bigpond dot com> ha scritto nel messaggio

[cut]

sorry, can I ask you something on my own?

do you mean that a configuration like:

- lan ip 192.168.10.xx 255.255.255.0

- win2000 server 192.168.10.1 running terminal services

- firewall (lan gateway) lan ip 192.168.10.254 - wan ip 192.168.1.254 -
static routing table 0.0.0.0 => 192.168.1.253 (router)

- internet router lan ip 192.168.1.253 wan ip assigned by Isp

would work correctly having a second (public) ip address on the win2000
server?

thanks in advance
bye

 

[Bo Berglund]

That is essentially correct. Forwarding port 1723 from the router to
the server's LAN IP effectively means that the firewall doesn't try to
process the packets - it just forwards them through the LAN. So the VPN
server is effectively getting the encrypted data, just as it was before. In
the other direction, the server is doing the encryption and encapsulation as
before, but sends the traffic to the firewall rather than directly to the
client. The firewall sends it on, just as it does any other packet addressed
to a public IP. (The encapsulated packet has the client's public IP as the
destination on the outer wrapper).

The GRE thing is a bit complicated. PPTP (which uses tcp port 1723) only
controls the setup and maintenance of the VPN tunnel. The actual data is
transferred as the payload of an IP packet with a GRE header. So the router
must allow the GRE protocol in both directions, or the VPN data will be
blocked. You will have a VPN tunnel, but no data will go through it, so it
will very soon time out!

Thanks, I tried at home where I have an ADSL "firewall" between the
incoming network and my home net. I set it up like this:

|--[Home PC] Win-XP-Pro
|--[VPN server] W2000 server with RRAS
|
[Home network]
|
[ADSL firewall] NAT to Internet, opened PPTP port 1723 to VPN server
|
[Internet]
|
|--[Remote PC] Win-XP-Pro using dialup plus PPTP dialup

On the Remote PC I dialled into Internet using a modem, then used
another Dialup, this time the VPN one to the home network.
And it worked the first time around.
The Dlink Router/Firewall has a predefined "server" called PPTP so I
just opened it and set its internal target IP. The Raptor might be a
different animal altogether...

But there was another problem, I could not get the name resolution to
work properly. For example I could not get a drive mapping to my home
PC, the response was that no such share was detected. I even tried
adding the home PC IP to the hosts file and specifying the IP instead
of the PC name when I tried creating a drive mapping - no dice.
But if I used Remote Desktop on the home PC from the remote it worked!
So why does some connections fail and others work?

Well, this was really a test. The real job is to get the 1723 traffic
through the Symantec Raptor FW into the company LAN to the VPN server,
but now I know that the VPN NIC can be removed from the Internet in
any case.

Thanks again!

/Bo

 

[Bill Grant]

No Ugo, don't go that way. It leads to all sorts of complications. Stick
to using just one NIC in the server and use port forwarding to get the
connection extended to the server's LAN IP.