From: Ramy Sisy (ramysisy@inspiredmaster.com)
Date: Wed Nov 12 2008 - 20:05:36 ARST
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
Inspired Knowledge Blog | 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
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