Need to let users into Intranet - What are my options - I have a PIX

[stownsend]

Here is the main focus of what we want to do.

We want to be able to allow remote-dial-in and SOHO users (50 or so simultaneous) access to the corporate servers behind the PIX firewall.

The Remote users are connected to the internet via Cable, DSL, Satellite or dial-in modem. Some of the users are using a public routable IP address from the ISP and some are using private addressing behind a NATd device. Most of them have a LinkSys Cable DSL Router at home.

We would like to authenticate the remote uses with an Assigned Certificate from a Microsoft CA Enterprise Server. We would like to revoke the Certificate at any time and disallow access once the new CRL has been published.

As an added feature we also have a Technical Service Office that has a DSL Connection to the internet. Currently they are only connected to the internet and not to the Corp Office.

We want to allow them to keep the connection to the internet and then use a Frame-Relay network for connection to the Corp Network. We were going to have the Router in that office route all traffic for the local Intranet (10.x.x.x) to the Frame router and then all of the other internet traffic would go though it to the DSL Connection. We have an 827 that we planned on using for this. We would also like to be able to use the DSL connection as a backup VPN connection to the PIX in the event of a communication failure from the Tech office Frame Connection.

We would like to be able to use the PIX for the VPN termination point for the remote users and for the Tech Service Office.

With the help of others on the internet and the CCO Forums I have been able to get the MS CA Server Certificates and CRL to work on the PIX. So my main concern is getting the Remote Clients to connect behind a NAT device. I have been close in getting this to work, though its spotty at best.

I’d like to discuss my options.

Thanks!

Scott<-

[kdurrett]

Scott,

You dont have many options here. Connecting a client from behind a NAT/PAT device to the pix just wont work unless:

1. You have a static one to one NAT translation

2. The device is capable of doing nat some type of esp translation, which was introduced in Cisco IOS 12.2.5T I do believe. Cisco allows you to do a static NAT translation for the protocol ESP to a single ip address. Downside is that it allows only 1 connection through. Some other low end devices, like Linksys are capable of doing this as well. Linksys will allow a single client connection, think you have to run 1.4.3 version when its doing port address translation. If the device doesn't have this capability, then it wont connect to the pix if the clients are being port address translated. I've seen some other post that state that 6.3 will support this feature you are looking for, contact your local sales account rep for more infomation. But unless the nat device supports a ESP translation, then you'll either have to wait, get more ip's or build a L2L tunnel instead of the client connection.

Kurtis Durrett

[stownsend]

Hello Again Kurtism, Thank you for the reply.

The NATing is taking place on the LinkSys router. Its WAN address is a public IP and the LAN address is a 192.168.1.x address. The Client I’m using is the Cisco VPN Client v3.6.1 I really only care about one client behind the LinkSys to get access to the Intranet. They may be more clients behind the LinkSys, but only one needs to connect.

While trying to get the Client to work with MS CA Certs (Case ID D167855) I was informed that Clients behind a NAT device is not an option with the PIX and is only available on the Concentrators and it may or may not be available on the PIX next April.

I have 1 LinkSys Routers, A BEFSR41 and a BEFSX41, both of which have the 1.43.3 Firmware. I can Almost make a Connection with the BEFSR4. I can Authenticate with the PIX and the PIX gives me an IP address, though I cant route any traffic.

The BEFSX41 on the other hand I cant do anything with. I've set it up just like the other and I get nothing. I then Tried to get the LinkSys VPN Router (BEFSX41) to terminate an IPSec connection to the PIX. (Case ID D231825) the First Engineer told me that its not an option and is not supported. Then trying to get PPTP to have multiple VDPN groups (Case ID D288902) (Which isn’t possible unless you have a RADIUS/TACACCS Server) I got a hold of another Engineer who has said that he has made the LinkSys VPN router talk to a PIX before and he was un able to get mine to talk to each other.

I’d really like to just have the VPN Client installed on everyone’s PC and just use that for Access and not the LinkSys VPN Router.

So I guess my other embedded question was is using the PIX the 'right' solution?

Thanks agin for your help,

Scott<-

[kdurrett]

The pix is a good solution, only problem is its not fitting your needs right now due to the client side issues and features not quite yet supported on the pix. A 3005 concentrator, depending on number of connections you need, in liu of the pix would solve your immediate needs with out having to upgrade all the client sites.

Client side issues with your linksys our related to CSCdv62613(your cert problem which is Linksys Issue) and CSCdu86399 (ipsec over udp-like to concentrator, another linksys issue).

But if you are able to connect with the BEFSR4 but not pass traffic, it could be a routing or a NAT/PAT issue. Something you can check into. Connect to the pix, ping internal pc(not the pix), do a "show crypto ipsec sa" and see if you are getting encrypts/or decrypts on the pix for your connection. If you are getting decrypts with no encrypts, then you have some type of nat/pat or routing issue on the pix side. You could also try lowering your MTU on client and make sure your not denying icmp anywhere as well. If you are't getting decrypts, the traffic isn't reaching the pix, make sure you are encrypting on the client side. If you are getting decrypts and encrypts on the pix, then you should look client side. Maybe the linksys or some type of personal firewall on your pc....etc.

Kurtis Durrett

[stownsend]

Here is the output from ' sh cry ipsec sa'

Looks like the packets are not getting to the PIX.

I wont hold you to any dates or anything, but do you have an estimate when 6.3 will be out? I was told April maybe?

outbound pcp sas:

local ident (addr/mask/prot/port): (10.0.0.0/255.0.0.0/0/0)

remote ident (addr/mask/prot/port): (10.200.0.1/255.255.255.255/0/0)

current_peer:

dynamic allocated peer ip: 10.200.0.1

PERMIT, flags={}

#pkts encaps: 0, #pkts encrypt: 0, #pkts digest 0

#pkts decaps: 0, #pkts decrypt: 0, #pkts verify 0

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0

#send errors 0, #recv errors 0

local crypto endpt.: , remote crypto endpt.:

path mtu 1500, ipsec overhead 56, media mtu 1500

current outbound spi: 755275dc

inbound esp sas:

spi: 0xb78776e9(3079108329)

transform: esp-des esp-md5-hmac ,

in use settings ={Tunnel, }

slot: 0, conn id: 2, crypto map: my_cry_map

sa timing: remaining key lifetime (k/sec): (4608000/3354)

IV size: 8 bytes

replay detection support: Y

outbound esp sas:

spi: 0x755275dc(1968338396)

transform: esp-des esp-md5-hmac ,

in use settings ={Tunnel, }

slot: 0, conn id: 1, crypto map: my_cry_map

sa timing: remaining key lifetime (k/sec): (4608000/3309)

IV size: 8 bytes

replay detection support: Y

[kdurrett]

The Cisco response would be to contact your local account manager for more details on expected delivery date. I do know they just started beta testing it so it should be sooner than April. BTW, do you have a firewall on the client? Is the client encrypting packets? Is there a firewall feature turned "on" on the linksys? Just some other things to check.