LARTC - Nov 2006 - Ingress qdisc bypassed on SNAT''ed traffic?

Hello,

I am using the following iptables POSTROUTING rule to NAT some RFC
1918 addresses:

iptables -t nat -A POSTROUTING -s 192.168.19.23 !
192.168.0.0/255.255.0.0 -p tcp --dport 80 -j SNAT --to-source
10.32.4.2

(I am using SNAT instead of MASQUERADE for performance reasons).
I have several addresses on the 192.168.0.0/16 subnet that I am
SNAT''ing similarly.

Problem is, ''tc -s filter show parent ffff: dev bond0'' is
reporting
that the ingress qdisc rule''s for each of these RFC1918 addresses are
being bypassed:

tc qdisc add dev bond0 ingress
tc filter add dev bond0 parent ffff: protocol ip prio 10 u32 match ip
dst 192.168.19.23/32 flowid 1:1 action police rate 100kbps burst 200kb
drop

However, the same lartc ingress filter rules work fine when run on the
NAT gateway address (10.32.4.2).

I suppose this means that the ingress filter is being run too early in
the PREROUTING chain to catch the NAT''ed destination address. Is there
a patch to change this behaviour?

I''ve also tried using connmark to no avail.

I would rather avoid using IMQ since my ingress QOS needs are pretty simple.

Any suggestions?

Thanks!

Eser Chamoglu

EKC wrote:
> Hello,
> However, the same lartc ingress filter rules work fine when run on the
> NAT gateway address (10.32.4.2).
The QoS processing is done just before the device queue for egress or 
immediately after ingress from the device. Thus using the 192.168.x.x 
addresses for tc filters will not work. Using the gateway address works 
as that is the IP on the incoming packet''s
header.
> 
> I suppose this means that the ingress filter is being run too early in
> the PREROUTING chain to catch the NAT''ed destination address. Is
there
> a patch to change this behaviour?
I''ve not seen one.
> 
> I''ve also tried using connmark to no avail.
Ingress QoS works much before packet hits all this
stuff.
> 
> I would rather avoid using IMQ since my ingress QOS needs are pretty 
> simple.
AFAIK, there is no other choice/way here.
> 
> Any suggestions?
One wa of doing this is to use one NAT IP per subnet and shape based on 
that NAT IP for ingress. However, this assumes you have as many 
addresses on the gateway as the subnet. I''m using you do as the
NAT''ted
IP is also a RFC1918 address. That leads to a more basic question - why 
NAT when both are RFC1918 addresses?

Mohan

Unfortunately, that NAT gateway address should have been a routable
address (I''m debugging this in vmware at the moment).

Considering that, it looks like I''m going to have to play around with
IMQ.


On 11/5/06, Mohan Sundaram <mohan.tux@gmail.com>
wrote:
> EKC wrote:
> > Hello,
>
> > However, the same lartc ingress filter rules work fine when run on the
> > NAT gateway address (10.32.4.2).
> The QoS processing is done just before the device queue for egress or
> immediately after ingress from the device. Thus using the 192.168.x.x
> addresses for tc filters will not work. Using the gateway address works
> as that is the IP on the incoming packet''s header.
> >
> > I suppose this means that the ingress filter is being run too early in
> > the PREROUTING chain to catch the NAT''ed destination address.
Is there
> > a patch to change this behaviour?
> I''ve not seen one.
> >
> > I''ve also tried using connmark to no avail.
> Ingress QoS works much before packet hits all this stuff.
> >
> > I would rather avoid using IMQ since my ingress QOS needs are pretty
> > simple.
> AFAIK, there is no other choice/way here.
> >
> > Any suggestions?
> One wa of doing this is to use one NAT IP per subnet and shape based on
> that NAT IP for ingress. However, this assumes you have as many
> addresses on the gateway as the subnet. I''m using you do as the
NAT''ted
> IP is also a RFC1918 address. That leads to a more basic question - why
> NAT when both are RFC1918 addresses?
>
> Mohan
>
>

EKC wrote:
> Unfortunately, that NAT gateway address should have been a routable
> address (I''m debugging this in vmware at the moment).
> 
> Considering that, it looks like I''m going to have to play around
with IMQ.
If you say no to packet action in kernel config then you get to choose 
the old policer - which does hook after deNAT.

Andy.