Solved

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

Posted on 2004-09-16
5
434 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

PRTG Network Monitor: Intuitive Network Monitoring

Network Monitoring is essential to ensure that computer systems and network devices are running. Use PRTG to monitor LANs, servers, websites, applications and devices, bandwidth, virtual environments, remote systems, IoT, and many more. PRTG is easy to set up & use.

Question has a verified solution.

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

Suggested Solutions

Title # Comments Views Activity
eigrp routing loop 5 63
Help with a subnetting question 7 58
Cisco ASA VPN Client Routing 8 44
What is an ASP Table on a Cisco ASA? 3 24
Use of TCL script on Cisco devices:  - create file and merge it with running configuration to apply configuration changes
This past year has been one of great growth and performance for OnPage. We have added many features and integrations to the product, making 2016 an awesome year. We see these steps forward as the basis for future growth.
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 …
As a trusted technology advisor to your customers you are likely getting the daily question of, ‘should I put this in the cloud?’ As customer demands for cloud services increases, companies will see a shift from traditional buying patterns to new…

820 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