Disabling conntrack for local net

Disabling conntrack for local net

[Gary Smith]

We have several IP's NAT'd in from public interface.  Even with that we noticed that 80% or so of the connection entries appear to be local to local traffic.

We have the following subnets

10.40.16.0/24 (NAT'd public)
10.40.17.0/24 (internal data)
10.40.18.0/24 (internal data)
10.40.19.0/24 (internal data)
10.40.20.0/24 (NAT'd public)

Public internface NAT's mostly to 10.40.16.0/24 IP's, and a couple on the 10.40.20.0/24 IP's.  We have data/internal services on the 10.40.17.0/24 and 10.40.18.0/24.  We see lots of connections from the 10.40.16.0/24 to the data/internal getting entered into the conntrack (as you would normally expect).  

So, is there any benefit of not conntracking these?  Is so, how do I do that without breaking the NAT.

I know I did this years ago, I just can't remember how.

Re: Disabling conntrack for local net

[Mart Frauenlob]

Gary Smith wrote:
> We have several IP's NAT'd in from public interface.  Even with that we noticed that 80% or so of the connection entries appear to be local to local traffic.
>
> We have the following subnets
>
> 10.40.16.0/24 (NAT'd public)
> 10.40.17.0/24 (internal data)
> 10.40.18.0/24 (internal data)
> 10.40.19.0/24 (internal data)
> 10.40.20.0/24 (NAT'd public)
>
> Public internface NAT's mostly to 10.40.16.0/24 IP's, and a couple on the 10.40.20.0/24 IP's.  We have data/internal services on the 10.40.17.0/24 and 10.40.18.0/24.  We see lots of connections from the 10.40.16.0/24 to the data/internal getting entered into the conntrack (as you would normally expect).  
>
> So, is there any benefit of not conntracking these?  Is so, how do I do that without breaking the NAT.
>
> I know I did this years ago, I just can't remember how.
>   

Benefit = No resources used on connection tracking

-t raw -m -s x.x.x.x/zz -d y.y.y.y/zz -j NOTRACK

Regards

Mart

Re: Disabling conntrack for local net

[Mart Frauenlob]

Mart Frauenlob wrote:
> Gary Smith wrote:
>> We have several IP's NAT'd in from public interface.  Even with that 
>> we noticed that 80% or so of the connection entries appear to be 
>> local to local traffic.
>>
>> We have the following subnets
>>
>> 10.40.16.0/24 (NAT'd public)
>> 10.40.17.0/24 (internal data)
>> 10.40.18.0/24 (internal data)
>> 10.40.19.0/24 (internal data)
>> 10.40.20.0/24 (NAT'd public)
>>
>> Public internface NAT's mostly to 10.40.16.0/24 IP's, and a couple on 
>> the 10.40.20.0/24 IP's.  We have data/internal services on the 
>> 10.40.17.0/24 and 10.40.18.0/24.  We see lots of connections from the 
>> 10.40.16.0/24 to the data/internal getting entered into the conntrack 
>> (as you would normally expect). 
>> So, is there any benefit of not conntracking these?  Is so, how do I 
>> do that without breaking the NAT.
>>
>> I know I did this years ago, I just can't remember how.
>>   
>
> Benefit = No resources used on connection tracking
>
> -t raw -m -s x.x.x.x/zz -d y.y.y.y/zz -j NOTRACK
>
sorry, missed that:
or the RAWNAT target from the xtables addon if you used NAT.

RE: Disabling conntrack for local net

[Gary Smith]

> > Benefit = No resources used on connection tracking
> >
> > -t raw -m -s x.x.x.x/zz -d y.y.y.y/zz -j NOTRACK
> >
> sorry, missed that:
> or the RAWNAT target from the xtables addon if you used NAT.

RAWNAT?  Never seen that before.

Looking up the xtables implementation it looks like I can do the RAWNAT in raw/rawpost for routing stead of PRE/POSTROUTING in nat.  Is there a recommendation of doing this over PRE/POSTROUTING rules?

Playing with it last night (based upon your answer and looking up some of my old posts from years ago) I added the rule to NOTRACK local but I ran into a problem with making connections to external IP's routing back inside.  For my own stuff, I run split DNS, but the problem is all of the client hosted stuff is blocked and split DNS isn't an option for their domains since we don't control them.  Since we have a limited number of public IP's now we are really dependent on NAT'ing to multiple different servers internally.

With that said, can someone assist me with writing a good NOTRACK rule that will still allow me to access my public IP's from internally, and be able to cross subnets, in the best possible manner.  We are running CentOS 5.3 if that make any this point in the game.

Here is an example of the rules we are running right now:

_A PREROUTING -d 208.35.34.20 -p tcp -m tcp --dport 53 -j DNAT --to-destination 10.40.16.21
-A PREROUTING -d 208.35.34.20 -p udp -m udp --dport 53 -j DNAT --to-destination 10.40.16.21
-A PREROUTING -d 208.35.34.20 -j DNAT --to-destination 10.40.16.29
...
-A POSTROUTING -s 10.40.16.21 -o eth1 -p tcp -m tcp --sport 53 -j SNAT --to-source 208.35.34.20
-A POSTROUTING -s 10.40.16.21 -o eth1 -p udp -m udp --sport 53 -j SNAT --to-source 208.35.34.20
-A POSTROUTING -s 10.40.16.29 -o eth1 -j SNAT --to-source 208.35.34.20
...
-A POSTROUTING -s 10.0.0.0/255.0.0.0 -o eth1 -j SNAT --to-source 208.35.34.2


Given this, can someone whip up the proper raw/nat/filter on how to make this NOTRACK and be able to route back inside?  

RE: Disabling conntrack for local net

[Gary Smith]

Can anyone tackle the problem below?  I need to NAT an external IP/Port internally (actually multiple, but one sample will do).  I also need to access these from internally as well through the NAT'ing (because we don't control DNS).  The final caveat is that we would like to skip conntrack for everything else (like MySql connections originating from one of the NAT'd boxes going to a non-NAT'd box internal, etc).

> Here is an example of the rules we are running right now:
> 
> _A PREROUTING -d 208.35.34.20 -p tcp -m tcp --dport 53 -j DNAT --to-
> destination 10.40.16.21
> -A PREROUTING -d 208.35.34.20 -p udp -m udp --dport 53 -j DNAT --to-
> destination 10.40.16.21
> -A PREROUTING -d 208.35.34.20 -j DNAT --to-destination 10.40.16.29
> ...
> -A POSTROUTING -s 10.40.16.21 -o eth1 -p tcp -m tcp --sport 53 -j SNAT --to-
> source 208.35.34.20
> -A POSTROUTING -s 10.40.16.21 -o eth1 -p udp -m udp --sport 53 -j SNAT --to-
> source 208.35.34.20
> -A POSTROUTING -s 10.40.16.29 -o eth1 -j SNAT --to-source 208.35.34.20
> ...
> -A POSTROUTING -s 10.0.0.0/255.0.0.0 -o eth1 -j SNAT --to-source 208.35.34.2
> 
> 
> Given this, can someone whip up the proper raw/nat/filter on how to make this
> NOTRACK and be able to route back inside?
>

Re: Disabling conntrack for local net

[Mart Frauenlob]

Gary Smith wrote:
> Can anyone tackle the problem below?  I need to NAT an external IP/Port internally (actually multiple, but one sample will do).  I also need to access these from internally as well through the NAT'ing (because we don't control DNS).  The final caveat is that we would like to skip conntrack for everything else (like MySql connections originating from one of the NAT'd boxes going to a non-NAT'd box internal, etc).
>
>   
>> Here is an example of the rules we are running right now:
>>
>> _A PREROUTING -d 208.35.34.20 -p tcp -m tcp --dport 53 -j DNAT --to-
>> destination 10.40.16.21
>> -A PREROUTING -d 208.35.34.20 -p udp -m udp --dport 53 -j DNAT --to-
>> destination 10.40.16.21
>> -A PREROUTING -d 208.35.34.20 -j DNAT --to-destination 10.40.16.29
>> ...
>> -A POSTROUTING -s 10.40.16.21 -o eth1 -p tcp -m tcp --sport 53 -j SNAT --to-
>> source 208.35.34.20
>> -A POSTROUTING -s 10.40.16.21 -o eth1 -p udp -m udp --sport 53 -j SNAT --to-
>> source 208.35.34.20
>> -A POSTROUTING -s 10.40.16.29 -o eth1 -j SNAT --to-source 208.35.34.20
>> ...
>> -A POSTROUTING -s 10.0.0.0/255.0.0.0 -o eth1 -j SNAT --to-source 208.35.34.2
>>
>>
>> Given this, can someone whip up the proper raw/nat/filter on how to make this
>> NOTRACK and be able to route back inside?
>>
>>     

Well, the RAWNAT target didn't seem to fit you?

You could always use iproute2 to do static nat.

OR - get routable IP addresses...


Regards

Mart

RE: Disabling conntrack for local net

[Gary Smith]

> Well, the RAWNAT target didn't seem to fit you?
> 
> You could always use iproute2 to do static nat.
> 
> OR - get routable IP addresses...
> 

Normally I would use routable IP's but in this case we have just a handful of them and each IP it's being mapped to multiple real servers on different ports (for many different services).

The firewall can handle the connections (as we tweaked max connections months ago).  I just wanted to find a better way to not have to have the firewall handle connections that originate internally.  I have several subnets internally and  I have them set to NOTRACK as they can use direct routing, it's just the external facing servers we have a problem with.

Anyway, thanks for the follow up.