Virtual Wire Deployments
In a virtual wire deployment, you install a firewall transparently on a network segment by binding two firewall ports (interfaces) together. The virtual wire logically connects the two interfaces; hence, the virtual wire is internal to the firewall.
Use a virtual wire deployment only when you want to seamlessly integrate a firewall into a topology and the two connected interfaces on the firewall need not do any switching or routing. For these two interfaces, the firewall is considered a bump in the wire .
A virtual wire deployment simplifies firewall installation and configuration because you can insert the firewall into an existing topology without assigning MAC or IP addresses to the interfaces, redesigning the network, or reconfiguring surrounding network devices. The virtual wire supports blocking or allowing traffic based on virtual LAN (VLAN) tags, in addition to supporting security policy rules, App-ID, Content-ID, User-ID, decryption, LLDP, active/passive and active/active HA, QoS, zone protection (with some exceptions), DoS protection, and NAT.
Each virtual wire interface is directly connected to a Layer 2 or Layer 3 networking device or host. The virtual wire interfaces have no Layer 2 or Layer 3 addresses. When one of the virtual wire interfaces receives a frame or packet, it ignores any Layer 2 or Layer 3 addresses for switching or routing purposes, but applies your security or NAT policy rules before passing an allowed frame or packet over the virtual wire to the second interface and on to the network device connected to it.
You wouldn’t use a virtual wire deployment for interfaces that need to support switching, VPN tunnels, or routing because they require a Layer 2 or Layer 3 address. A virtual wire interface doesn’t use an interface management profile, which controls services such as HTTP and ping and therefore requires the interface have an IP address.
By default, a virtual wire interface forwards all non-IP traffic it receives.
All firewalls shipped from the factory have two Ethernet ports (ports 1 and 2) preconfigured as virtual wire interfaces, and these interfaces allow all untagged traffic.
If you don’t intend to use the preconfigured virtual wire, you must delete that configuration to prevent it from interfering with other settings you configure on the firewall. See Set Up Network Access for External Services.
Layer 2 and Layer 3 Packets over a Virtual Wire
A virtual wire interface will allow Layer 2 and Layer 3 packets from connected devices to pass transparently as long as the policies applied to the zone or interface allow the traffic. The virtual wire interfaces themselves don’t participate in routing or switching.
For example, the firewall doesn’t decrement the TTL in a traceroute packet going over the virtual link because the link is transparent and doesn’t count as a hop. Packets such as Operations, Administration and Maintenance (OAM) protocol data units (PDUs), for example, don’t terminate at the firewall. Thus, the virtual wire allows the firewall to maintain a transparent presence acting as a pass-through link, while still providing security, NAT, and QoS services.
In order for bridge protocol data units (BPDUs) and other Layer 2 control packets (which are typically untagged) to pass through a virtual wire, the interfaces must be attached to a virtual wire object that allows untagged traffic, and that is the default. If the virtual wire object Tag Allowed field is empty, the virtual wire allows untagged traffic. (Security policy rules don’t apply to Layer 2 packets.)
In order for routing (Layer 3) control packets to pass through a virtual wire, you must apply a security policy rule that allows the traffic to pass through. For example, apply a security policy rule that allows an application such as BGP or OSPF.
If you want to be able to apply security policy rules to a zone for IPv6 traffic arriving at a virtual wire interface on the firewall, enable IPv6 firewalling. Otherwise, IPv6 traffic is forwarded transparently across the wire.
If you enable multicast firewalling for a virtual wire object and apply it to a virtual wire interface, the firewall inspects multicast traffic and forwards it or not, based on security policy rules. If you don’t enable multicast firewalling, the firewall simply forwards multicast traffic transparently.
Fragmentation on a virtual wire occurs the same way as in other interface deployment modes.
Port Speeds of Virtual Wire Interfaces
Different firewall models provide various numbers of copper and fiber optic ports, which operate at different speeds. A virtual wire can bind two Ethernet ports of the same type (both copper or both fiber optic), or bind a copper port with a fiber optic port. By default, the Link Speed of copper ports on the firewall is set to auto, which means the firewall automatically negotiates their speed and transmission mode ( Link Duplex). When you Configure a Virtual Wire, you can also select a specific Link Speed and Link Duplex but the values for these settings must be the same for both ports in any single virtual wire.
LLDP over a Virtual Wire
Virtual wire interfaces can use LLDP to discover neighboring devices and their capabilities, and LLDP allows neighboring devices to detect the presence of the firewall in the network. LLDP makes troubleshooting easier especially on a virtual wire, where the firewall would typically go undetected by a ping or traceroute passing through the virtual wire. LLDP provides a way for other devices to detect the firewall in the network. Without LLDP, the presence of a firewall through the virtual wire link is practically undetectable to all network management systems.
Aggregated Interfaces for a Virtual Wire
You can Configure an Aggregate Interface Group of virtual wire interfaces, but virtual wires don’t use LACP. If you configure LACP on devices that connect the firewall to other networks, the virtual wire will pass LACP packets transparently without performing LACP functions.
In order for aggregate interface groups to function properly, ensure all links belonging to the same LACP group on the same side of the virtual wire are assigned the same zone.
High Availability Path Monitoring for a Virtual Wire Path Group
If you configure the firewall to perform path monitoring for High Availability using a virtual wire path group, the firewall attempts to resolve ARP for the configured destination IP address by sending ARP packets out both of the virtual wire interfaces. The destination IP address that you are monitoring must be on the same subnetwork as one of the devices surrounding the virtual wire.
Virtual wire interfaces support both active/passive and active/active HA. For an active/active HA deployment with a virtual wire, the scanned packets must be returned to the receiving firewall to preserve the forwarding path. Therefore, if a firewall receives a packet that belongs to the session that the peer HA firewall owns, it sends the packet across the HA3 link to the peer.
For PAN-OS 7.1 and later releases, you can configure the passive firewall in an HA pair to allow peer devices on either side of the firewall to pre-negotiate LLDP and LACP over a virtual wire before an HA failover occurs. Such a configuration for LACP and LLDP Pre-Negotiation for Active/Passive HA speeds up HA failovers.
Zone Protection for a Virtual Wire Interface
You can apply zone protection to a virtual wire interface, but because virtual wire interfaces don’t perform routing, you can’t apply Packet-Based Attack Protection to packets coming with a spoofed IP address, nor can you suppress ICMP TTL Expired error packets or ICMP Frag Needed packets.
VLAN-Tagged Traffic
Virtual wire interfaces by default allow all untagged traffic. You can, however, use a virtual wire to connect two interfaces and configure either interface to block or allow traffic based on the virtual LAN (VLAN) tags. VLAN tag 0 indicates untagged traffic.
You can also create multiple subinterfaces, add them into different zones, and then classify traffic according to a VLAN tag or a combination of a VLAN tag with IP classifiers (address, range, or subnet) to apply granular policy control for specific VLAN tags or for VLAN tags from a specific source IP address, range, or subnet.
Virtual Wire Subinterfaces
Virtual wire deployments can use virtual wire subinterfaces to separate traffic into zones. Virtual wire subinterfaces provide flexibility in enforcing distinct policies when you need to manage traffic from multiple customer networks. The subinterfaces allow you to separate and classify traffic into different zones (the zones can belong to separate virtual systems, if required) using the following criteria:
VLAN tags —The example in Figure: Virtual Wire Deployment with Subinterfaces (VLAN Tags only) shows an ISP using virtual wire subinterfaces with VLAN tags to separate traffic for two different customers. VLAN tags in conjunction with IP classifiers (address, range, or subnet) — The following example shows an ISP with two separate virtual systems on a firewall that manages traffic from two different customers. On each virtual system, the example illustrates how virtual wire subinterfaces with VLAN tags and IP classifiers are used to classify traffic into separate zones and apply relevant policy for customers from each network.
Virtual Wire Subinterface Workflow
Configure two Ethernet interfaces as type virtual wire, and assign these interfaces to a virtual wire.
Create subinterfaces on the parent Virtual Wire to separate CustomerA and CustomerB traffic. Make sure that the VLAN tags defined on each pair of subinterfaces that are configured as virtual wire(s) are identical. This is essential because a virtual wire does not switch VLAN tags.
Create new subinterfaces and define IP classifiers. This task is optional and only required if you wish to add additional subinterfaces with IP classifiers for further managing traffic from a customer based on the combination of VLAN tags and a specific source IP address, range or subnet. You can also use IP classifiers for managing untagged traffic. To do so, you must create a subinterface with the vlan tag “0”, and define sub-interface(s) with IP classifiers for managing untagged traffic using IP classifiers.
IP classification may only be used on the subinterfaces associated with one side of the virtual wire. The subinterfaces defined on the corresponding side of the virtual wire must use the same VLAN tag, but must not include an IP classifier.
Figure: Virtual Wire Deployment with Subinterfaces (VLAN Tags only)
Figure: Virtual Wire Deployment with Subinterfaces (VLAN Tags only) depicts CustomerA and CustomerB connected to the firewall through one physical interface, ethernet1/1, configured as a virtual wire; it is the ingress interface. A second physical interface, ethernet1/2, is also part of the virtual wire; it is the egress interface that provides access to the internet.
For CustomerA, you also have subinterfaces ethernet1/1.1 (ingress) and ethernet1/2.1 (egress). For CustomerB, you have the subinterface ethernet1/1.2 (ingress) and ethernet1/2.2 (egress). When configuring the subinterfaces, you must assign the appropriate VLAN tag and zone in order to apply policies for each customer. In this example, the policies for CustomerA are created between Zone1 and Zone2, and policies for CustomerB are created between Zone3 and Zone4.
When traffic enters the firewall from CustomerA or CustomerB, the VLAN tag on the incoming packet is first matched against the VLAN tag defined on the ingress subinterfaces. In this example, a single subinterface matches the VLAN tag on the incoming packet, hence that subinterface is selected. The policies defined for the zone are evaluated and applied before the packet exits from the corresponding subinterface.
The same VLAN tag must not be defined on the parent virtual wire interface and the subinterface. Verify that the VLAN tags defined on the Tag Allowed list of the parent virtual wire interface ( Network > Virtual Wires) are not included on a subinterface.
Figure: Virtual Wire Deployment with Subinterfaces (VLAN Tags and IP Classifiers) depicts CustomerA and CustomerB connected to one physical firewall that has two virtual systems (vsys), in addition to the default virtual system (vsys1). Each virtual system is an independent virtual firewall that is managed separately for each customer. Each vsys has attached interfaces/subinterfaces and security zones that are managed independently.
Figure: Virtual Wire Deployment with Subinterfaces (VLAN Tags and IP Classifiers)
Vsys1 is set up to use the physical interfaces ethernet1/1 and ethernet1/2 as a virtual wire; ethernet1/1 is the ingress interface and ethernet1/2 is the egress interface that provides access to the internet. This virtual wire is configured to accept all tagged and untagged traffic with the exception of VLAN tags 100 and 200 that are assigned to the subinterfaces.
CustomerA is managed on vsys2 and CustomerB is managed on vsys3. On vsys2 and vsys3, the following vwire subinterfaces are created with the appropriate VLAN tags and zones to enforce policy measures.
Customer Vsys Vwire Subinterfaces Zone VLAN Tag IP Classifier
A 2 e1/1.1 (ingress) e1/2.1 (egress) Zone3 Zone4 100 100 None
2 e1/1.2 (ingress) e1/2.2 (egress) Zone5 Zone6 100 100 IP subnet 192.1.0.0/16
2 e1/1.3 (ingress) e1/2.3 (egress) Zone7 Zone8 100 100 IP subnet 192.2.0.0/16
B 3 e1/1.4 (ingress) e1/2.4 (egress) Zone9 Zone10 200 200 None
When traffic enters the firewall from CustomerA or CustomerB, the VLAN tag on the incoming packet is first matched against the VLAN tag defined on the ingress subinterfaces. In this case, for CustomerA, there are multiple subinterfaces that use the same VLAN tag. Hence, the firewall first narrows the classification to a subinterface based on the source IP address in the packet. The policies defined for the zone are evaluated and applied before the packet exits from the corresponding subinterface.
For return-path traffic, the firewall compares the destination IP address as defined in the IP classifier on the customer-facing subinterface and selects the appropriate virtual wire to route traffic through the accurate subinterface.
The same VLAN tag must not be defined on the parent virtual wire interface and the subinterface. Verify that the VLAN tags defined on the Tag Allowed list of the parent virtual wire interface ( Network > Virtual Wires) are not included on a subinterface.
Configure a Virtual Wire
The following task shows how to configure two virtual wire interfaces (Ethernet 1/3 and Ethernet 1/4 in this example) to create a virtual wire (see Virtual Wire Deployments). The two interfaces must have the same Link Speed and transmission mode ( Link Duplex). For example, a full-duplex 1000Mbps copper port matches a full-duplex 1Gbps fiber optic port.
Configure a Virtual Wire
Configure the first virtual wire interface. Select Network > Interfaces > Ethernet and select an interface you have cabled ( ethernet1/3 in this example). Set the Interface Type to Virtual Wire and click OK.
Attach the interface to a virtual wire object. While still on the same Ethernet interface, on the Config tab, select Virtual Wire and click New Virtual Wire. Enter a Name for the virtual wire object. For Interface1, select the interface you just configured ( ethernet1/3). (Only interfaces configured as virtual wire interfaces appear in the drop-down.) For Tag Allowed, enter 0 to indicate untagged traffic (such as BPDUs and other Layer 2 control traffic) is allowed. The absence of a tag implies tag 0. Enter additional allowed tag integers or ranges of tags, separated by commas (default is 0; range is 0 to 4,094). Select Multicast Firewalling if you want to be able to apply security policy rules to multicast traffic going across the virtual wire. Otherwise, multicast traffic is transparently forwarded across the virtual wire. Select Link State Pass Through so the firewall can function transparently. When the firewall detects a link down state for a link of the virtual wire, it brings down the other interface in the virtual wire pair. Thus, devices on both sides of the firewall see a consistent link state, as if there were no firewall between them. If you don’t select this option, link status is not propagated across the virtual wire. Click OK to save the virtual wire object.
Determine the link speed of the virtual wire interface. While still on the same Ethernet interface, select Advanced and note or change the Link Speed. The port type determines the speed settings available in the drop down. By default, copper ports are set to auto negotiate link speed. Both virtual wire interfaces must have the same link speed. Click OK to save the Ethernet interface.
Configure the second virtual wire interface. Repeat the preceding steps to configure the second interface ( ethernet1/4 in this example). When you select the Virtual Wire object you created, the firewall automatically adds the second virtual wire interface as Interface2.
Create a separate security zone for each virtual wire interface. Select Network > Zones and Add a zone. Enter the Name of the zone (such as internet ). For Location, select the virtual system where the zone applies. For Type, select Virtual Wire. Add the Interface that belongs to the zone. Click OK.
(Optional) Create security policy rules to allow Layer 3 traffic across the virtual wire. Create a Security Policy Rule to allow traffic from the user zone to the internet zone, and another to allow traffic from the internet zone to the user zone, selecting the applications you want to allow, such as BGP or OSPF.
(Optional) Enable IPv6 firewalling. If you want to be able to apply security policy rules to IPv6 traffic arriving at a virtual wire interface, enable IPv6 firewalling. Otherwise, IPv6 traffic is forwarded transparently. Select Device > Setup > Session and edit Session Settings. Select Enable IPv6 Firewalling. Click OK.
Commit your changes. Click Commit.
(Optional) Configure an LLDP profile and apply it to the virtual wire interfaces. Configure LLDP.

Related Documentation