From: Paul Dardinski (pauld@marshallcomm.com)
Date: Sun Jul 20 2008 - 07:56:30 ART
Inherited sec level on the RA will be whichever int it arrives on. In
your case you mentioned it would be zero, hence traffic will not hairpin
to the higher (90) int. I'm assuming you have now altered this (either
made sec levels equal or need to add statics, which may be problematic
with your private to private arrangement). Also, for tshooting this I'd
get a sniffer on the egress int headed towards mpls int to ensure your
nat is working how you expect it to and that you aren't forwarding
private address space that is being dropped by your mpls provider.
Finally, as to inter-intra interface traffic, as can be seen from below,
neither are enabled by default. However, I doubt this is your issue as
this only affects same sec int transfer of traffic and you have now
conveyed that you have one at 90 and other at 0. Almost certainly your
issue here sounds like sec levels across the ints.
PD (#16842 RS/Sec)
same-security-traffic
To permit communication between interfaces with equal security levels,
or to allow traffic to enter and exit the same interface, use the
same-security-traffic command in global configuration mode. To disable
the same-security traffic, use the no form of this command.
same-security-traffic permit {inter-interface | intra-interface}
no same-security-traffic permit {inter-interface | intra-interface}
Syntax Description
inter-interface
Permits communication between different interfaces that have the same
security level.
intra-interface
Permits communication in and out of the same interface.
Defaults
This command is disabled by default.
From: Jian Gu [mailto:guxiaojian@gmail.com]
Sent: Sunday, July 20, 2008 3:54 AM
To: Joseph Brunner
Cc: Paul Dardinski; ccielab@groupstudy.com
Subject: Re: RA VPN users can not ping remote LAN
Interesting, my understanding of PIX configuration is that you configure
NAT on an interface that has higher security level for traffic
destinated to lower security level. In my case mpls interface security
level is 90, outside interface security level is 0, by configuring NAT
exemption on mpls interface, traffic sourced from private address space
to RA VPN pool address space will not be NATed and connection from RA
VPN can be initiated. This is exactly the same idea of configuring NAT
exemption on inside interface for internal traffic and traffic to RA VPN
pool, which works fine.
On Sat, Jul 19, 2008 at 11:47 PM, Joseph Brunner
<joe@affirmedsystems.com> wrote:
nope; my way
we nat clients at one site so they can use their PRIVATE ip s to hit a
dmz
it may be HEADED to the mpls interface; but its sourced from the vpn
pool
addresses internally where the xlate is created.
Think of your mpls as a dmz with routing if that helps forget the
capture.
think of the capture as checking if the car hits 6000 rpm, and does a
fast <
mile we still need to know why the ENGINE wont start
do intensive debugs and there should be nothing funny in those debugs
-J
_____
From: Jian Gu [mailto:guxiaojian@gmail.com]
Sent: Sunday, July 20, 2008 2:41 AM
To: Joseph Brunner
Cc: Paul Dardinski; ccielab@groupstudy.com
Subject: Re: RA VPN users can not ping remote LAN
I do have nat (mpls) 0 configured, but shouldn't the access-list look
the
other way around? like this:
access-list vpn-clients-nonat extended permit ip object-group
private-space
object-group vpn-clients
Traffic is coming to mpls interface, so the source should be
private-space
while the destination is vpn-clients?
On Sat, Jul 19, 2008 at 11:34 PM, Joseph Brunner
<joe@affirmedsystems.com>
wrote:
ok thanks, we just all piecing it all together.
I have done many MPLS turn-ups with PAETEC/ATT lately, and if you don't
advertise it to them, they don't know about it, no matter how MUNDANE a
route
Just looking at my ASA;
so you have both of these commands in the conf.
same-security-traffic permit inter-interface
same-security-traffic permit intra-interface
(should be default PIX/ASA commands IMHO!!!)
and do you have something like this .
access-list vpn-clients-nonat extended permit ip object-group
vpn-clients
object-group private-space
nat (mpls) 0 access-list vpn-clients-nonat
thanks,
Joe
_____
From: Jian Gu [mailto:guxiaojian@gmail.com]
Sent: Sunday, July 20, 2008 2:23 AM
To: Joseph Brunner
Cc: Paul Dardinski; ccielab@groupstudy.com
Subject: Re: RA VPN users can not ping remote LAN
The traffic is dropped in firewall, yes, MPLS provider routes
10.10.10.0/24
in my VRF, why would MPLS provider care what kind of routes I have?
remote
CE does get 10.10.10.0/24, so I am pretty sure the problem is not
routing.
Regarding your second question, I am sure, when traffic come in from RA
VPN,
what security level would it have? and what difference would it make
when
the traffic is routed to site2site VPN interface or mpls interface? both
interfaces have security level higher than outside interface security
level
0.
On Sat, Jul 19, 2008 at 9:52 PM, Joseph Brunner
<joe@affirmedsystems.com>
wrote:
Are we sure the MPLS provider routes 10.10.10.0/24 in your VRF? What are
you
static natting this to out interface "MPLS"?
-Joe
_____
From: Jian Gu [mailto:guxiaojian@gmail.com]
Sent: Sunday, July 20, 2008 12:42 AM
To: Joseph Brunner
Cc: Paul Dardinski; ccielab@groupstudy.com
Subject: Re: RA VPN users can not ping remote LAN
It is running 7.x
On Sat, Jul 19, 2008 at 8:45 PM, Joseph Brunner
<joe@affirmedsystems.com>
wrote:
All Good points, Master Paul;
One question I have now, is what Version Pix 515 is this? Hopefully 7.x
that
permits intra/inter anything.
-Joe
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Paul
Dardinski
Sent: Saturday, July 19, 2008 10:06 PM
To: Jian Gu
Cc: ccielab@groupstudy.com
Subject: RE: RA VPN users can not ping remote LAN
The intra hairpin worked previously w/site-to-site, right? Assuming that
to
be the case then only delta is change of interface (which I assume is
routed
correctly for the new site-to-site between offices). As you haven't
changed
any of the IP addies and only added a new int, take a look at your sec
level
on the new int and ensure its not lower then the ra. Also, ensure you
have
inter-interface traffic permitted (I'm assuming you had intra-interface
permitted before).
PD (#16842 RS/Sec)
=======================================================================
Paul Dardinski - CCIE #16842 (RS & Security)
CCNP, CCDA, MCSE, MBA
Cisco Wireless Specialist
Marshall Communications
20098 Ashbrook Place
Suite 260
Ashburn, VA 20147
(571) 223-2010 (Ext 105)
FAX: (571) 223-2012
"Systems Integration...IS...the Total
Solution"
=======================================================================
WARNING - THIS E-MAIL TRANSMISSION IS CONFIDENTIAL.
This e-mail transmission (including any accompanying attachments)
contains
confidential information, which is intended for the named addressee
only.
If you are not the intended recipient, you are hereby notified that any
use,
dissemination, distribution or reproduction of this e-mail is
prohibited. If
you have received this e-mail in error please contact me immediately at
pauld@marshallcomm.com. Thank you.
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Jian
Gu
Sent: Saturday, July 19, 2008 6:33 PM
To: Cisco certification
Subject: RA VPN users can not ping remote LAN
Hi, all,
This is a real world scenario, we have two offices one in San Jose and
the
other one in LA, the network is very simple, each office has a PIX 515
and
has one L3 subnet directly attached to firewall's inside interface, the
subnets are 192.168.1.0/24 and 192.168.2.0/24, respectively. Each
firewall
has two public IP addresses, one public address dedicated to Internet
access
and IPsec RA access, and the other public IP is dedicated for site2site
VPN,
the address pool for remote access VPN in SJ office is 10.10.10.0/24,
while
remote access pool in LA office is taken from 192.168.2.0/24 space. So
everything worked fine, when employees VPN in to either firewall, they
can
access Email/files in either location.
We now decided to get rid of the site2site VPN and go with MPLS VPN
service
provided by ATT, the MPLS VPN service was attached to third interface
(nameif MPLS) in firewall, we changed the static route on firewall such
that
traffic between two offices are routed to interface MPLS, the cutover is
successful, means that hosts in both offices can communicate with each
other
fine.
The only problem is remote access users can only access servers in their
local office but can not access servers (or ping) in remote office, I
think
somehow firewall does not route traffic coming from RA VPN to the new
(MPLS)
interface, but I can not figure out why is so, because the routing looks
correct, and NAT translation also OK.
If you guys have any suggestions, please guide, I can post the relevant
configuration if that helps.
Thanks,
Jian
This archive was generated by hypermail 2.1.4 : Mon Aug 04 2008 - 06:11:56 ART