cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
410
Views
5
Helpful
4
Replies

3005 Concentrator in PIX DMZ

akciscoman
Level 1
Level 1

Hi all,

I’ve setup the concentrator going through the PIX I’ve placed it in a DMZ with the public interface directly connected to the internet and the private connected to the DMZ.

I can connect to the concentrator on its private interface (from our network to DMZ) to administer it. I have set up static mappings in to the DMZ for the servers we need access to with VPN and I can ping those servers from the concentrator. When I connect in with WebVPN I can connect to those servers no problem.

The problem is when I connect using the VPN client. When using the client the users can connect in and are authenticated using NT authentication (can connect to our domain controller for authentication) but after that they cannot access the servers I have mapped into the DMZ. I have setup a pool of addresses for VPN client users and have made sure that these addresses are not NATed on the firewall using ‘NAT 0 192.168.2.0 255.255.255.0’ 192.168.2.0 are the pool of addresses VPN clients are assigned. Also setup the access lists on the firewall and the hit counts are going up when I ping but no connection. It seems the client addresses are not connecting through the PIX.

Ideally I would like to set up pools or individual addresses on the concentrator and control access on the PIX as to what access those assigned IP address have.

Has anyone done this before can anyone help, please...

4 Replies 4

msrohman
Level 1
Level 1

akciscoman,

I have set up something like this in the past. Could you clarify some details?

1. "I have set up static mappings in to the DMZ for the servers we need access to with VPN "

- I'm interpreting that the servers reside on the 'inside' network. In addition, you have static NAT mappings (inside,dmz) so that the VPN clients can access them coming from the 'DMZ' network. Is this correct?

If so,

You might want to :

1. Check your NAT statements. NAT/Global are used when traffic initiates from higher security interface to a lower security interface. Static is used when you initiate traffic from a lower to a higher security interface. The VPN client addresses are coming from the DMZ. It has a lower security number than the inside.

2. The PIX , by default, blocks traffic initiating from a lower to a higher security interface. Make sure you have an ACL allowing your VPN client pool into the 'inside' network.

3. If you think your NAT and ACLs are set up correctly, then make sure your routes are set up on the Concentrator and PIX correctly (for the VPN client address pool).

4. Does the VPN concentrator have any network lists applied to the IPSec group? Can you ping from a VPN client to the VPN concentrator private interface?

I hope this helps.

-Mike

just a quick add-on.

concentrator itself is not a firewall, and hence it is not capable to protect itself from internet attack such as dos.

providing there is a spare interface on the pix, then you may connect both public and private interfaces on the pix.

alternatively, personally i rather connect the public to the dmz and the private directly to the lan.

Jackko, that's a great add-on.

We had set up a design sometime ago that involved two DMZs. One for the Public interface of the VPN 3000 and one for the Private interface.

It took a few days to get it working , but it was stable once in production use.

-Mike

Guys many thanks for your replies I have now discovered what the problem was. The ip addresses that I had assigned the VPN clients was on a different subnet so they would connect in and then have no connectivity on the DMZ which is why web VPN worked, I believe you assigned the ip address of the private interface with web VPN hence why it worked and VPN clients didn’t, simple really.

In answer in your reply jackko I agree it is a good idea to have the public interface also protected but I only have one interface on the PIX available and so need to consider what is more of a priority, protecting the public interface or internal LAN from a variety of VPN users. The reason why I say this is because I can assign ip addresses once VPN users are connected in I can restrict access to the LAN on these address so I know who can do what, for example external suppliers only have access to the servers they require on RDP or certain internal users can only get to specific resources on the LAN.

With protecting the external interface, not knowing the specific IP addresses that required access in it would be difficult for me to setup efficient access rules.

Maybe I’m wrong but from my understanding I believe this is the best approach, any thoughts would be appreciated.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: