You could also apply the ACL to the B5 on the workstations interface.  I guess 
I never understood how you were blocking internet access to the workstations in 
the first place.  If the workstations have their DG as 192.168.97.203 and there 
is a static route to the internet pointing to 192.168.91.1, then all traffic on 
the B5 could get to the internet unless you had another method of doing this.

From: Michael York [mailto:[email protected]]
Sent: Wednesday, March 09, 2011 11:09 PM
To: Enterasys Customer Mailing List
Subject: RE: [enterasys] SIRA VPN Access


Another solution may be as follows.

B5
Vlan 97 192.168.97.203 (The default Gateway for workstations)
Vlan 72 172.16.1.1 (The default Gateway for Phone equipment)
Ip route 0.0.0.0 0.0.0.0 172.16.1.2

VPN Router
Internal interface 172.16.1.2
ACL outbound on external interface      permit 172.16.1.0 0.0.0.255
                                                Deny 192.168.97.0 0.0.0.255
This acl should allow the vlan 72 device access to the internet but still deny 
the workstations whilst not interfering with internet traffic between the two 
vlans.


Michael York
Project Officer
Managed Services Group
National Maintenance & Deployment
NEC Australia Pty Ltd
NEC Australia Pty Ltd 26 Rodborough Rd, Frenchs Forest NSW   2086  Australia
Mob 0438 318 235 Fax: +61 2 9930 2520 E: [email protected]
Twitter @NEC_Australia  NEC on: Youtube, Flickr, Scribd
nec.com.au




-----Original Message-----
From: Keith Jefferson [mailto:[email protected]]
Sent: Thursday, 10 March 2011 9:12 AM
To: Enterasys Customer Mailing List
Subject: [enterasys] SIRA VPN Access

This may not be the right place to ask this question, but the thought
here is that since Siemens recommends Enterasys POE switches in their
configurations, that someone has encountered a similar situation.

I have actually a rather complex network comprising 4 subnets with a
nice mix of Unix, Mac and Windows packets flying about in addition to
the voice traffic created by a new Siemens HiPath 4000 Phone System.
But for simplicity, what I actually need help on can be summarized in
this diagram:

+--------------+     +--------+     +--------------------+
|              |     |        |     |   192.168.97.203   |
| Workstations +-----+ Phones +-----+ B5 Stack (VLAN 97) |
|              |     |        |     |--------------------|
+--------------+     +--------+     | B5 Stack (VLAN 72) |
  192.168.97.x       172.16.1.x     |    172.16.1.1      |
                                    +---------+----------+
                                              |
                                              |
                                              |
             +----------+----------+----------+
             |          |          |
             |          |          |
             |          |          |
          +--+--+    +--+--+    +--+--+
          |     |    |     |    |     |
          |     |    |     |    |     |
          +-----+    +-----+    +-----+
          Voice      HiPath 4K  Call Center
          Recorder              Server

We have an Enterasys B5 Stack that basically is the center of the
network.  The phones are on a 172.16.1.x subnet and are all connected
directly to the stack.  Each user workstation is connected to the back
of the phone, on a separate 192.168.97.x subnet.  The majority of the
stack, including the phones, is configured in one VLAN (VLAN 97), with a
few ports reserved for the actual Siemens equipment in a separate VLAN
(VLAN 72).  Everything uses the B5 as its gateway, either the
192.168.97.203 address for the workstations, or 172.16.1.1 for the
phones and phone equipment.  This allows the workstations to see the
phone equipment for Call Center reports, etc. even though they are on
separate VLANs.

All of this was setup by the Enterasys folks when the phone system was
installed, and it all works great.

One wrinkle not shown here that I added after the fact: There is a
Watchguard router connected to VLAN 97 with an address of 192.168.1.1.
VLAN 97 has a secondary address of 192.168.1.203 and a static route to
the Watchguard.  The Watchguard has a corresponding static route to
172.16.1.0 using the 192.168.1.203 address as a gateway.  This grants
internet access to the equipment connected to VLAN 72, WITHOUT giving
internet access to the user workstations connected to VLAN 97.  This is
a customer requirement.

Siemens needs IPSec VPN access to all of the equipment on VLAN 72, as
their SIRA support system relies on it.  For whatever reason, their
system refuses to talk to the Watchguard (which hosts several other VPN
tunnels), we've been down that road.  So I need to introduce a new VPN
router specifically for their use.  And this is where I get confused.

My first thought was to disconnect the Watchguard from the stack (it
served no other purpose to the phone system beyond granting the
aforementioned internet access) and connect another VPN device in it's
place.  I figure it can take care of the internet access also, and that
one router in this piece of the network is plenty.  That's why I didn't
show it above.

So my first attempt was to change the IP address of VLAN 72 on the B5
stack to 172.16.1.2, and introduce the VPN router at 172.16.1.1,
connected to VLAN 97 as the Watchguard was.  This way, all of the VLAN
72 devices now use the VPN router as a gateway, so the router can grant
IPSec VPN access to them, and those devices also get their required
internet access, while the VLAN 97 workstations do not.

However, doing this (changing the gateway, I imagine) caused the VLAN 97
workstations to lose access to the VLAN 72 equipment.  From a
workstation I could ping the B5 stack at 172.16.1.2, but I could not
reach the router (172.16.1.1) or more importantly the Call Center Server
(172.16.1.19) which is used to constantly display a Calls in Queue
monitor among other things.

And my sophmoric attempt to resolve the situation by adding a static
route on the B5 to a network to which it was already directly connected:

ip route 172.16.1.0 255.255.255.0 172.16.1.1

did not solve that problem <G>.  So at that point, I decided that I
clearly didn't know what I was doing and restored the status quo.  All
of this is taking place at a fairly large organization and I only have
the liberty to play around with the configuration on weekends.  My
strategy now is to try to figure out on paper what's going to work, and
return on a weekend with a new plan of attack.

So I'm hoping that there is someone else out there with a Siemens phone
system and their recommended Enterasys switch stack, who also has their
workstations piggy backed out of their phones, that has successfully
granted Siemens their required SIRA access.  If so, what type of router
did you use and how is it connected to your network with respect to the
switch stack?  Even if you don't have my added wrinkle of selective net
access, it might give me the insight I need to finish this off.

Thanks,

--Keith Jefferson
  Iscomp Systems






---
To unsubscribe from enterasys, send email to [email protected] with the body: 
unsubscribe enterasys [email protected]

---
To unsubscribe from enterasys, send email to [email protected] with the body: 
unsubscribe enterasys [email protected]

________________________________

No virus found in this message.
Checked by AVG - www.avg.com<http://www.avg.com>
Version: 10.0.1204 / Virus Database: 1497/3496 - Release Date: 03/10/11

---
To unsubscribe from enterasys, send email to [email protected] with the body: 
unsubscribe enterasys [email protected]

Reply via email to