PIX 501 VPN RAS

I have recently started to (attempted to) use a PIX 501 firewall on our network, the consequence being the MS VPN connection does not seem to be working properly.

Being complete novices when it comes to PIX I need some advice on how to configure the PIX to pass the VPN traffic to a RAS server.

The network set-up is:

INTERNET Netgear DG814 PIX ------(Intranet)

By intranet, I mean there are three servers connected to the PIX firewall. (Internet Server, Mail Server and the RAS Server).

Basically, (I think!) I need to know how to route all PPTP traffic to the RAS server.

If I have it totally wrong, please feel free to ridicule... Also if you are so kind as to reply, please pitch the answers as if you are explaining to the local village idiot, so I can understand

Thanks in advance

Tony

PIX version is : 6.3(5)

Reply to
POP3.demon.co.uk
Loading thread data ...

Use Transport-Mode and disable PFS, to get MS IPSec working. Use vpdn for L2TP.

You need a public address on the pix outside interface.

You need 1:1 NAT (static) for this single server. Otherwise GRE (using PPTP) will not be forwarable. Allow TCP/1723 and GRE from outside.

You need at least two fixed, public addresses on the pix outside interface.

Reply to
Lutz Donnerhacke

Hi Lutz

I am slowly starting to understand (I think)

I am still a little confused over having to need two fixed public addresses

We currently have one fixed IP from the ISP which connects to a Netgear router which acts as a DHCP server and gives out an IP address to the PIX. I would like to know if it is possible to use these DHCP addresses instead of the fixed public ip addresses.

I have a diagram off the Cisco site which seems to indicate only one is needed. I do not mean to offend but can you explain why the following will not work (or rather where I am getting confused)

192.168.1.1 204.69.198.2 204.69.198.1 Server (192.168.1.4) >>>>@ (inside) (outside) (Gateway) Server (192.168.1.15) >>>@>>>>>>>>>>>> [ PIX ] >>>>>>>>>>>>>>>>>>>>> [ ROUTER ] >>>>>>>>INTERNET Server (192.168.1.10) >>>@ 192.168.1.0/24 204.69.198.0/24

Many thanks

Tony

Reply to
POP3.demon.co.uk

Sorry, that hasn't come out too well has it....

How can I get a copy of the diagram to you Lutz?

Reply to
POP3.demon.co.uk

So the Pix itself is behind NAT. => Forget about PPTP (Windows VPN) Forget about L2TP over native IPSec (Windows VPN)

You will need at least a patch for Windows (NAT traversal). Futhermore connecting to a NATted server is not supported in Windows.

PPTP is not supported by PIX itself. If you want to use a Windows Server as RAS device, you will need to forward GRE protocol, which does not contain any session information. In order to forward this protocol, the PIX must know which session refers to a single packet. Because the payload of the GRE packet is encrypted the only usable value is the IP address. Therefore you need a distinct public IP address for such PPTP connections. PIX 7.0 contains an educated guess algoithm which might remoce this restriction.

L2TP over IPSec is supported by PIX itself. Therefore you can use a single address. Unfortunly IPSec is not specified for NAT enviroments, so you have to use a public address on the PIX. PIX 7.0 does not support L2TP over IPSec.

If possible, drop the Netgear router from your setup.

Reply to
Lutz Donnerhacke

Hi Lutz

This is getting complicated! I had hoped it would be a little easier... I am thinking that I may start again from the beginning.

If you get a moment could you give me the benefit of your knowledge and recommend how I should set up a simple VPN.

We have a Win2003 server (if relevant), obviously we have the PIX501 and Netgear ADSL router.My only requirements are that I must be able to use Terminal Server and be able to access any drive on any server on our network.....

Even if it meant buying additional equipment, how would you set up a VPN?

Please.....

Tony

Reply to
POP3.demon.co.uk

1) Remove the Netgear. 2) Connect the pix to the DSL modem and configure the pix to PPPoE. 3) Configure IPSec with a dynamic-map to transport mode without PFS. 4) Configure vdpn (the PIX' l2tp server implementation) 5) Connect with your clients.

It's preferable to set up a CA and radius server inside your network first and use those to authentificate the clients.

Reply to
Lutz Donnerhacke

What leads you to say that?

vpdn group NAME accept dialin pptp

formatting link

There was a short thread last year sometime pointing out that GRE does have session information, and that at least one vendor was successfully nating on that (by manipulating the session identifier). GRE does not have ports, though.

Not quite true.

formatting link
the Call ID is in the GRE header and unenrypted.

Only AH is a problem in NAT, and RFC 3947 on NAT-Traversal deals with that.

: PIX 7.0 does not support L2TP over IPSec.

vpn-tunnel-protocol L2TP/IPSec

formatting link

Reply to
Walter Roberson

Bad experience.

If the VPN is "private", the content is encryptet. Windows might build tunnels without encryption. All implementations of GRE forwarding I saw, exploit the timeing between initial session setup (via TCP) and data packets.

Thanx for the info. This is quite unusual for GRE AFAIK.

The implementations out there does not support an RfC but a number of drafts and serveral proprietary variants. Especially "server behind NAT" is not well supported. Even on PIX.

Did you ever tried it on a real device? There is no implementation out there (it might be added in the latest interim releases.)

Reply to
Lutz Donnerhacke

In article , Lutz Donnerhacke wrote: :* Walter Roberson wrote: :> Lutz Donnerhacke wrote: :>>PPTP is not supported by PIX itself.

:> What leads you to say that?

:Bad experience.

We've had PPTP terminated on our PIX 6.x without any difficulties. We've never done a lot of PPTP, but we didn't have any difficulties.

Re: GRE:

An RFC1701 compatable implementation can use the KEY field or the Sequence Number field.

RFC 2784 deprecates those fields, but allows for RFC 1701 compatable receivers.

Thus, one could be compatable with RFC 2784 by:

- manipulating the KEY or Sequence Number fields if already present

- adding a KEY or Sequence Number field if none was already present -- knowing that the device at the other end will strip them off before forwarding them on.

Then there is RFC 2890, which essentially adds the key and sequence number fields back in again. From RFC 2890:

The Key field is intended to be used for identifying an individual traffic flow within a tunnel. For example, packets may need to be routed based on context information not present in the encapsulated data. The Key field provides this context and defines a logical traffic flow between encapsulator and decapsulator. Packets belonging to a traffic flow are encapsulated using the same Key value and the decapsulating tunnel endpoint identifies packets belonging to a traffic flow based on the Key Field value.

which is pretty much exactly what you need to track individual GRE flows through NAT.

Reply to
Walter Roberson

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.