Last updated on: June 16 2024.

Virtual Server

This page describes the role of a Virtual Server in IPsec packet flow and some considerations on handling the flows inside IPsec.

TL;DR

A Virtual Server does not handle ISAKMP. The VLAN that sees connection establishment attempts must be enabled on the Virtual Server. IPsec selectors must match the packet after Virtual Server processing.

Role of the Virtual Server

For a tunnel to pass user traffic, a Virtual Server (VS) must exist to handle the private network flow. The VS does not process the ISAKMP or ESP because internal listeners are automatically setup for that part.

The Virtual Server handles local to remote traffic before IPsec is involved.

Remote to local traffic comes out of the tunnel and as long as the packet passes traffic selector checking, if the packet is not part of an already established connection it is handed to the closest matching Virtual Server.

Bi-Directional Traffic

Most applications require bi-directional flows, TCP can’t operate without it, but keep in mind which side establishes connections. Some tunnels will have endpoints on both sides that can initiate a new host-to-host flow and in that case either a broadly listening Virtual Server is required or, more securely, two specific Virtual Servers to catch connection establishment from either side.

The following configuration allows a host 10.2.1.1 start a TCP connection to 10.1.1.1.

The same in tmsh:

ltm virtual ipsec-0 {
    destination 10.1.1.0:any
    ip-forward
    ip-protocol tcp
    mask 255.255.255.0
    profiles {
        fastL4 { }
    }
    source 10.2.1.0/24
    translate-address disabled
    translate-port disabled
}

TCP connections to 10.1.1.1 from 10.2.1.1 will establish. However, new connections originated by 10.1.1.1 cannot reach 10.2.1.1. This would be acceptable for normal client-to-application connectivity.

To allow both sides to establish a new connection, a second virtual server is required.

ltm virtual ipsec-2 {
    destination 10.2.1.0:any
    ip-forward
    ip-protocol tcp
    mask 255.255.255.0
    profiles {
        fastL4 { }
    }
    source 10.1.1.0/24
    translate-address disabled
    translate-port disabled
}

Now both sides can establish a connection.

Check Statistics

When a VS is configured to specifically handle IPsec flows, look at the VS statistics in the web UI or with the command tmsh show ltm virtual <name>.

# tmsh show ltm virtual ipsec-2 

------------------------------------------------------------------
Ltm::Virtual Server: ipsec-2   
------------------------------------------------------------------
Status                 
  Availability     : unknown   
  State            : enabled   
  Reason           : ...
  CMP              : enabled   
  CMP Mode         : all-cpus  
  Destination      : 10.2.1.0:any
                       
Traffic                             ClientSide  Ephemeral  General
  Bits In                                36.1K          0        -
  Bits Out                               42.3K          0        -
  Packets In                                27          0        -
  Packets Out                               31          0        -

The presence of packets in and out indicates that the VS is likely doing its job.

VLAN Listeners

If the Virtual Server is not listening on all VLANs, the VLAN associated with the side that establishes a user flow must be added. If all traffic originates local to the BIG-IP, the VLAN that the user traffic arrives on must be added as a listener.

If the traffic originates from the tunnel side, the external VLAN (the VLAN over which the tunnel is established) must be added. If the ipsec-policy is in “interface” mode, the IPsec interface must be added, not the external VLAN.

The config below shows a Virtual Server setup to handle inbound connections from both an internal VLAN and the IPsec interface (not tunnel mode).

The same config in tmsh:

# tmsh list ltm virtual vlans-enabled
ltm virtual ipsec-0 {
    vlans-enabled
}

# tmsh list ltm virtual vlans
ltm virtual ipsec-0 {
    vlans {
        ipsec-tunnel
        vlan-internal-2-0
    }
}

NAT on the Virtual Server

NAT on the Virtual Server and NAT Detection for ISAKMP tunnel negotiation are two different things. NAT on the Virtual Server changes the IP address of the user flows inside the tunnel. As a result the traffic-selectors have to reflect the traffic in its NAT form.

For example if this global NAT translation existed:

ltm nat /Common/NAT-1 {
    inherited-traffic-group true
    originating-address 192.168.15.2
    traffic-group /Common/traffic-group-1
    translation-address 172.17.1.1
}

Then the traffic selector would be something like this:

net ipsec traffic-selector /Common/my-nat-selector {
    destination-address 192.168.15.2/32
    ipsec-policy /Common/Rio
    source-address 10.1.1.0/24
}

Top | Flowchart | Contents