Hi All,
Can anyone verify (based on my diagram below) if they have had success with
queuing IKEv2 return traffic from the "Server". I have been able to use
IKEv2 based tagging and doing it (as described in iked.conf(5)) when NAT-T
isn't used and when traffic is 'pass out' from the IKEv2 "Client", but
never for NAT-T connections from the "Server". Looking at tcpdumps of the
$ext_if on the "Server", there is never any independent egress ESP traffic
from the "Server", it all passes over the original "pass in" connection to
the server on port 4500, back to the "Client" via the "NAT GW".
As enc(4) is not queue-able, using tagging and queuing of ESP flows is the
best option (as excellently documented in iked.conf(5)) but in a NAT-T
setup, the ESP flows are 'udpencap' into the NAT-T transport and the
individual flows don't actually touch the external interface.
For road worriers, this probably isn't a problem but in my case I need to
be able to use tagging of the IKEv2 flows to budget traffic and ensure QoS
of certain network traffic.
Controlling at the network entry points is not an option as I have no
control over the network gear (3rd party management by the ISP).
Am I doing it wrong? Is this something that wasn't thought of in the
OpenIKED implementation? Or is queuing coming to enc(4) real soon?
+---------------+ +-------------+pppoe0
+--------------+
| Client | | NAT GW |130.40.2.3 | IKEv2
Server |
| 192.168.1.101 | ---------> | 192.168.1.1 | ----> Internet ----> |
10.0.1.1/8 | ------> Big Internal
+---------------+ +-------------+
202.140.3.50+--------------+ Network /8
em0
Thanks in advance,
Jason.
