> On May 30, 2015 at 2:24 AM "John A. Sullivan III" > <jsulli...@opensourcedevel.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 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
