Best approach to vpn through two firewalls

[tuliphead]

I have the following scenario:
- One external netscreen firewall that is connected directly to the internet
- One internal firewall that further protects some internal subnets

Internet <--- External Firewall ---> DMZ <--- Internal Firewall ---> Internal subnets

Only the external firewall has a public ip-adress.
What is the best approach for a IPsec VPN connection to the internal subnet? I know how to get a functional vpn connection to the external firewall, but how do I proceed from there? When the connection is up, the user should be able to reach the internal subnet. I get a bit lost when it comes to vpns that goes through more than one FW. How do I allow access to other network segments than the ones that is directly attached to the vpn firewall?

Any hints/tips/ideas on how to proceed?

 

[Packet7]

Hi,

OK, I'm guessing you already have an IPSec VPN configured on your External FW and you want to permit VPN connectivity to your Internal subnets behind the second FW?

If so, the following will help.

- Are we talking site-to-site VPN's between two external Netscreens, Cisco, CheckPoint? or are they IPSec VPN clients (Netscreen Remote, etc).
- Are they Policy Based VPN's or Route Based?
- Does the Internal Firewall configured for NAT between the Trust and DMZ zones?
- Is the internal FW configured in transparent mode (layer 2)

Let me know.



Rgds,

John

 

[tuliphead]

>OK, I'm guessing you already have an IPSec VPN configured
>on your External FW and you want to permit VPN
>connectivity to your Internal subnets behind the second FW?

Only the internet interface on the externel FW is configured with a public adress. All other network ID's is private. Your guessing is correct. All my earlier experience is related to giving users VPN access to a subnet that is directly connected to the external firewall itself. Now, that the access thing is spanning through two firewalls it got a bit more complicated.

>Are we talking site-to-site VPN's between two external
>Netscreens, Cisco, CheckPoint? or are they IPSec VPN
>clients (Netscreen Remote, etc).

Users are IPsec VPN clients via the Netscreen Remote client software. They will connect to this network from any pc on the internet and their only point of access will be the first FW (the extneral one)

>Are they Policy Based VPN's or Route Based?

I guess the answer for this would be policy based.

>Does the Internal Firewall configured for NAT between the Trust and DMZ zones?

NAT would not be necessary since only the external FW is directly connected to public adresses. The internal FW is solely handling private adresses. So no NAT would be necessary here.

>Is the internal FW configured in transparent mode (layer 2)

Both FW's is configured in routing mode. They are functioning as both routers and firewalls. The bit that I am trying to figure out is how to tell the internal firewall that some user that connects to the external firewall (through VPN) should have access to a subnet that is connected to the internal FW.

Do you have a more clear picture of the situation now?

Oh, BTW both FW's is Netscreen (no Cisco or any other third party products)

 

[Packet7]

OK, that helps. Can you summarize your subnets? For example, we send all 10.0.0.0/8 traffic from our NSR (Netscreen Remote) clients over the VPN. All other traffic is sent out the local internet at the clients LAN. This is called split tunneling.

This summary is defined in the "Remote Party Identity and Addressing" and controls what traffic the NSR client encrypts and injects into the tunnel. How is currently configured?

Since this is a Policy Based VPN, you will need to make sure the above subnet matches the object in your Policy. If not, you will probably get a proxy-id mismatch and the VPN would fail.

Once the NSR client and VPN Policy is changed, you will most likely need a route. Are you using an IP Pool with the NSR clients? If so, you will need to make sure both Firewalls can route that network. If you NSR clients can ping resources on the Internal Network, I would test from your trust interface on the external FW. Make sure the FW can reach the other subnets first. I'm guessing you will have to modify the FW policy on the internal FW and add a few return routes (IP Pool, etc).

If you have any more questions, let me know.



Rgds,

John