[cisco-voip] Expressway E Firewall Rule Activation

Tue Apr 30 13:49:55 EDT 2019

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-voip at 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 <ryanhuff at 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 <ajp26 at buffalo.edu>
>> *Sent:* Tuesday, April 30, 2019 11:36 AM
>> *To:* 'Ryan Huff'
>> *Cc:* cisco-voip at 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 <ryanhuff at outlook.com>
>> *Sent:* Tuesday, April 30, 2019 10:13 AM
>> *To:* Pawlowski, Adam <ajp26 at buffalo.edu>
>> *Cc:* cisco-voip at 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 <ajp26 at 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 at puck.nether.net
>>
>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7C3fcc9eb351fe41b70dfc08d6cd6a4a65%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636922253726465693&sdata=72kYzwChhoFD14H6a6mRTn4TdHUcMDcFWrMSXpRo%2Btw%3D&reserved=0
>> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7C53c6d0eb53664c52fa1f08d6cd818e07%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636922353647552666&sdata=1IXxZp8QQ0FzhW3GAGY%2F1k2nnUSYA3QlKHlEABhE5PY%3D&reserved=0>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20190430/de55763a/attachment.html>