Date:	Sat, 30 May 2015 16:51:11 -0400 (EDT)
From:	"jsullivan@...nsourcedevel.com" <jsullivan@...nsourcedevel.com>
To:	netdev@...r.kernel.org
Subject: Re: Ingress tc filters with IPSec


> On May 30, 2015 at 4:12 PM "jsullivan@...nsourcedevel.com"
> <jsullivan@...nsourcedevel.com> wrote:
>
>
>
> > On May 30, 2015 at 2:24 AM "John A. Sullivan III"
> > <jsullivan@...nsourcedevel.com> wrote:
> >
> >
> > On Sat, 2015-05-30 at 01:52 -0400, John A. Sullivan III wrote:
> > > Argh! yet another obstacle from my ignorance. We are attempting ingress
> > > traffic shaping using IFB interfaces on traffic coming via GRE / IPSec.
> > > Filters and hash tables are working fine with plain GRE including
> > > stripping the header. We even got the ematch filter working so that the
> > > ESP packets are the only packets not redirected to IFB.
> > >
> > > But, regardless of whether we redirect ESP packets to IFB, the filters
> > > never see the decrypted packets. I thought the packets passed through
> > > the interface twice - first encrypted and they decrypted. However,
> > > tcpdump only shows the ESP packets on the interface.
> > >
> > > How do we apply filters to the packets after decryption? Thanks - John
> >
> > I see what changed. In the past, this seemed to work but we were using
> > tunnel mode. We were trying to use transport mode in this application
> > but that seems to prevent the decrypted packet contents from appearing
> > again on the interface. Reverting to tunnel mode made the contents
> > visible again and our filters are working as expected - John
>
> Alas, this is still a problem since we are using VRRP and the tunnel end
> points
> are the virtual IP addresses. That makes StrongSWAN choke on selector matching
> in tunnel mode so back to trying to make transport mode work.
>
> I am guessing we do not see the second pass of the packet because it is only
> encrypted and not encapsulated. So my hunch is that we ned to pass the ESP
> packet into the ifb qdisc but need to look elsewhere the packet for the filter
> matching information. We know that matching on the normal offsets does not
> work
> so I am hoping the decrypted packet is decipherable by the filter matching
> logic
> but just still has all the ESP transport header attached.
>
> Normally, to extract the contents of my GRE tunnel, I would place them into a
> separate hash table with the GRE header stripped off and then filter them into
> TCP and UDP hast tables:
>
> tc filter add dev ifb0 parent 11:0 protocol ip prio 2 u32 match ip protocol 47
> 0xff match u16 0x0800 0xffff at 22 link 11: offset at 0 mask 0f00 shift 6 plus
> 4
> eat
>
> So we match the GRE protocol and determine that GRE is carrying an IP packet.
> With the ESP transport header and IV (AES = 16B) interposed between the IP
> header and the GRE header, I suppose the first part of this filter becomes:
>
> tc filter add dev ifb0 parent 11:0 protocol ip prio 2 u32 match ip protocol 47
> 0xff match u16 0x0800 0xffff at 46
>
> but what do I do with the second half to find the start of the TCP/UDP header?
> Is it still offset at 0 because tc filter somehow knows where the interior IP
> header starts or should it be offset at 48 to account for the GRE + ESP
> headers?
> Or is there a better way to filter ingress traffic on GRE/IPSec tunnels?
> Thanks
> - John

Alas, this is not working.  I set a continue action for the ESP traffic:

tc filter replace dev ifb0 parent 11:0 protocol ip prio 1 u32 match ip protocol
50 0xff action continue

and that seems to be matching:

filter parent 11: protocol ip pref 1 u32 fh 802::800 order 2048 key ht 802 bkt 0
terminal flowid ???  (rule hit 3130003 success 2931853)
  match 00320000/00ff0000 at 8 (success 2931853 ) 
	action order 1: gact action continue
	 random type none pass val 0
	 index 1 ref 1 bind 1 installed 294 sec

And I even reduced the GRE filter to just look for the GRE protocol in the IP
header:

tc filter add dev ifb0 parent 11:0 protocol ip prio 2 u32 match ip protocol 47
0xff link 11: offset at 48 mask 0f00 shift 6 plus 4 eat

but it does not appear to be matching at all:

filter parent 11: protocol ip pref 2 u32 fh 800::800 order 2048 key ht 800 bkt 0
link 11:  (rule hit 3130012 success 0)
  match 002f0000/00ff0000 at 8 (success 0 ) 
    offset 0f00>>6 at 48 plus 4  eat 

Any suggestions about how to traffic shape ingest traffic coming off an ESP
Transport connection? Thanks - John
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists