From: Jason W. Miller (jaymiller5@gmail.com)
Date: Wed Nov 12 2008 - 23:11:26 ARST
This is the solution for doing a public deployment of your solution. Note
the nat (outside) statement that forces a nat translation to the outside
IP for the VPN traffic from the remote client going to the internet/outside
bound traffic. Your RRI solution works most likely because your lab is
configured to know where this traffic is at etc which is what Ramy is
pointing to a basic routing issue and is why RRI solved your issue with
hairpinning.
http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a00805734ae.shtml
Jay
On Wed, Nov 12, 2008 at 5:05 PM, Ramy Sisy <ramysisy@inspiredmaster.com>wrote:
> You are welcome Steven,
> - I think what you are saying is that the VPN headend (which would be the
> same as EZVPN server) had no route to the 10.100.100.0 subnet -
> This is true, that is why RRI solved the issue.
> - but if that is true why could they ping to that subnet before RRI was
> added -
> Probably they are reached outside the tunnel but they are not reached
> through the tunnel.
>
> It is purely routing problem.
> I recommend you to remove RRI and try to consult your VPN traffic to go
> through the tunnel using static routing. You can use a static statement
> telling the router which interface should be use to deliver the traffic
> instead of writing destination IP.
> Any other traffic should follow your NAT or existing Translation rules to
> anywhere else.
>
> HTH
>
> Best Regards,
>
> Ramy Sisy | CCIE II (Security, Routing/Switching)#17321, CCSI#30417
> CCIE Program Manager
>
> Inspired Master | Inspiring Creative Thinking... | WWW.INSPIREDMASTER.COM<http://www.inspiredmaster.com/>
> Inspired Knowledge Blog | WWW.INSPIREDK.COM <http://www.inspiredk.com/>
> e. RAMYSISY@INSPIREDMASTER.COM
>
>
> From: Steven Jenkins [mailto:steven.jenkins72@yahoo.com]
> Sent: Wednesday, November 12, 2008 1:09 PM
> To: Ramy Sisy; ccielab@groupstudy.com; security@groupstudy.com
> Subject: Re: VPN help
>
> Thanks Ramy,
>
> I don't think I qet it all the way though. The issues being ...
>
> 1) The VPN was site to site so no EZVPN involved.
> 2) both sides could ping across to each other with no problem ... so the
> 10.100.100.0 subnet was reachable from the head end.
>
> Part of what I don't understand is when the deny message came to me ... was
> it the ping request or the ping reply that was being blocked?
>
> I think what you are saying is that the VPN headend (which would be the
> same
> as EZVPN server) had no route to the 10.100.100.0 subnet ... but if that
> is
> true why could they ping to that subnet before RRI was added?
>
> To make sure we are talking abou the same thing ... what RRI fixed was the
> remote site pinging a destination on the internet after being hairpinned at
> the headend ASA.
>
> Also, the site to site subnets have NAT exemptions on both sides, but NAT
> was required for the remote site coming via the headend and going to the
> internet.
>
> Thanks so much!
> SJ
>
> ________________________________________
> From: Ramy Sisy <ramysisy@inspiredmaster.com>
> To: Steven Jenkins <steven.jenkins72@yahoo.com>; ccielab@groupstudy.com;
> security@groupstudy.com
> Sent: Wednesday, November 12, 2008 3:27:51 PM
> Subject: RE: VPN help
>
> Hi SJ,
> RRI simply will tell EzVPN server to reach VPN client's assigned IP address
> through host's actual physical interface IP address.
> Without RRI, EzVPN server will not be able to map between VPN client
> assigned IP address and client's public IP address at layer 3.
>
>
> Best Regards,
>
> Ramy Sisy | CCIE II (Security, Routing/Switching)#17321, CCSI#30417
> CCIE Program Manager
>
> Inspired Master | Inspiring Creative Thinking... | WWW.INSPIREDMASTER.COM<http://www.inspiredmaster.com/>
> Inspired Knowledge Blog | WWW.INSPIREDK.COM <http://www.inspiredk.com/>
> e. RAMYSISY@INSPIREDMASTER.COM
>
>
>
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Steven Jenkins
> Sent: Wednesday, November 12, 2008 11:41 AM
> To: ccielab@groupstudy.com; security@groupstudy.com
> Subject: VPN help
>
> Hey Guys,
>
> I got it ...
>
> I am still not sure why, but enabling RRI fixed the
> issue ...
>
> My obviously weak understadning of RRI doesn't tell me why this
> fixed it as I wasn't passing the route to any internal host.
>
> I guess it just
> put an entry in the routing table of the ASA and stopped it from dropping
> the
> packet due to thinking it had no entry in it's routing table. YES? And if
> that is the case, I guess it was the return ping, but I don't understand
> that
> either, because the log didn't show me traffic going going out and then the
> return ping being denied.
>
> Anyway - if someone can explain this I appreaciate
> it ...
>
> Thanks everyone!
> SJ
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
-- Jason W. Miller Two things are infinite: the universe and human stupidity; and I'm not sure about the universe." Albert EinsteinBlogs and organic groups at http://www.ccie.net
This archive was generated by hypermail 2.1.4 : Mon Dec 01 2008 - 08:18:30 ARST