Solved

OSFP routing on a Cisco PIX to a Cisco 3640 through a VPN tunnel.

Posted on 2004-09-16
5
428 Views
Last Modified: 2013-11-16
I have a Main office that has a PIX with router behind it and a remote office that only has a PIX only.  The 2 PIXs have a VPN tunnel established between the two of them.  The internal network of the router has to be able to communicate with the inside network on the remote PIX.  I know that the PIX 6.3 software has the ability to use OSPF.  I was trying to setup OSPF between the router at the main office to the PIX at the remote office.  Does any one know how to setup OSPF on the PIX?  Also, part of my problem is that I don't know how I should setup my static route statements.  The traffic has to pass through the VPN tunnel in order to get to the other side.  I'm not sure what to make the Next-Hop.  I'll try my best to provide a diagram.  

The network Behind RouterA is 192.168.100.0/23.  The network behind PIX1 is 192.168.98.0/24.  The network behind PIX2 is 192.168.5.0/24.

The current OSPF configuration for ROUTERA is
router ospf 11
 log-adjacency-changes
 network 192.168.5.0 0.0.0.255 area 0

The current OSPF configuration for PIX2 is
router ospf 10
  network 192.168.100.0 255.255.254.0 area 0
  log-adj-changes
                                  .1          .252   .1    __________________VPN TUNNEL________________      .1
192.168.100.0/23|-------ROUTERA-----PIX1----INETROUTER------INTERNET------INETROUTER-----PIX2------| 192.168.5.0/24
                                                  ^          
                                              192.168.98.0/23
0
Comment
Question by:tomytek
  • 2
  • 2
5 Comments
 
LVL 79

Expert Comment

by:lrmoore
ID: 12079813
Unless you have another router(s), like a WAN, on the back side of RouterA that needs to get to the LAN behind PIX2, you don't need OSPF.

Router A has default gateway pointing to PIX1
PIX 1 has a VPN rule that takes traffic destined to LAN B 192.168.5.0, encrypts it and sends it to the PIX2 outside interface to be decrypted.
Users/systems on LAN B have the PIX2 .1 interface as their default gateway. PIX2 takes all traffic destined for LAN A, encrypts it and sends it to PIX1 public IP to be decrypted and forwarded on to LAN B

The only routes you need are:
Router A:
  ip route 0.0.0.0 0.0.0.0 192.168.80.1
PIX1:
  route 0.0.0.0 0.0.0.0 <inetrouter>
PIX2
  route 0.0.0.0 0.0.0.0 <inetrouter>

The IPSEC policy and "match" statements, with access-lists to define the VPN tunnel traffic is all you need.

IF you have more networks behind router A, and you already have OSPF enabled, then all you need to do is make sure it is the default gateway, and add all the appropriate subnets into the VPN tunnel definition..

0
 
LVL 5

Expert Comment

by:epylko
ID: 12080475
Also, you can't run OSPF across an IPSec tunnel. IPSec doesn't support multicast. If you really want to run OSPF across a tunnel, you need a GRE tunnel and then encrypt the GRE packets. The OSPF data will happily pass across the internet that way.

That being said, lrmoore is right, you don't really need OSPF for this situation. Static routes will probably work much better (ie less problematic) for you.

-Eric
0
 
LVL 1

Author Comment

by:tomytek
ID: 12081512
There are actually host/computers behind the Router and there are hosts/computers behind the remote PIX.  The computers from the Main Office have to be able to communicate with the computers at the remote office.  Here is a better picture of the topology http://www.geocities.com/tommy0308/vpntopo.html.  I guess static routes would be better to use since there are not routers behind the networks.  I already have the route statements that lrmoore suggested entered.  The following are the access-lists that I have used to define interesting traffic.

Main Office PIX
access-list 110 permit ip 192.168.100.0 255.255.254.0 192.168.5.0 255.255.255.0
access-list 110 permit ip 192.168.98.0 255.255.254.0 192.168.5.0 255.255.255.0
Remote Office PIX
access-list 110 permit ip 192.168.5.0 255.255.255.0 192.168.100.0 255.255.254.0
access-list 110 permit ip 192.168.5.0 255.255.255.0 192.168.98.0 255.255.254.0

I am still not able to ping across the tunnel from the remote to the 192.168.100.0/23 network and back the other direction.  I am able to ping accross from the remote to the 192.168.98.0/23 network and back.  Are there static routes that I have to add to the inside router and the remote PIX?  Thanks for responding.  
0
 
LVL 79

Accepted Solution

by:
lrmoore earned 500 total points
ID: 12105711
No routes should be necessary because the VPN policy definitions set that up for you.
As long as the 3640 has a default route pointing to the PIX, and the PIX is the default gateway on the remote network there is no other routing necessary.

Have you made any other progress on this? If not, can you post your complete PIX config?
Do you have an access-list for NAT 0 as well as the tunnel traffic match list?

0
 
LVL 1

Author Comment

by:tomytek
ID: 12122443
Thanks for the help.  The problem was with my router configuration.  I had Natting enabled on the router.  I had to turn off natting and statically nat on the PIX.  Now traffic is able to go from the router to the remote PIX.  Thanks again.
0

Featured Post

What is SQL Server and how does it work?

The purpose of this paper is to provide you background on SQL Server. It’s your self-study guide for learning fundamentals. It includes both the history of SQL and its technical basics. Concepts and definitions will form the solid foundation of your future DBA expertise.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

Title # Comments Views Activity
ipsec tunnel comme not up 10 75
Cisco Any Connect Client 5 37
The purpose of using BGP 33 70
Configuring routing and ACL for Cisco 891 router 15 45
Have you experienced traffic destined through a Cisco ASA firewall disappears and you do not know if the traffic stops in the firewall or somewhere else? The solution is the capture feature. This feature was released in 6.2(1) and works in all firew…
The DROP (Spamhaus Don't Route Or Peer List) is a small list of IP address ranges that have been stolen or hijacked from their rightful owners. The DROP list is not a DNS based list.  It is designed to be downloaded as a file, with primary intention…
Both in life and business – not all partnerships are created equal. As the demand for cloud services increases, so do the number of self-proclaimed cloud partners. Asking the right questions up front in the partnership, will enable both parties …
Both in life and business – not all partnerships are created equal. Spend 30 short minutes with us to learn:   • Key questions to ask when considering a partnership to accelerate your business into the cloud • Pitfalls and mistakes other partners…

911 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

23 Experts available now in Live!

Get 1:1 Help Now