• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 420
  • Last Modified:

DMZ Access over VPN

Here is the problem.

We have our DMZ on our Second Pix Firewall group.  We have a VPN that connects our 2 facilities using Cisco VPN Concentrators.  We can not get the VPN Traffic to route to the DMZ of the firewall.  Any ideas where the routing needs to be set up?  When doing a tracert we start loosing packets at the vpn.  When doing a tracert to the internat IP of the firewall, if makes it through?
0
thepilo
Asked:
thepilo
  • 4
  • 4
1 Solution
 
lrmooreCommented:
How is your VPN concentrator set up, with independent Internet access, or behind the PIX FW?

Internet
   |        |
 VPN    PIX - DMZ
   |____|
       |
     LAN

Does the VPN concentrator have a static route to the DMZ subnet pointing to the PIX?
Have you thought about enabling OSPF between the VPN 3000 and the PIX?

0
 
thepiloAuthor Commented:
The VPN is behind another PIX firewall that get's it to the out side.

Here is the setup

Our Side
T1-1    T1-2
 |           |
PIX        PIX ---DMZ
 |          |
 VPN      |
 |           |
 Switch--|

Remote Side

 T1
  |
 Pix
  |
 VPN
  |
Users
0
 
lrmooreCommented:
The VPN 3000 on Your side should have a static route for the DMZ subnet pointing to the #2 PIX
PIX #2 with the DMZ should have a route statement for the remote side subnet pointing to the VPN..

Do you have networks defined that includes the DMZ subnet for inclusion inside the VPN tunnel?
Does the VPN concentrator on the remote side include the local-to-DMZ subnet traffic in the tunnel definitions?
Does the VPN concentrator at your end include the DMZ subnet-to-remote subnet traffic in the tunnel definitions?
0
Evaluating UTMs? Here's what you need to know!

Evaluating a UTM appliance and vendor can prove to be an overwhelming exercise.  How can you make sure that you're getting the security that your organization needs without breaking the bank? Check out our UTM Buyer's Guide for more information on what you should be looking for!

 
thepiloAuthor Commented:
The VPN on our side has the followring route

192.168.14.0/255.255.255.0(IP subnet of DMZ) ->10.1.100.9 (Internal IP of PIX2)

The VPN Tunnel has it's own DMZ setup 192.168.11.0 for here, and 192.168.21.0 for remote site



0
 
lrmooreCommented:
The remote VPN concentrator must have the DMZ subnet in it's tunnel config:
i.e. traffic from 192.168.21.0 to 192.168.14.0 must be defined in the remote concentrator for the tunnel

Conversely, the VPN concentrator at your end needs to have the traffic from 192.168.14.0 to 192.168.21.0 defined as tunnel traffic.

And, the PIX2 must have a static route for 192.168.21.0 pointing to the VPN internal IP 10.1.100.x

0
 
thepiloAuthor Commented:
We have set 192.168.14.0 in network lists under policy management.  We have a route on the local vpn for 192.168.14.0 -> 10.1.100.9  

The web server has a static route for 10.2.100.0 to the 192.168.14.1 firewall.  The switch has a route from all traffic on 10.1.100.0 to go to the local VPN 10.1.100.15

Not sure what I am missing....
0
 
jaysonjenningsCommented:
Perform a debug packet inside on PIX2 for traffic destined towards the DMZ from the source of the remote network.  Thus get you some visibility;
If you have version 4 of the VPN conc code, you can perform a traceroute to determine the VPN knows the location of the DMZ.  As lrmoore indicates, OSPF would be a nice solution.
0
 
thepiloAuthor Commented:
We have goe the solution.  There was no static allowing traffic from the DMZ back to the 10.2.x.x network.  We have added that, and are good to go for that network.  We have one last issue of adding the 192.168.14.0/24 network to a 506E firewall/VPN   And idea on how to set the network list like you can in the concentrator under policy management?
0
 
lrmooreCommented:
You add it to the access-list called out in the "match access-list xxxx" under the crytpo map
0

Featured Post

Become an Android App Developer

Ready to kick start your career in 2018? Learn how to build an Android app in January’s Course of the Month and open the door to new opportunities.

  • 4
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now