# BIG-IP vWire Configuration **URL:** \ **Category:** F5 Technical Articles\ **Tags:** tmos, series-l2-mode-deployment-of-bigip, application-delivery\ **Created:** [January 21, 2020, 8:43pm UTC](https://community.f5.com/t/big-ip-vwire-configuration/67626 "2020-01-21T20:43:36Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![Romain](https://avatars.discourse-cdn.com/v4/letter/r/c2a13f/32.png) [@Romain](https://community.f5.com/u/Romain)\ **Post date:** [January 21, 2020, 8:43pm UTC](https://community.f5.com/t/big-ip-vwire-configuration/67626/1 "2020-01-21T20:43:36Z")
## Introduction The insertion of inline security and application delivery devices into an existing network infrastructure can require significant network re-design and architecture changes. Deploying tools that operate transparently at Layer 2 of the OSI model (L2) can greatly reduce the complexity and disruption associated with these implementations. F5’s BIG-IP hardware appliances can be inserted as L2 devices in existing networks.  This can be achieved using either virtual Wire ([vWire](https://techdocs.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/tmos-routing-administration-13-1-0/2.html)) or by bridging 2 Virtual LANs using a [VLAN Groups](https://techdocs.f5.com/kb/en-us/products/big-ip-aam/manuals/product/aam-network-configuration-11-5-0/8.html). This article focusses on the configuration of vWire on a standalone BIG-IP with 2 physical interface. The 2 physical interfaces are bridged together and allow traffic through the BIG-IP behaving like a wire. **Note: Virtual Wire is available on BIG-IP hardware.** ![image_285579.png](https://d20hrnpixdzcsd.cloudfront.net/original/3X/5/1/519842ebc72a685cce0fe15cc3aa2388edba2f9a.png) For more information on F5 security and other modules and their configuration please refer to [www.f5.com](http://www.f5.com/) to access user guides, recommended practices and other deployment documentation.  The configuration of BIG-IP modules, such as those providing DDoS protection/mitigation or SSL visibility, is beyond the scope of this article and is the subject of other user guides. ## Under the covers Building virtual wires leverages the underlying configuration of two separate VLAN objects that are bridged using a VLAN group.  For convenience, going forward, one will be called the “ingress VLAN object” and the other one the “egress VLAN object”. This is significant because, you will be able to use these objects in your configuration to setup listeners and associate them to either VLAN object. ## Configuration ### Using the CLI Overview: 1. Modify the 2 interfaces’ mode to support virtual wire 2. Create 2 VLAN objects using the interfaces selected above using VLAN id 4096 - this is the default “any” VLAN ID which will accept and forward all 802.1Q tagged traffic. 3. Create 2 VLAN objects using the same interfaces above using the desired VLAN id (512 will be used as an example below) 4. Create VLAN Groups to bridge the VLAN’s created above Sample Configuration: The sample below creates a virtual wire that will work with 802.1Q VLAN id. 512. **Configure interfaces to support virtual wire:** ```ql-syntax root@(localhost)(cfg-sync Standalone)(Active)(/Common)(tmos)# modify net interface 1.1 port-fwd-mode virtual-wire root@(localhost)(cfg-sync Standalone)(Active)(/Common)(tmos)# modify net interface 1.2 port-fwd-mode virtual-wire ``` **Create all VLAN tag VLAN objects:** ```ql-syntax root@(localhost)(cfg-sync Standalone)(Active)(/Common)(tmos)# create net vlan Direct_all_vlan_4096_1 tag 4096 interfaces add { 1.1 { tagged } } root@(localhost)(cfg-sync Standalone)(Active)(/Common)(tmos)# create net vlan Direct_all_vlan_4096_2 tag 4096 interfaces add { 1.2 { tagged } } ``` **Create specific (802.1Q tag 512) VLAN objects:** ```ql-syntax root@(localhost)(cfg-sync Standalone)(Active)(/Common)(tmos)# create net vlan Direct_vlan_512_1 tag 512 interfaces add { 1.1 { tagged } } root@(localhost)(cfg-sync Standalone)(Active)(/Common)(tmos)# create net vlan Direct_vlan_512_2 tag 512 interfaces add { 1.2 { tagged } } ``` **Create VLAN Groups:** ```ql-syntax root@(localhost)(cfg-sync Standalone)(Active)(/Common)(tmos)# create net vlan-group Direct_all_vlan members add { Direct_all_vlan_4096_1 Direct_all_vlan_4096_2 } mode virtual-wire root@(localhost)(cfg-sync Standalone)(Active)(/Common)(tmos)# create net vlan-group Direct_vlan_512 members add { Direct_vlan_512_1 Direct_vlan_512_2 } mode virtual-wire ``` **Don’t forget to save:** ```ql-syntax root@(localhost)(cfg-sync Standalone)(Active)(/Common)(tmos)# save sys config partitions all ``` ### Using the WEBUI: Overview: There is a single interface to create and configure the necessary configuration objects. 1. Create a virtual wire with the desired interfaces 2. Associate VLANs that will be used by the BIG-IP function (e.g. SSL Orchestrator, Traffic Manager, etc.) 3. Apply the configuration Sample Configuration: From the BIG-IP WebUI (Network\>\>Virtual Wire): - Select Create (upper right) - Enter the values for interfaces added to the virtual wire - Enter VLAN information and click on Add for every VLAN object created ![image_285579.jpg](https://d20hrnpixdzcsd.cloudfront.net/original/3X/6/d/6d0349cd7d34c6a57d593f547d507f9c192ffde9.jpeg) Once the all the selections are made and you are ready to implement, click on “Commig Changes to System”: ![image_285579.jpg](https://d20hrnpixdzcsd.cloudfront.net/original/2X/6/6374921007faf36deed571a27f6aabc17cd8892a.jpeg) The resulting screen will look like the following: ![image_285579.jpg](https://d20hrnpixdzcsd.cloudfront.net/original/3X/a/6/a6dccfc2674448d6736dfd9733189721ee103f01.jpeg) The resulting VLAN configuration will look as follows: ![image_285579.jpg](https://d20hrnpixdzcsd.cloudfront.net/original/3X/1/7/17d680a10c097efe8a9a4d053fc5209b282f4ca5.jpeg) ## Notable Effects-Caveats ### Virtual Wire Created Through WebUI - Configuring vWire via the WebUI will result in creating the aforementioned VLANs automatically. During the creation process, an identifier is appended to the VLAN object-name. This identifier will vary from one BIG-IP to another. - When deploying a pair of BIG-IP’s in HA mode, the virtual wire configuration will create objects with different names on each BIG-IP. So for example, the creation of vwire\_lab01 will result in the creation of VLAN objects vwire\_lab01\_1\_567 and vwire\_lab01\_2\_567 on one BIG-IP, while the other BIG-IP will have vwire\_lab01\_1\_000 and vwire\_lab01\_2\_000 in its configuration. For modules like SSL Orchestrator, or in cases where a Virtual Server needs to be associated with a specific VLAN, the numbering is problematic. The administrator will not be able to associate the topology or Virtual Server to one VLAN object (vwire\_lab01\_2\_567) on the first BIG-IP and the other VLAN object (vwire\_lab01\_2\_000) on the peer BIG-IP. (this is not possible for a number of reasons, one of which is the way configurations are synchronized between BIG-IP devices) - This results in the necessary manual configuration using the procedure described above. ### VLAN Objects Available for Configuration After creating virtual wire objects, VLANs are available for you to configure the desired services. This includes BIG-IP LTM or SSL Orchestrator objects allowing you to take different actions when traffic comes in one or the other “side” of the virtual wire. For example, you might want connections initiated from the LAN (in the picture above) to be decrypted for security inspection purposes, while having traffic coming in from the firewall passed through transparently. ## Conclusion Deploying the BIG-IP in virtual wire mode provides a great way to insert services into your network without affecting the rest of the network configuration, routing and forwarding. The flexibility of the BIG-IP allows you to control the traffic traversing the BIG-IP on what ever VLAN (tagged or not). I hope this has been useful. ---
**Author:** ![Dojs](https://avatars.discourse-cdn.com/v4/letter/d/0ea827/32.png) [@Dojs](https://community.f5.com/u/Dojs)\ **Post date:** [January 27, 2020, 7:34pm UTC](https://community.f5.com/t/big-ip-vwire-configuration/67626/2 "2020-01-27T19:34:36Z")
Great article. We are using this feature and works very well. The same configuration that you shared. ---
**Author:** ![Saravanan\_M\_K](https://d1p9zq3aats0t8.cloudfront.net/user_avatar/community.f5.com/saravanan_m_k/32/5662_2.png) [@Saravanan\_M\_K](https://community.f5.com/u/Saravanan_M_K)\ **Post date:** [January 29, 2020, 8:45am UTC](https://community.f5.com/t/big-ip-vwire-configuration/67626/3 "2020-01-29T08:45:56Z")
Thanks for the article. What is the purpose of creating 4096 vlan (in addition to the one we want which is 511)? ---
**Author:** ![Romain](https://avatars.discourse-cdn.com/v4/letter/r/c2a13f/32.png) [@Romain](https://community.f5.com/u/Romain)\ **Post date:** [January 29, 2020, 5:57pm UTC](https://community.f5.com/t/big-ip-vwire-configuration/67626/4 "2020-01-29T17:57:09Z")
VLAN 4096 is a reserved VLAN number that represents a wildcard. Basically the 4096 VLAN allows all tagged traffic to traverse the BIG-IP. Adding a specific VLAN number (VLAN 501 in this case) allows the administrator to associate a listener to that specific VLAN. For example if this is deployed with F5’s SSL inspection product, you can associate a service chain/topology to that specific VLAN and associate another service-chain/topology to another VLAN (602?). I hope this answers your question. ---
**Author:** ![Saravanan\_M\_K](https://d1p9zq3aats0t8.cloudfront.net/user_avatar/community.f5.com/saravanan_m_k/32/5662_2.png) [@Saravanan\_M\_K](https://community.f5.com/u/Saravanan_M_K)\ **Post date:** [February 23, 2020, 8:54pm UTC](https://community.f5.com/t/big-ip-vwire-configuration/67626/5 "2020-02-23T20:54:34Z")
Yes. Thanks for the clarification. ---
**Author:** ![ARAV](https://avatars.discourse-cdn.com/v4/letter/a/b9e5f3/32.png) [@ARAV](https://community.f5.com/u/ARAV)\ **Post date:** [October 14, 2020, 12:02pm UTC](https://community.f5.com/t/big-ip-vwire-configuration/67626/6 "2020-10-14T12:02:05Z")
Good article ---
**Author:** ![Nikoolayy1](https://d1p9zq3aats0t8.cloudfront.net/user_avatar/community.f5.com/nikoolayy1/32/3589_2.png) [@Nikoolayy1](https://community.f5.com/u/Nikoolayy1)\ **Post date:** [March 21, 2021, 12:47pm UTC](https://community.f5.com/t/big-ip-vwire-configuration/67626/7 "2021-03-21T12:47:11Z")
Thanks saw this on Palo Alto but I did not know that F5 can also do it. ---
**Author:** ![spalande](https://d1p9zq3aats0t8.cloudfront.net/user_avatar/community.f5.com/spalande/32/10043_2.png) [@spalande](https://community.f5.com/u/spalande)\ **Post date:** [October 19, 2022, 6:52pm UTC](https://community.f5.com/t/big-ip-vwire-configuration/67626/8 "2022-10-19T18:52:12Z")
Hi @Romain  - thanks for the article. Can we use this set up to use advance WAF for TLS traffic? If we have BIGIP in layer2 mode without any selfIP defined, but would like to use WAF for application traffic passing through it? How we can define virtual servers and how F5 can decrypt the traffic without being acting as reverse proxy? Any guide or pointer to the solution will be appreciable. ---
**Author:** ![Nikoolayy1](https://d1p9zq3aats0t8.cloudfront.net/user_avatar/community.f5.com/nikoolayy1/32/3589_2.png) [@Nikoolayy1](https://community.f5.com/u/Nikoolayy1)\ **Post date:** [November 18, 2022, 7:16pm UTC](https://community.f5.com/t/big-ip-vwire-configuration/67626/9 "2022-11-18T19:16:42Z")
Hello @Romain Just a quick note does vWire allow AFM NAT as yes there is no self-ip for the vWire but if snat/nat pool (not Automap) is used is it possible or this will break the vWire logical link between interfaces? ---
**Author:** ![Nikoolayy1](https://d1p9zq3aats0t8.cloudfront.net/user_avatar/community.f5.com/nikoolayy1/32/3589_2.png) [@Nikoolayy1](https://community.f5.com/u/Nikoolayy1)\ **Post date:** [November 23, 2022, 12:03pm UTC](https://community.f5.com/t/big-ip-vwire-configuration/67626/10 "2022-11-23T12:03:32Z")
As a fast note after checking some stuff I saw that in 15.1.x vWire does not support self-ip or ARP/Proxy ARP so NAT seems not an option but in 16.1.3.2 ARP and SELF-IP for vWires are supported so NAT probably can work there (have not tested NAT on 16.1.3 to 100% confirm this) but for NAT or IPS/port misuse  as I see it Layer 3 AFM/LTM deployments are better.