From: Steven Jenkins (steven.jenkins72@yahoo.com)
Date: Wed Nov 12 2008 - 19:08:33 ARST
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
Inspired Knowledge Blog | 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
This archive was generated by hypermail 2.1.4 : Mon Dec 01 2008 - 08:18:30 ARST