Hello: We currently have a PIX Box. Our network is set up so that the PIX is the default gateway. When I add the Cisco 3015 I will put one interface on the inside (parallel to the PIX) and one interface on the outside (parallel to the PIX on the outside) The Cisco 3015 will bring users past the pix and into the inside RFC1918 network. Now how does the computer on the inside know how to get out via the 3015 when it has a default gateway set to the PIX.
I'm not sure I understand what you are trying to accomplish. We certainly want to keep the PIX as your gateway for proper firewalling from the outside. If there is a path around the PIX, hacking or security breaches are likely to occur. If all interfaces of the 3015 are staying inside, no problem. You'll gateway all your hosts to it and then gateway it to the PIX inside interface. What are you hoping to accomplish with the 3015?
I'm trying to accompolish the following: I want it to terminate the VPN tunnels from the IRE or Altiga clients at remote sites. I've done this with the PIX but felt the 3015 would be more suited for the task than the PIX. Those terminated tunnels would of course need access to the private address space. Are you saying that there's a way to put the 3015 upstream from the PIX (outside the firewall) and have the 3015 send traffic through the PIX into the inside? If so then that's what I'd like to do.
Do you recommend any good documentation on the topology of attaching the 3015 to a site where a PIX is the primary firewall. I attended Networkers and got a feel for some of the methods but the 4hr session couldn't cover everyone's topology.
Well, I can't recommend that you terminate your VPN tunnels outside the firewall. If you don't want to use your PIX to terminate the tunnels, then I would go through it with a static and conduit to the 3015 which should reside on the inside. I think that's what another user on this thread suggested. Does anyone else have any experience with a similar topology?
I believe that the original poster is asking how to deal with gateways when implementing the network architecture as depicted on page 1-7 of the VPN 3000
Concentrator Getting Started Manual. In this diagram, the firewall box and the VPN concentrator
are connected in parallel between the public (untrusted) segment and the private (trusted) segment. The real question deals with the network configuration of the hosts/servers on the private (trusted) segment. What default gateway should these devices have configured so as to be reachable from the outside for VPN functions and simultaneously for
receiving (and replying to) permitted connections through the firewall.
If you are teminating your IPSec tunnels on the 3015, leave it inside behind the PIX and open statics and conduits to it to allow the VPN through.
Let's see if I can help you here...
You want to have the PIX and the VPN 3015 working in parallel, it can be done easily, but you will need to have also a Router on the INSIDE.
The router will be the default gateway for all the computers (any router works). You will need to add static routes on the Router pointing to the PIX for 0.0.0.0 and also a Static Route on the Router pointing to the Network that the VPN3015 will be using as pool of addresses. (you define this pool on the 3015 using RFC 1918 addresses). The VPN3015 can also do some routing and participate in OSPF. Which is a cool feature.
Regarding "the Static Route on the Router pointing to the Network that the VPN3015 will be using as pool of addresses", Where does that static route point to?
1) PIX inside interface
2) VPN (3015) inside interface
You really don't need the router. Set the 3015 up to use DHCP and each client will be issued an address after they pass authentication. The 3015 will proxy arp for these clients so every device in the network thinks they are local.
The OSPF comes into play for large corporate networks like yours where you have hundreds of IP subnets on the inside.
Suppose that the 3015 sits on the dmz interface of the PIX with the subnet 10.1.1.0/24 confgured on it. Now, if you use a range of addresses from this subnet to assign addresses to the VPN clients, the PIX will know that this subnet exists on its DMZ. So, even if you have no router on the inside, all the traffic which is sent to the PIX from the machines on the inside will be passed on by the PIX to the dmz interface.
OK...let me throw my 2 cents in here. If you hang one interface of the concentrator in your DMZ (public) and the other on a new VLAN that both your internal conecntrator interface and an external PIX interface sits you will accomplish a few things.
1) You will not dig into your existing RFC 1918 address space when allocating VLAN client addresses. You can create another RFC address space in that VLAN that you will assign to clients.
2) You will keep the VPN traffic going through the PIX.
3) If you are running redundant PIXs, you will keep your VPN Clients up and running if the PIX fails over since the secondary PIX assumes the config of the primary (MAC address and all). If you are directly connected to the PIX via crossover, you will disconnect VPN clients in the event of a failover.
4) When traffic comes back from your servers it is going go go to the new RFC 1918 address space which your PIX (the defaut gateway) will see as a directly connected network. Routing problem solved.
This of course means that you are running VLANs.
I have tested this in the lab and it works well.
Let me know what you think of this.
We are doing the same thing here. If you are using the VPN 3015 just for VPN clients, you create an address pool from IP's on your inside network's ip subnet and the LAN router doesn't care about the existance of the 3015, since the 3015 does proxy ARP for the VPN client IP's and they look like client PC's sitting on your inside network
If you are using the 3015 for LAN to LAN, set a default route to the PIX and the more specific address of the remote LANs as static routes on the LAN router pointing at the 3015 and we use 'redist static' (we don't use OSPF) - Hey Cisco - let's get EIGRP on the 3000 series too