Advanced ISA/RRAS configuraiton for ISP offering PPPoE based Broad

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

My Intro:

My company, 4ward/4ward Communications, is a Hong Kong SAR based ASP/ISP
specialising in Hosted Unified Communications Solutions based on Microsoft's
HMC and Nortel's CS1000E platforms. We are in the process of expanding our
service offerings in Hong Kong and will begin delivering services to eight
(8) countries in Asia this year, three (3) more by June 2007.

As a Microsoft Service Provider we rely heavily on ISA as a routing and
firewall mechanism in our networks. On the voice side we also use Nortel VPN
Router 221, 1100, and 2700 series devices along with Nortel's Ethernet
Routing Switch 8610 and 5520 products.


My challenge:

We recently signed a wholesale agreement with one of the fixed network
operators in Hong Kong covering services including PPPoE based broadband.
The operator uses Cisco Broadband Remote Access Service (BRAS)/LACs to
collect and forward the client connections. End users connect using PPPoE
from any PC or broadband router. The operator's LAC receives the inbound
PPPoE connection and simultaneously initiates an L2TP connection to the ISP's
(4ward's) LNS. In the Cisco world an LNS is probably a 2700 VXR series
router.

I must admit I’m a bit green in this area. I have a solid understanding of
routing technologies and VPNs but this PPPoE to L2TP thing has me a little
confused on a couple of points, which I will outline below. My whole
understanding of this solution is that it is much like a VPN connection but I
admit, I could be totally off about this.

I guess my first question is, ‘Can ISA be used as the LNS in a Wholesale
ISP/BB scenario?’

Our lives would be so much easier if we could use ISA for this solution as
we already use ISA to secure traffic between all of our networks. Treating
the client connections as either site-to-site or dial-up users would
certainly solve a large number of issues with securing traffic and allowing
access between networks.


Q2 The L2TP connections coming from the LAC are unencrypted. Can ISA handle
this if I disable VPN encryption in my RADIUS server, IAS?

Q3 Can I create site-to-site connections out of these inbound L2TP
connections? How do I deal with the fact that ISA wants the IP address of
the other end of the tunnel? I won’t have that as the PPPoE sessions are
demand dialled from the client end.

Actually, I have this problem with many of my current VPN users as we have
many site-to-site connections from sites without static IP addresses. Static
IP addresses are hard to come by in Hong Kong due to severe address
shortages. As a result, many of our VPN site-to-site networks in ISA have a
dummy tunnel end. How should I handle this? My current solution involved
dismantling our previous Enterprise Array and go instead with stand-along ISA
servers. This was because ISA in an array wants to be able to load-balance
the site-to-site networks using the IP address of the other end of the tunnel
when ILB is enabled. Being we never know the IP of the other end, we
couldn’t use ILB. Any workaround for this?

Q4 How will ISA/RRAS handle multiple connections originating from the same
IP address. Again, I don’t fully understand the LAC/LNS scenario yet but I’m
guessing multiple inbound client connections will originate from the same IP
address. We have problems with L2TP dial-up sessions from behind NAT when
multiple users dial-in over the internet from the same public IP. For
example, in our internet VPN situation we often get many users visiting the
same hotel which uses NAT to present the same public IP address to us for all
users. In this scenario, only one (1) user can successfully establish an
L2TP connection from the same hotel. Is this an encryption problem that can
be solved by disabling encryption/IPSec on the L2TP tunnel or is there some
other way to work around this problem?

In this wholesale BB case, the service provider gave use an IP address to
use for our LNS and an IP address for their LAC. For example 10.0.2.81/29
for their LAC and 10.0.2.82 for our LNS for 2M connections and 10.0.2.83 for
4M connections, and 10.0.2.84 for 10M connections. They also told us that we
needed a static route in our LNS pointing 172.16.10.0/24 to their LAC,
10.0.2.81. I’m not sure if this means that each unique client tunnel will be
presented to us from a unique address in the 172.16.10.0/24 range or if
multiple tunnels will end up sharing the same originating address. It seems
to me that all tunnels will appear to originate from 10.0.2.81 as they are
surely expecting us to have more than 254 users but I’m trying to get this
information from them. Unfortunately, there is no one I can really talk to
in the operator to learn this information from so it’s all still a little bit
fussy.

Q5 What kind of capacity/performance issues can you foresee with this
scenario? If the tunnels are unencrypted and we are providing only basic
filtering with an ‘allow all outbound to internet’ type of rule on ISA, are
we going to see good performance out of this solution or are we likely to
find that ISA balk under this kind of traffic?



I really appreciate any insight/thoughts anyone can share on this topic. I
have posted a file containing a diagram in PowerPoint and also the Service
Provider’s documentation for review on our web site at
http://www.4ward.hk/lns-lac.zip. You will notice that the documents discuss
VoIP and Data traffic. We will likely use a Nortel VPN Router solution for
the voice side out of performance concerns so we are just talking about the
Data tunnels for now. We will provide each customer with two (2) VDSL
circuits. Once for voice and one for data. Voice traffic will have priority
throughout the solution.



Thanks and Make it a Great Day!



Brad Pfeffer
Regional Technical Director
Hosted IP Voice
Asia-Pacific
科衛

e-mail: (e-mail address removed)
+852 2137-2828 DIRECT/MOBILE
+852 2137-2829 Direct FAX
+852 9408-3262 Mobile
web: http://www.4ward.hk

19th Floor, Asian House
1 Hennessy Road
Wan Chai, Hong Kong
Hong Kong SAR, PR China

+852 2137-2888 Reception
+852 2137-2889 Fax
 
Back
Top