Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 07 May 2008 21:41:23 -0400
From:      "Derek (freebsd-ipfw)" <482254ac@razorfever.net>
To:        freebsd-ipfw@freebsd.org
Subject:   Dummynet, gif, and ipsec
Message-ID:  <48225A43.3080909@razorfever.net>

Next in thread | Raw E-Mail | Index | Archive | Help
Hello,

I am trying to do some traffic shaping on my router using dummynet.  The 
router is one endpoint in an ipsec tunnel (configured as the handbook 
suggests).

I'm running voip inside ipsec, so the goal here is to minimize the delay
in transmitting the encapsulated voip packets.  I'd like to be able to 
classify other traffic inside ipsec as well.

I currently have my outgoing pipe configured with 5 queues:

pipe 10 config delay 0                  #outgoing pipe send
queue 101 config pipe 10 weight 100     #highest priority
queue 102 config pipe 10 weight 20
queue 103 config pipe 10 weight 5
queue 104 config pipe 10 weight 1       #lowest priority

I have all of my outgoing ipsec queued into queue 101, with most of my 
other traffic hitting the other queues.

I have set up additional queues to run over top of my
gif interfaces:

pipe 20 config delay 0                  #VPN outgoing pipe (gif*) send
queue 201 config pipe 20 weight 100     #highest priority
queue 202 config pipe 20 weight 20
queue 203 config pipe 20 weight 5
queue 204 config pipe 20 weight 1       #lowest priority

As I'm running a tunnel, I have specific subnets that are communicating
over the gif interfaces.

If I simply allow the traffic, everything works fine:

add 7200 allow ip from table(1) to table(1)

If I try to queue traffic going out, packets disappear right after the
queue:

add 7020 queue 203 ip from table(1) to table(1) out via gif*
add 7025 count ip from table(1) to table(1) out via gif*
add 7200 allow ip from table(1) to table(1)

I zero my stats, and let the traffic run for a little while.  When I
show my stats again, there is a gross discrepancy in the counts at 7020,
and 7025.  Packets that normally show up on the other end of the tunnel,
don't.  If I remove the count, the packets still don't show up.

If anyone can recognize why this is happening, or provide suggestions on
how to troubleshoot it, I'd greatly appreciate it.

If your are doing a similar approach successfully, I'd like to know.

If you have alternative suggestions on how to shape traffic based on
what is inside an ipsec tunnel, that is also appreciated.

I tried using IPFW's tag command, and I think that is the best way to do 
what I want to do, period.  Tag the unencrypted data as it is going out 
the gif interface, and queue the IPSEC traffic based on the packet tag, 
but the tag disappears after IPSEC processing.

Also, I'm aware of using the IP TOS flags for this, and I may have to go 
that route (based on the research I've done), but I want to know why 
what I'm currently is failing the way it is.  The TOS flags don't seem 
as flexible, as there are only a few classes that I can use, and there 
isn't any built-in way to modify these flags.  I'd have to use netgraph, 
or divert, and I'm not too keen on either of these approaches right now.

Best regards, and thanks!
-- Derek



More details about the machine:

Running 6.3-RELEASE

/etc/sysctl.conf:
net.inet.ip.fw.one_pass=0

Kernel:
include SMP
ident           GW2

options         MPTABLE_FORCE_HTT
options         NO_F00F_HACK
options         DEVICE_POLLING
options         AUTO_EOI_1

options         IPSEC
options         IPSEC_ESP
options         IPSEC_FILTERGIF

device          carp
device          disc

options         IPFIREWALL
options         IPFIREWALL_VERBOSE
options         IPFIREWALL_FORWARD
options         IPDIVERT
options         IPSTEALTH
options         TCP_DROP_SYNFIN
options         DUMMYNET
options         ZERO_COPY_SOCKETS
options         HZ=1000

device          snp



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?48225A43.3080909>