From: Sean Reilly (seanreilly@xxxxxxxxx)
Date: Thu Oct 11 2001 - 17:17:15 GMT-3
Actually I was able to get this to work. I didn't follow the directions
carefully enough and use an extended ping (sourcing from the Ethernet,
instead of the default serial interface).
-----Original Message-----
From: Jim Brown [mailto:Jim.Brown@CaseLogic.com]
Sent: Thursday, October 11, 2001 3:34 PM
To: 'Sean Reilly'; ccielab@groupstudy.com
Subject: RE: fatkid ipsec lab 393
I haven't looked at the lab, but you would solve this by creating a tunnel
between peers to pass routing information, or static routes to point towards
the remote ends.
-----Original Message-----
From: Sean Reilly [mailto:seanreilly@nc.rr.com]
Sent: Thursday, October 11, 2001 1:21 PM
To: ccielab@groupstudy.com
Subject: fatkid ipsec lab 393
Has anyone successfully completed the Fatkid Ipsec 393 lab?
I have a question concerning the IPsec lab 393. R1, without routing
enabled, has no idea how to transfer packets back to the originating private
networks. After hours of frustration, I configured all the routers with the
"answer" configs and it still does not work. I don't see how R3 and R5 can
send routing info, if the intermediate R1 router has no routes for these
networks in its routing table. Am I missing something?
Thanks.
Sean
This archive was generated by hypermail 2.1.4 : Thu Jun 20 2002 - 22:33:17 GMT-3