How to Configure Virtual Wire (VWire). Device Management Initial Configuration Installation QoS Zone and DoS Protection Resolution There is a newer version of this.

• Installation Steps For Virtual Wire Mode Evaluation Software

Last time we saw how to deploy the Palo Alto NGFW in a tap mode, so we could verify our security policy would work. The main drawback of this mode is that we cannot interfere with a traffic in any way. We can see attacks, but we can do nothing to prevent them. Now we want to be able to do just that. One way of doing this is placing our PA firewall in a so called Virtual Wire or V-Wire mode. Here is our topology: Let’s describe briefly our topology. We have a Hyper-V/ESXi physical host with VMs running on it.

These VMs belong to VLANs 110 and 112. Originally, these VMs were accessed and were accessing resources through the trunk link to the Switch181, which was connected to some partner network, our own datacenter or Internet. Now we want to change this topology in a way we treat these VMs as important and protect them from being accessed by other hosts. We also want to protect them from reaching unwanted Internet sites and picking up viruses, trojans or other malware. First we will disconnect our Hyper-V host from the switch and insert our PA firewall between the host and the switch by connecting the host to the ethernet1/2 port on the PA, and then connect the ethernet1/1 port on the PA to the switch. This way we placed our PA in the line and created something called “ bump in the wire“. The port on the switch is set up like this: interface GigabitEthernet0/14 description Hyper-V Host 2 switchport trunk encapsulation dot1q switchport trunk native vlan 199 switchport trunk allowed vlan 110,112 switchport mode trunk spanning-tree portfast trunk At this point no traffic can flow to and from host, because we did not set up our firewall.

Let’s do that now. First let’s notice that PA comes with one virtual wire predefined. That virtual wire is called default-vwire and includes interfaces ethernet1/1 and ethernet1/2. There are also two zones created by default trust and untrust. By default ethernet1/1 belongs to untrust zone and ethernet1/2 belongs to trust zone: Also by default we have security policy rule called rule1 which permits all traffic from trust zone to untrust: What we need to do to make our scenario happen? Not much, actually. For starters let’s create a mirror security policy rule to allow all traffic from untrust zone to trust.

This is only to verify connectivity both way. We can create policy which is more restrictive that this. After creating second rule, our policy looks like this: If we applied our configuration now, we would not have connectivity, although it might seem all was ok. This is because we inserted our PA in the middle of the trunk link. If this link was access link, this is where our traffic would start to flow.

But because this is trunk link, which means that Ethernet frames are tagged with the VLAN ID, there is one additional step to be performed. We need to change default-vwire settings so it allows tagged frames. Under Network-Virtual Wires we can see our vwire’s settings: We can see that “ Tag Allowed” column setting is default. This means that firewall allows only untagged frames.

Installation Steps For Virtual Wire Mode Evaluation Software

We need to change this to allow all tagged frames or only specified VLANs. We click default-vwire and under “ Tag Allowed” we can see value of 0-4094 dimmed: Here we need to type 0-4094 to allow all VLANs or specify wanted VLANs. We are using only two VLANs, so will list only them: If we now commit our changes, traffic would flow both ways. Of course, nothing is blocked.

Now we need to adjust our security policy according to our needs. We can attach default profiles or create our own. Let’s, for example, block remote desktop connections to our protected VMs. We create a rule that blocks RDP connection from untrust zone to trust and make sure it is placed before the rule that allows anything from untrust to trust: After committing our changes, we can verify our settings by checking logs under Monitor-Logs-Traffic: We can see that the rule2 is allowing pings (as it would all other type of traffic), but the BLOCKRDPCONNECTIONS rule is blocking RDP or TCP/3389 sessions. We can further tune our security policy, such as attaching different profiles, but this is enough for demonstration purposes. See you next time with another deployment scenario.