VM-Series-L2 firewall configuration?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

VM-Series-L2 firewall configuration?

L3 Networker

Hi,

does anyone have VM series configured like L2 firewall (intra-host communication) and well working?

My interface ethernet1/4 is configured like L2 and have leg to portgroup (vlan xx) glued to zone abcd....

Polices was created in way to deny SSH between zones abcd to abcd and allow other traffic, but SSH pass anyway from one guest vm to another in abcd zone. Situation is same with other deny traffic too, so I'm suspect that L2 firewall not working at all. Port group on distributed virtual switch is configured with promiscuous mode to allow, but from underlying infrastructure and VMware perspective that's mean that all traffic was redirected to all ports for monitoring purposes and cannot be filtered with "L2 interface leg" on PAN VM. 

From Monitor tab, I filtered "interesting" traffic between guest VM's, and by firewall, traffic are filtered "action>deny", unfortunately that is not truth...

1 accepted solution

Accepted Solutions

Actually if you take a step back and look at the configuration, Ethernet 1/1 and Ethernet 1/3 are both in VLAN300, and are part of different zones.  CustA-Servers (zone) is permitted to talk to CustA-vDS (zone) and vice-versa through this rule.

This rule can not control traffic from CustA-Servers to CustA-Servers, because that traffic does not traverse the firewall.  The only way you'll get traffic to traverse the firewall is to insert it _between_ the two servers.  This can be done with v-Wires, Layer2 (recommended in a virtualized datacenter) or Layer3.

Think of this like a perimeter firewall.  You don't just connect one interface to your LAN switch and call it good.  You connect one interface to the Internet, and another Interface to your internal network.  The firewall will inspect traffic passing from LAN to Internet and vice-versa.  But, just because the firewall is plugged into your LAN doesn't mean that all of your LAN-to-LAN traffic goes through the firewall...  Same thing with the VM Series.  You need to plumb the traffic appropriate so that it passes through the firewall.

In the PDF you referenced, there's a great graphic that illustrates this point:

Server A1 and Server A2 can talk to each other directly because they are on the same VDS on the same host.  Their traffic does not pass through the firewall.   However, traffic from A1 to B1 <must> go through the firewall, and that is where you can enforce policy.  Also look at Server B1 and B2, they can talk to each other without traversing the firewall.  However, for B1 to communicate with B3, that traffic must pass through 2 different firewalls - one on each ESXi host.  In this example, there are 2 different places where you could apply policy.

Hope that helps.

View solution in original post

6 REPLIES 6

L7 Applicator

Can you post a diagram of your configuration?  From the description it sounds like all 3 devices (ethernet1/4, guest1, and guest2) are all in the same portgroup.  The VM Series firewall will not filter traffic between two machines connected to the same portgroup.

One way to do this would be to configure the environment like this:

     guest1 connected to portgroup1

     guest2 connected to portgroup2

     vm-series firewall ethernet1/4 configured for abcd zone, connected to portgroup1

     vm-series firewall ethernet1/5 configured for wxyz zone, connected to portgroup2

At this point, you may now configure zone-based rules permitting/denying traffic from abcd to wxyz.

Once you have that working properly, then you can get more adventurous with multiple VLANs on a single VM-Series ethernet interface, "bridging" those vlans together using vlan re-write, etc.  I'd start simple, though, with the above configuration.

Hi,

yes my configuration is just like you describe, but if you review official doc from Palo Alto Networks "VM-Series_Deploymnt-RevA.pdf", they have example scenario, where have one L2 interface which permit/deny traffic within same security zone.

sec_policy_samezone.jpg

after while, they filter permited traffic within same sec zone

filter_samezone.jpg

You can see that example interface eth1/3 belongs to vlan 300 (supposed one port group), and rule "allow some stuff CustA" with statement between same zones, allow ping.

Actually if you take a step back and look at the configuration, Ethernet 1/1 and Ethernet 1/3 are both in VLAN300, and are part of different zones.  CustA-Servers (zone) is permitted to talk to CustA-vDS (zone) and vice-versa through this rule.

This rule can not control traffic from CustA-Servers to CustA-Servers, because that traffic does not traverse the firewall.  The only way you'll get traffic to traverse the firewall is to insert it _between_ the two servers.  This can be done with v-Wires, Layer2 (recommended in a virtualized datacenter) or Layer3.

Think of this like a perimeter firewall.  You don't just connect one interface to your LAN switch and call it good.  You connect one interface to the Internet, and another Interface to your internal network.  The firewall will inspect traffic passing from LAN to Internet and vice-versa.  But, just because the firewall is plugged into your LAN doesn't mean that all of your LAN-to-LAN traffic goes through the firewall...  Same thing with the VM Series.  You need to plumb the traffic appropriate so that it passes through the firewall.

In the PDF you referenced, there's a great graphic that illustrates this point:

Server A1 and Server A2 can talk to each other directly because they are on the same VDS on the same host.  Their traffic does not pass through the firewall.   However, traffic from A1 to B1 <must> go through the firewall, and that is where you can enforce policy.  Also look at Server B1 and B2, they can talk to each other without traversing the firewall.  However, for B1 to communicate with B3, that traffic must pass through 2 different firewalls - one on each ESXi host.  In this example, there are 2 different places where you could apply policy.

Hope that helps.

Hi JValentine,

thanks for answer and clarification of this scenario, that was very helpful.

To conclude, if we focus on L2 broadcast domain (one vlan) which span more than one ESX host, in case of host failure if the server B4 has HA coverage, they will be moved to host ESXi3 host (different sec zone), then our policy (deny) will failed because now, we have 2 guest VM's on same physical host and same zone, if I'm right?

Traffic must pass through the firewall in order for it to be inspected/secured.  If you place 2 guests on the same host in the same port-group & same zone, then they will be able to pass traffic between them without going through the firewall. 

If your requirement is to secure traffic between guests located on the same host, then make sure you don't place them in the same portgroup / same zone.

Hi JValentin,

Just like what you advise:

     guest1 connected to portgroup1

     guest2 connected to portgroup2

     vm-series firewall ethernet1/4 configured for abcd zone, connected to portgroup1

     vm-series firewall ethernet1/5 configured for wxyz zone, connected to portgroup2

My question is:

1. if guest1 and guest2 is in the same VLAN, then guest1 can directly connect to guest2. vm-series

can receive guest1-2 packets  but can not filter.,

2. IN vm-series administratir web, Monitor tab only display 'Deny' or 'Drop' traffic, do not display 'allow' traffic, why?

3.. Can I make l2 filter between ServerA1 and SeverA2  ServerA1 and SeverA2 in the same switch and the same vlan.

thank you.

  • 1 accepted solution
  • 4712 Views
  • 6 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!