Re: [cisco-voip] Expressway E Firewall Rule Activation

[Ryan Huff]

Shucks Adam, I didn’t think you were snippy at all :). Listen, the only way to 
truly offend me is to take the last beer BEFORE the designated gofer for the 
night has Uber’ed his/her way back from the package store ;).

Stay Classy AP ;)

- RH

Sent from my iPhone

On Apr 30, 2019, at 13:20, Pawlowski, Adam 
mailto:aj...@buffalo.edu>> wrote:

No snipe intended! Just been a rough day here.

Normally I wouldn’t get too far into details but, I feel like there are other 
customers out there who would have a similar network design with an in and an 
out, and it maybe be simpler to deploy this way, given the considerations.

And as always, I like to post and see what I can learn, especially from 
superstars such as yourself ☺

Best,

Adam Pawlowski
SUNYAB NCS

From: Ryan Huff mailto:ryanh...@outlook.com>>
Sent: Tuesday, April 30, 2019 12:09 PM
To: Pawlowski, Adam mailto:aj...@buffalo.edu>>
Cc: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
Subject: Re: [cisco-voip] Expressway E Firewall Rule Activation

Adam,

I certainly didn't mean to imply the, "Expressway Edge on a Stick" method 
doesn't work, though out of pure technical curiosity, I would be curious as to 
what exists in your environment that would make a " single NIC" Expressway Edge 
deployment more preferred than "dual NICs" (not that I expect you would or 
could say). I can think of very few reasons that a single NIC edge would be 
more ideal than a dual NIC edge (outside of the infosec team just not wanting 
to screw with the firewall, or production not being able to sustain a 
maintenance window); its easier to troubleshoot, easier to install, easier to 
support and easier to secure.

Though, I suspect I'm, "preaching to the choir", lol . All good my friend.

Thanks,

Ryan


From: Pawlowski, Adam mailto:aj...@buffalo.edu>>
Sent: Tuesday, April 30, 2019 11:36 AM
To: 'Ryan Huff'
Cc: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
Subject: RE: [cisco-voip] Expressway E Firewall Rule Activation


Ryan,



The “tl;dr” is that we were sort of given the recommendation by Cisco to just 
run it with the single interface given our environment and requirements, and 
hasn’t given us any trouble that I can recall.



Long story is …

Our environment ends up being the driver for a lot of this, as it is sort of a 
historic design from the early internet, with just about everything on public 
address space, and various services and networks secured behind firewalls as 
needed from internal and external alike.



In the dual interface design, the outside interface sits in a “DMZ” with a 
firewall, which we don’t have available explicitly. There is a border firewall 
but that isn’t really its function. The inside leg has to sit somewhere as 
well, which is a place that doesn’t exist.

We did have a competitor’s border proxy become compromised in the past due to a 
software update, and this model where the inside wasn’t properly secured – and 
given our current VMWare topology, creating another zone to hairpin traffic 
around to separate that inside interface wasn’t in the cards. Not to mention 
the annoyance of trying to setup split routes on this device to allow some 
traffic to go in, some to go out, in an environment that is MRA only.



If you trust the E enough never to be a bad actor, then you could put that 
interface in the same zone as your other collaboration appliances, like the 
Expressway C, but, we didn’t want to do that either really.



Given that, we did have a call with Cisco to discuss this, and with 
representation from the Expressway group they recommended that we stick with 
the single interface design.  That was based on the public addressing (so we 
could avoid NAT reflection) and that despite the pipe dream of everyone wanting 
HD video calling and mobile client access, we didn’t see that we’d be pushing 
that much traffic.



As it is, the E clusters sit in a collaboration DMZ, where they are independent 
from any of our other appliances and treated like any other host on our 
network. Our application firewalls do not allow anything in from the Expressway 
E since the C tunnels to it, so really the only thing lacking from a security 
standpoint there could be containment of that host, but, we chose to guard from 
it instead.



Since we installed it back on X8.8 or whatever, I’d noted that rebooting the 
appliance does not reapply the internal rules, which can easily be forgotten, 
and would need to be remembered if you run a VMWare HA policy that restarts the 
guest.



That all being said the worst that we have seen are various SSH attempts (on 
any port, the zone tunnel, administrative SSH, doesn’t matter) until the rules 
are put back up. We could tighten them on the border once that becomes 
available to do so.



The B2BUA is invoked on calls within the appliances sometimes which can cause 
some co

Re: [cisco-voip] Expressway E Firewall Rule Activation

[Brian Meade]

Yea, I almost always do single NIC because of this.  Not many customers
have a separate DMZ-Outside and DMZ-Inside.  If they do, I go with the
dual-NIC design.

Almost always when I see a dual-NIC implementation done, they've got the
inside NIC directly attached to the inside network.  It seems like a lot of
people prefer the dual-NIC due to how easy that setup is not realizing the
security implementations.

I can count on one hand the number of true dual-NIC dual-DMZ Expressway
setups I've seen in the wild.

On Tue, Apr 30, 2019 at 12:13 PM Anthony Holloway <
avholloway+cisco-v...@gmail.com> wrote:

> Ryan,
>
> Do you have any insight as to whether or not it's common for Firewalls in
> the field to already have more than one DMZ defined?  In my limited
> experience, I have never seen it done, and I am having to have that second
> DMZ created to support Expressway.  For that reason, I actually tend to
> think the single NIC approach is better, although, the NAT reflection could
> be a limitation of some firewalls.
>
> On Tue, Apr 30, 2019 at 11:09 AM Ryan Huff  wrote:
>
>> Adam,
>>
>> I certainly didn't mean to imply the, "Expressway Edge on a Stick" method
>> doesn't work, though out of pure technical curiosity, I would be curious as
>> to what exists in your environment that would make a " single NIC"
>> Expressway Edge deployment more preferred than "dual NICs" (not that I
>> expect you would or could say). I can think of very few reasons that a
>> single NIC edge would be more ideal than a dual NIC edge (outside of the
>> infosec team just not wanting to screw with the firewall, or production not
>> being able to sustain a maintenance window); its easier to troubleshoot,
>> easier to install, easier to support and easier to secure.
>>
>> Though, I suspect I'm, "preaching to the choir", lol . All good my
>> friend.
>>
>> Thanks,
>>
>> Ryan
>>
>> ----------
>> *From:* Pawlowski, Adam 
>> *Sent:* Tuesday, April 30, 2019 11:36 AM
>> *To:* 'Ryan Huff'
>> *Cc:* cisco-voip@puck.nether.net
>> *Subject:* RE: [cisco-voip] Expressway E Firewall Rule Activation
>>
>>
>> Ryan,
>>
>>
>>
>> The “tl;dr” is that we were sort of given the recommendation by Cisco to
>> just run it with the single interface given our environment and
>> requirements, and hasn’t given us any trouble that I can recall.
>>
>>
>>
>> Long story is …
>>
>>
>> Our environment ends up being the driver for a lot of this, as it is sort
>> of a historic design from the early internet, with just about everything on
>> public address space, and various services and networks secured behind
>> firewalls as needed from internal and external alike.
>>
>>
>>
>> In the dual interface design, the outside interface sits in a “DMZ” with
>> a firewall, which we don’t have available explicitly. There is a border
>> firewall but that isn’t really its function. The inside leg has to sit
>> somewhere as well, which is a place that doesn’t exist.
>>
>>
>> We did have a competitor’s border proxy become compromised in the past
>> due to a software update, and this model where the inside wasn’t properly
>> secured – and given our current VMWare topology, creating another zone to
>> hairpin traffic around to separate that inside interface wasn’t in the
>> cards. Not to mention the annoyance of trying to setup split routes on this
>> device to allow some traffic to go in, some to go out, in an environment
>> that is MRA only.
>>
>>
>>
>> If you trust the E enough never to be a bad actor, then you could put
>> that interface in the same zone as your other collaboration appliances,
>> like the Expressway C, but, we didn’t want to do that either really.
>>
>>
>>
>> Given that, we did have a call with Cisco to discuss this, and with
>> representation from the Expressway group they recommended that we stick
>> with the single interface design.  That was based on the public addressing
>> (so we could avoid NAT reflection) and that despite the pipe dream of
>> everyone wanting HD video calling and mobile client access, we didn’t see
>> that we’d be pushing that much traffic.
>>
>>
>>
>> As it is, the E clusters sit in a collaboration DMZ, where they are
>> independent from any of our other appliances and treated like any other
>> host on our network. Our application firewalls do not allow anything in
>> from the Expressway E since the C tunnels to it, so really the only thing
>> lacking from

Re: [cisco-voip] Expressway E Firewall Rule Activation

[Anthony Holloway]

If you stick the Edge LAN1 on the inside (where Core is), then doesn't this
technically circumvent the "traversal" part of the technology?  Because we
point Core at Edge via it's LAN 1 IP, right?  Or am I missing something?



On Tue, Apr 30, 2019 at 11:33 AM Ryan Huff  wrote:

> Not generally, no. A couple of my larger customer’s that have fully
> fleshed out IT departments did though.
>
> For a few of my customers I’ve had to walk them through setting a 2nd one
> up. In some cases, not even a true DMZ and just a new network and lock it
> down with ACLs.
>
> I’ve also had customer’s which do the DMZ on “LAN2” (outside), and then
> keeps LAN1 in the same network as Expressway-C. This particular method
> doesn’t offer a lot of advantages (from a infosec perspective) over a
> “Single NIC”, but still makes the traffic flow more logical, easier to
> support and troubleshoot and keeps you from having to “hairpin” in the
> firewall (ewww, like gag me with a spoon man lol), which I have never been
> a fan of from a design perspective.
>
> -Ryan
>
> On Apr 30, 2019, at 12:12, Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
> Ryan,
>
> Do you have any insight as to whether or not it's common for Firewalls in
> the field to already have more than one DMZ defined?  In my limited
> experience, I have never seen it done, and I am having to have that second
> DMZ created to support Expressway.  For that reason, I actually tend to
> think the single NIC approach is better, although, the NAT reflection could
> be a limitation of some firewalls.
>
> On Tue, Apr 30, 2019 at 11:09 AM Ryan Huff  wrote:
>
>> Adam,
>>
>> I certainly didn't mean to imply the, "Expressway Edge on a Stick" method
>> doesn't work, though out of pure technical curiosity, I would be curious as
>> to what exists in your environment that would make a " single NIC"
>> Expressway Edge deployment more preferred than "dual NICs" (not that I
>> expect you would or could say). I can think of very few reasons that a
>> single NIC edge would be more ideal than a dual NIC edge (outside of the
>> infosec team just not wanting to screw with the firewall, or production not
>> being able to sustain a maintenance window); its easier to troubleshoot,
>> easier to install, easier to support and easier to secure.
>>
>> Though, I suspect I'm, "preaching to the choir", lol . All good my
>> friend.
>>
>> Thanks,
>>
>> Ryan
>>
>> --
>> *From:* Pawlowski, Adam 
>> *Sent:* Tuesday, April 30, 2019 11:36 AM
>> *To:* 'Ryan Huff'
>> *Cc:* cisco-voip@puck.nether.net
>> *Subject:* RE: [cisco-voip] Expressway E Firewall Rule Activation
>>
>>
>> Ryan,
>>
>>
>>
>> The “tl;dr” is that we were sort of given the recommendation by Cisco to
>> just run it with the single interface given our environment and
>> requirements, and hasn’t given us any trouble that I can recall.
>>
>>
>>
>> Long story is …
>>
>>
>> Our environment ends up being the driver for a lot of this, as it is sort
>> of a historic design from the early internet, with just about everything on
>> public address space, and various services and networks secured behind
>> firewalls as needed from internal and external alike.
>>
>>
>>
>> In the dual interface design, the outside interface sits in a “DMZ” with
>> a firewall, which we don’t have available explicitly. There is a border
>> firewall but that isn’t really its function. The inside leg has to sit
>> somewhere as well, which is a place that doesn’t exist.
>>
>>
>> We did have a competitor’s border proxy become compromised in the past
>> due to a software update, and this model where the inside wasn’t properly
>> secured – and given our current VMWare topology, creating another zone to
>> hairpin traffic around to separate that inside interface wasn’t in the
>> cards. Not to mention the annoyance of trying to setup split routes on this
>> device to allow some traffic to go in, some to go out, in an environment
>> that is MRA only.
>>
>>
>>
>> If you trust the E enough never to be a bad actor, then you could put
>> that interface in the same zone as your other collaboration appliances,
>> like the Expressway C, but, we didn’t want to do that either really.
>>
>>
>>
>> Given that, we did have a call with Cisco to discuss this, and with
>> representation from the Expressway group they recommended that we stick
>> with the single interface design.  That was

Re: [cisco-voip] Expressway E Firewall Rule Activation

[Pawlowski, Adam]

No snipe intended! Just been a rough day here.

Normally I wouldn’t get too far into details but, I feel like there are other 
customers out there who would have a similar network design with an in and an 
out, and it maybe be simpler to deploy this way, given the considerations.

And as always, I like to post and see what I can learn, especially from 
superstars such as yourself ☺

Best,

Adam Pawlowski
SUNYAB NCS

From: Ryan Huff 
Sent: Tuesday, April 30, 2019 12:09 PM
To: Pawlowski, Adam 
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Expressway E Firewall Rule Activation

Adam,

I certainly didn't mean to imply the, "Expressway Edge on a Stick" method 
doesn't work, though out of pure technical curiosity, I would be curious as to 
what exists in your environment that would make a " single NIC" Expressway Edge 
deployment more preferred than "dual NICs" (not that I expect you would or 
could say). I can think of very few reasons that a single NIC edge would be 
more ideal than a dual NIC edge (outside of the infosec team just not wanting 
to screw with the firewall, or production not being able to sustain a 
maintenance window); its easier to troubleshoot, easier to install, easier to 
support and easier to secure.

Though, I suspect I'm, "preaching to the choir", lol . All good my friend.

Thanks,

Ryan


From: Pawlowski, Adam mailto:aj...@buffalo.edu>>
Sent: Tuesday, April 30, 2019 11:36 AM
To: 'Ryan Huff'
Cc: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
Subject: RE: [cisco-voip] Expressway E Firewall Rule Activation


Ryan,



The “tl;dr” is that we were sort of given the recommendation by Cisco to just 
run it with the single interface given our environment and requirements, and 
hasn’t given us any trouble that I can recall.



Long story is …

Our environment ends up being the driver for a lot of this, as it is sort of a 
historic design from the early internet, with just about everything on public 
address space, and various services and networks secured behind firewalls as 
needed from internal and external alike.



In the dual interface design, the outside interface sits in a “DMZ” with a 
firewall, which we don’t have available explicitly. There is a border firewall 
but that isn’t really its function. The inside leg has to sit somewhere as 
well, which is a place that doesn’t exist.

We did have a competitor’s border proxy become compromised in the past due to a 
software update, and this model where the inside wasn’t properly secured – and 
given our current VMWare topology, creating another zone to hairpin traffic 
around to separate that inside interface wasn’t in the cards. Not to mention 
the annoyance of trying to setup split routes on this device to allow some 
traffic to go in, some to go out, in an environment that is MRA only.



If you trust the E enough never to be a bad actor, then you could put that 
interface in the same zone as your other collaboration appliances, like the 
Expressway C, but, we didn’t want to do that either really.



Given that, we did have a call with Cisco to discuss this, and with 
representation from the Expressway group they recommended that we stick with 
the single interface design.  That was based on the public addressing (so we 
could avoid NAT reflection) and that despite the pipe dream of everyone wanting 
HD video calling and mobile client access, we didn’t see that we’d be pushing 
that much traffic.



As it is, the E clusters sit in a collaboration DMZ, where they are independent 
from any of our other appliances and treated like any other host on our 
network. Our application firewalls do not allow anything in from the Expressway 
E since the C tunnels to it, so really the only thing lacking from a security 
standpoint there could be containment of that host, but, we chose to guard from 
it instead.



Since we installed it back on X8.8 or whatever, I’d noted that rebooting the 
appliance does not reapply the internal rules, which can easily be forgotten, 
and would need to be remembered if you run a VMWare HA policy that restarts the 
guest.



That all being said the worst that we have seen are various SSH attempts (on 
any port, the zone tunnel, administrative SSH, doesn’t matter) until the rules 
are put back up. We could tighten them on the border once that becomes 
available to do so.



The B2BUA is invoked on calls within the appliances sometimes which can cause 
some confusion with attempting to read logging if need be, but it hasn’t 
otherwise caused us any trouble.



Adam







From: Ryan Huff mailto:ryanh...@outlook.com>>
Sent: Tuesday, April 30, 2019 10:13 AM
To: Pawlowski, Adam mailto:aj...@buffalo.edu>>
Cc: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
Subject: Re: [cisco-voip] Expressway E Firewall Rule Activation



That seems odd and not been my experience. Let me ask; why a

Re: [cisco-voip] Expressway E Firewall Rule Activation

[Ryan Huff]

Not generally, no. A couple of my larger customer’s that have fully fleshed out 
IT departments did though.

For a few of my customers I’ve had to walk them through setting a 2nd one up. 
In some cases, not even a true DMZ and just a new network and lock it down with 
ACLs.

I’ve also had customer’s which do the DMZ on “LAN2” (outside), and then keeps 
LAN1 in the same network as Expressway-C. This particular method doesn’t offer 
a lot of advantages (from a infosec perspective) over a “Single NIC”, but still 
makes the traffic flow more logical, easier to support and troubleshoot and 
keeps you from having to “hairpin” in the firewall (ewww, like gag me with a 
spoon man lol), which I have never been a fan of from a design perspective.

-Ryan

On Apr 30, 2019, at 12:12, Anthony Holloway 
mailto:avholloway+cisco-v...@gmail.com>> wrote:

Ryan,

Do you have any insight as to whether or not it's common for Firewalls in the 
field to already have more than one DMZ defined?  In my limited experience, I 
have never seen it done, and I am having to have that second DMZ created to 
support Expressway.  For that reason, I actually tend to think the single NIC 
approach is better, although, the NAT reflection could be a limitation of some 
firewalls.

On Tue, Apr 30, 2019 at 11:09 AM Ryan Huff 
mailto:ryanh...@outlook.com>> wrote:
Adam,

I certainly didn't mean to imply the, "Expressway Edge on a Stick" method 
doesn't work, though out of pure technical curiosity, I would be curious as to 
what exists in your environment that would make a " single NIC" Expressway Edge 
deployment more preferred than "dual NICs" (not that I expect you would or 
could say). I can think of very few reasons that a single NIC edge would be 
more ideal than a dual NIC edge (outside of the infosec team just not wanting 
to screw with the firewall, or production not being able to sustain a 
maintenance window); its easier to troubleshoot, easier to install, easier to 
support and easier to secure.

Though, I suspect I'm, "preaching to the choir", lol . All good my friend.

Thanks,

Ryan


From: Pawlowski, Adam mailto:aj...@buffalo.edu>>
Sent: Tuesday, April 30, 2019 11:36 AM
To: 'Ryan Huff'
Cc: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
Subject: RE: [cisco-voip] Expressway E Firewall Rule Activation


Ryan,



The “tl;dr” is that we were sort of given the recommendation by Cisco to just 
run it with the single interface given our environment and requirements, and 
hasn’t given us any trouble that I can recall.



Long story is …

Our environment ends up being the driver for a lot of this, as it is sort of a 
historic design from the early internet, with just about everything on public 
address space, and various services and networks secured behind firewalls as 
needed from internal and external alike.



In the dual interface design, the outside interface sits in a “DMZ” with a 
firewall, which we don’t have available explicitly. There is a border firewall 
but that isn’t really its function. The inside leg has to sit somewhere as 
well, which is a place that doesn’t exist.

We did have a competitor’s border proxy become compromised in the past due to a 
software update, and this model where the inside wasn’t properly secured – and 
given our current VMWare topology, creating another zone to hairpin traffic 
around to separate that inside interface wasn’t in the cards. Not to mention 
the annoyance of trying to setup split routes on this device to allow some 
traffic to go in, some to go out, in an environment that is MRA only.



If you trust the E enough never to be a bad actor, then you could put that 
interface in the same zone as your other collaboration appliances, like the 
Expressway C, but, we didn’t want to do that either really.



Given that, we did have a call with Cisco to discuss this, and with 
representation from the Expressway group they recommended that we stick with 
the single interface design.  That was based on the public addressing (so we 
could avoid NAT reflection) and that despite the pipe dream of everyone wanting 
HD video calling and mobile client access, we didn’t see that we’d be pushing 
that much traffic.



As it is, the E clusters sit in a collaboration DMZ, where they are independent 
from any of our other appliances and treated like any other host on our 
network. Our application firewalls do not allow anything in from the Expressway 
E since the C tunnels to it, so really the only thing lacking from a security 
standpoint there could be containment of that host, but, we chose to guard from 
it instead.



Since we installed it back on X8.8 or whatever, I’d noted that rebooting the 
appliance does not reapply the internal rules, which can easily be forgotten, 
and would need to be remembered if you run a VMWare HA policy that restarts the 
guest.



That all being said the worst th

Re: [cisco-voip] Expressway E Firewall Rule Activation

[Anthony Holloway]

Ryan,

Do you have any insight as to whether or not it's common for Firewalls in
the field to already have more than one DMZ defined?  In my limited
experience, I have never seen it done, and I am having to have that second
DMZ created to support Expressway.  For that reason, I actually tend to
think the single NIC approach is better, although, the NAT reflection could
be a limitation of some firewalls.

On Tue, Apr 30, 2019 at 11:09 AM Ryan Huff  wrote:

> Adam,
>
> I certainly didn't mean to imply the, "Expressway Edge on a Stick" method
> doesn't work, though out of pure technical curiosity, I would be curious as
> to what exists in your environment that would make a " single NIC"
> Expressway Edge deployment more preferred than "dual NICs" (not that I
> expect you would or could say). I can think of very few reasons that a
> single NIC edge would be more ideal than a dual NIC edge (outside of the
> infosec team just not wanting to screw with the firewall, or production not
> being able to sustain a maintenance window); its easier to troubleshoot,
> easier to install, easier to support and easier to secure.
>
> Though, I suspect I'm, "preaching to the choir", lol . All good my
> friend.
>
> Thanks,
>
> Ryan
>
> --
> *From:* Pawlowski, Adam 
> *Sent:* Tuesday, April 30, 2019 11:36 AM
> *To:* 'Ryan Huff'
> *Cc:* cisco-voip@puck.nether.net
> *Subject:* RE: [cisco-voip] Expressway E Firewall Rule Activation
>
>
> Ryan,
>
>
>
> The “tl;dr” is that we were sort of given the recommendation by Cisco to
> just run it with the single interface given our environment and
> requirements, and hasn’t given us any trouble that I can recall.
>
>
>
> Long story is …
>
>
> Our environment ends up being the driver for a lot of this, as it is sort
> of a historic design from the early internet, with just about everything on
> public address space, and various services and networks secured behind
> firewalls as needed from internal and external alike.
>
>
>
> In the dual interface design, the outside interface sits in a “DMZ” with a
> firewall, which we don’t have available explicitly. There is a border
> firewall but that isn’t really its function. The inside leg has to sit
> somewhere as well, which is a place that doesn’t exist.
>
>
> We did have a competitor’s border proxy become compromised in the past due
> to a software update, and this model where the inside wasn’t properly
> secured – and given our current VMWare topology, creating another zone to
> hairpin traffic around to separate that inside interface wasn’t in the
> cards. Not to mention the annoyance of trying to setup split routes on this
> device to allow some traffic to go in, some to go out, in an environment
> that is MRA only.
>
>
>
> If you trust the E enough never to be a bad actor, then you could put that
> interface in the same zone as your other collaboration appliances, like the
> Expressway C, but, we didn’t want to do that either really.
>
>
>
> Given that, we did have a call with Cisco to discuss this, and with
> representation from the Expressway group they recommended that we stick
> with the single interface design.  That was based on the public addressing
> (so we could avoid NAT reflection) and that despite the pipe dream of
> everyone wanting HD video calling and mobile client access, we didn’t see
> that we’d be pushing that much traffic.
>
>
>
> As it is, the E clusters sit in a collaboration DMZ, where they are
> independent from any of our other appliances and treated like any other
> host on our network. Our application firewalls do not allow anything in
> from the Expressway E since the C tunnels to it, so really the only thing
> lacking from a security standpoint there could be containment of that host,
> but, we chose to guard from it instead.
>
>
>
> Since we installed it back on X8.8 or whatever, I’d noted that rebooting
> the appliance does not reapply the internal rules, which can easily be
> forgotten, and would need to be remembered if you run a VMWare HA policy
> that restarts the guest.
>
>
>
> That all being said the worst that we have seen are various SSH attempts
> (on any port, the zone tunnel, administrative SSH, doesn’t matter) until
> the rules are put back up. We could tighten them on the border once that
> becomes available to do so.
>
>
>
> The B2BUA is invoked on calls within the appliances sometimes which can
> cause some confusion with attempting to read logging if need be, but it
> hasn’t otherwise caused us any trouble.
>
>
>
> Adam
>
>
>
>
>
>
>
> *From:* Ryan Huff 
> *Sent:* Tuesday, April 30

Re: [cisco-voip] Expressway E Firewall Rule Activation

[Ryan Huff]

Look at that, you did say. I just "tl;dr"'ed it hahah

-Ryan


From: cisco-voip  on behalf of Ryan Huff 

Sent: Tuesday, April 30, 2019 12:08 PM
To: Pawlowski, Adam
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Expressway E Firewall Rule Activation

Adam,

I certainly didn't mean to imply the, "Expressway Edge on a Stick" method 
doesn't work, though out of pure technical curiosity, I would be curious as to 
what exists in your environment that would make a " single NIC" Expressway Edge 
deployment more preferred than "dual NICs" (not that I expect you would or 
could say). I can think of very few reasons that a single NIC edge would be 
more ideal than a dual NIC edge (outside of the infosec team just not wanting 
to screw with the firewall, or production not being able to sustain a 
maintenance window); its easier to troubleshoot, easier to install, easier to 
support and easier to secure.

Though, I suspect I'm, "preaching to the choir", lol . All good my friend.

Thanks,

Ryan


From: Pawlowski, Adam 
Sent: Tuesday, April 30, 2019 11:36 AM
To: 'Ryan Huff'
Cc: cisco-voip@puck.nether.net
Subject: RE: [cisco-voip] Expressway E Firewall Rule Activation


Ryan,



The “tl;dr” is that we were sort of given the recommendation by Cisco to just 
run it with the single interface given our environment and requirements, and 
hasn’t given us any trouble that I can recall.



Long story is …

Our environment ends up being the driver for a lot of this, as it is sort of a 
historic design from the early internet, with just about everything on public 
address space, and various services and networks secured behind firewalls as 
needed from internal and external alike.



In the dual interface design, the outside interface sits in a “DMZ” with a 
firewall, which we don’t have available explicitly. There is a border firewall 
but that isn’t really its function. The inside leg has to sit somewhere as 
well, which is a place that doesn’t exist.

We did have a competitor’s border proxy become compromised in the past due to a 
software update, and this model where the inside wasn’t properly secured – and 
given our current VMWare topology, creating another zone to hairpin traffic 
around to separate that inside interface wasn’t in the cards. Not to mention 
the annoyance of trying to setup split routes on this device to allow some 
traffic to go in, some to go out, in an environment that is MRA only.



If you trust the E enough never to be a bad actor, then you could put that 
interface in the same zone as your other collaboration appliances, like the 
Expressway C, but, we didn’t want to do that either really.



Given that, we did have a call with Cisco to discuss this, and with 
representation from the Expressway group they recommended that we stick with 
the single interface design.  That was based on the public addressing (so we 
could avoid NAT reflection) and that despite the pipe dream of everyone wanting 
HD video calling and mobile client access, we didn’t see that we’d be pushing 
that much traffic.



As it is, the E clusters sit in a collaboration DMZ, where they are independent 
from any of our other appliances and treated like any other host on our 
network. Our application firewalls do not allow anything in from the Expressway 
E since the C tunnels to it, so really the only thing lacking from a security 
standpoint there could be containment of that host, but, we chose to guard from 
it instead.



Since we installed it back on X8.8 or whatever, I’d noted that rebooting the 
appliance does not reapply the internal rules, which can easily be forgotten, 
and would need to be remembered if you run a VMWare HA policy that restarts the 
guest.



That all being said the worst that we have seen are various SSH attempts (on 
any port, the zone tunnel, administrative SSH, doesn’t matter) until the rules 
are put back up. We could tighten them on the border once that becomes 
available to do so.



The B2BUA is invoked on calls within the appliances sometimes which can cause 
some confusion with attempting to read logging if need be, but it hasn’t 
otherwise caused us any trouble.



Adam







From: Ryan Huff 
Sent: Tuesday, April 30, 2019 10:13 AM
To: Pawlowski, Adam 
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Expressway E Firewall Rule Activation



That seems odd and not been my experience. Let me ask; why are you using the 
application firewall rather than the actual firewall (another reason all our 
edge’s should be using dual interfaces with LAN1 and LAN2 in their own separate 
security zones)? Is there a reason you have to, in other words?

Thanks,



Ryan

On Apr 30, 2019, at 08:49, Pawlowski, Adam 
mailto:aj...@buffalo.edu>> wrote:

Figured I’d also ask this question



I note that it seems like any time I reboot an Expressway E, I have to go and 
re-acti

Re: [cisco-voip] Expressway E Firewall Rule Activation

[Ryan Huff]

Adam,

I certainly didn't mean to imply the, "Expressway Edge on a Stick" method 
doesn't work, though out of pure technical curiosity, I would be curious as to 
what exists in your environment that would make a " single NIC" Expressway Edge 
deployment more preferred than "dual NICs" (not that I expect you would or 
could say). I can think of very few reasons that a single NIC edge would be 
more ideal than a dual NIC edge (outside of the infosec team just not wanting 
to screw with the firewall, or production not being able to sustain a 
maintenance window); its easier to troubleshoot, easier to install, easier to 
support and easier to secure.

Though, I suspect I'm, "preaching to the choir", lol . All good my friend.

Thanks,

Ryan


From: Pawlowski, Adam 
Sent: Tuesday, April 30, 2019 11:36 AM
To: 'Ryan Huff'
Cc: cisco-voip@puck.nether.net
Subject: RE: [cisco-voip] Expressway E Firewall Rule Activation


Ryan,



The “tl;dr” is that we were sort of given the recommendation by Cisco to just 
run it with the single interface given our environment and requirements, and 
hasn’t given us any trouble that I can recall.



Long story is …

Our environment ends up being the driver for a lot of this, as it is sort of a 
historic design from the early internet, with just about everything on public 
address space, and various services and networks secured behind firewalls as 
needed from internal and external alike.



In the dual interface design, the outside interface sits in a “DMZ” with a 
firewall, which we don’t have available explicitly. There is a border firewall 
but that isn’t really its function. The inside leg has to sit somewhere as 
well, which is a place that doesn’t exist.

We did have a competitor’s border proxy become compromised in the past due to a 
software update, and this model where the inside wasn’t properly secured – and 
given our current VMWare topology, creating another zone to hairpin traffic 
around to separate that inside interface wasn’t in the cards. Not to mention 
the annoyance of trying to setup split routes on this device to allow some 
traffic to go in, some to go out, in an environment that is MRA only.



If you trust the E enough never to be a bad actor, then you could put that 
interface in the same zone as your other collaboration appliances, like the 
Expressway C, but, we didn’t want to do that either really.



Given that, we did have a call with Cisco to discuss this, and with 
representation from the Expressway group they recommended that we stick with 
the single interface design.  That was based on the public addressing (so we 
could avoid NAT reflection) and that despite the pipe dream of everyone wanting 
HD video calling and mobile client access, we didn’t see that we’d be pushing 
that much traffic.



As it is, the E clusters sit in a collaboration DMZ, where they are independent 
from any of our other appliances and treated like any other host on our 
network. Our application firewalls do not allow anything in from the Expressway 
E since the C tunnels to it, so really the only thing lacking from a security 
standpoint there could be containment of that host, but, we chose to guard from 
it instead.



Since we installed it back on X8.8 or whatever, I’d noted that rebooting the 
appliance does not reapply the internal rules, which can easily be forgotten, 
and would need to be remembered if you run a VMWare HA policy that restarts the 
guest.



That all being said the worst that we have seen are various SSH attempts (on 
any port, the zone tunnel, administrative SSH, doesn’t matter) until the rules 
are put back up. We could tighten them on the border once that becomes 
available to do so.



The B2BUA is invoked on calls within the appliances sometimes which can cause 
some confusion with attempting to read logging if need be, but it hasn’t 
otherwise caused us any trouble.



Adam







From: Ryan Huff 
Sent: Tuesday, April 30, 2019 10:13 AM
To: Pawlowski, Adam 
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Expressway E Firewall Rule Activation



That seems odd and not been my experience. Let me ask; why are you using the 
application firewall rather than the actual firewall (another reason all our 
edge’s should be using dual interfaces with LAN1 and LAN2 in their own separate 
security zones)? Is there a reason you have to, in other words?

Thanks,



Ryan

On Apr 30, 2019, at 08:49, Pawlowski, Adam 
mailto:aj...@buffalo.edu>> wrote:

Figured I’d also ask this question



I note that it seems like any time I reboot an Expressway E, I have to go and 
re-activate all the firewall rules. They don’t seem to activate automatically.



Is there something I missed or is this really what’s necessary?



Adam





___
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://eur

Re: [cisco-voip] Expressway E Firewall Rule Activation

[Ryan Huff]

That seems odd and not been my experience. Let me ask; why are you using the 
application firewall rather than the actual firewall (another reason all our 
edge’s should be using dual interfaces with LAN1 and LAN2 in their own separate 
security zones)? Is there a reason you have to, in other words?

Thanks,

Ryan

On Apr 30, 2019, at 08:49, Pawlowski, Adam 
mailto:aj...@buffalo.edu>> wrote:

Figured I’d also ask this question

I note that it seems like any time I reboot an Expressway E, I have to go and 
re-activate all the firewall rules. They don’t seem to activate automatically.

Is there something I missed or is this really what’s necessary?

Adam


___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voipdata=02%7C01%7C%7C3fcc9eb351fe41b70dfc08d6cd6a4a65%7C84df9e7fe9f640afb435%7C1%7C0%7C636922253726465693sdata=72kYzwChhoFD14H6a6mRTn4TdHUcMDcFWrMSXpRo%2Btw%3Dreserved=0
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip