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
}