Re: iptables resources consumed

[Grant Taylor <gtaylor@riverviewtech.net>]

On 7/4/2008 12:22 AM, Elison Niven wrote:
> I'd just like to clarify a few things I should have done before.
> 
> 1) Eth0 and eth2 will always be in different subnets.

Ok.

> 2) All RTP traffic that has to be sent to the DSPs will always arrive 
> to eth0.

Ok.

> Eth2 is an internal IP address. The system is known only by one IP 
> address to the outer world - that of eth0.

*nod*

> Consider an example: My System's IP is eth0 - 192.168.1.50, subnet 
> mask - 255.255.255.0 Eth2 (internal) is 192.168.2.50, The DSPs are 
> 192.168.2.51 to 192.168.2.58, subnet mask - 255.255.255.0 The default 
> gateway of the DSPs is eth2 - 192.168.2.50.

This is simple enough.

> There is a voice call from another device at 192.168.1.100 to 
> 192.168.1.50.
> 
> Outside the system, the following transfers are visible (say in 
> wireshark/ethereal):
> 
> 192.168.1.100 --> Sends RTP:
> src IP = 192.168.1.100
> dest IP = 192.168.1.50
> src port = 8000
> dest port = 10000
> 
> My system 192.168.1.50 --> Sends RTP:
> Src IP = 192.168.1.50
> Dest IP = 192.168.1.100
> Src port = 10000
> Dest port = 8000

Ok.  This is the request and the reply (if you will) as seen when 
sniffing the cable connected to eth0 of your system.

> Inside the system, the RTP is actually generated by the DSPs, say 
> DSP1 here.
> 
> DSP1 --> Sends RTP:
> Src IP = 192.168.1.50 - This is IP spoofing. DSP1's actual IP is 
> 192.168.2.51. This is the IP as seen in the source IP field in the IP 
> header.
> Dest IP = 192.168.1.100
> Src port = 10000
> Dest port = 8000
> 
> This traffic is received on eth2 and must be sent out through eth0. 
> The purpose of faking the IP is not to have to do SNAT on such 
> packets.

You can do the source IP spoofing here, but I would not recommend it for 
multiple reasons.
  - You will have to (re)configure all the DSPs with the IP of eth0 if 
it ever changes.
  - This could conflict with reverse path filtering on your system.
  - IMHO this is bad form.
  - If the DSP wants to communicate with your system it will have to use 
a different source IP, or other trickery will have to be done to allow 
your system to communicate with the DSP.
  - SNATing is not going to be that much of a load.

> The traffic that the other device is sending is received on eth0. 
> Such traffic is forwarded to DSP1.

Ok.

> Each of the DSPs also sends control packets that are always sent as:
> 
> Src IP = DSPs actual IP address = 192.168.2.51 Dest IP = eth2 = 
> 192.168.2.50

Ok.

> Such packets need to be sent to a local process on the CPU.

By standard routing and socket binding this will be inherent.

> So I guess the minimal rules needed will be:
> 
> 1) For packets received on interface eth2
> 
> IF Destination IP != eth2 IP THEN send the packet out from eth0 ELSE 
> send it to the CPU

This is not a rule.  This is standard routing / forwarding.  If a packet 
coming in to an interface has a destination IP belonging to the system, 
it will be processed by the system.  If a packet coming in to an 
interface has a destination that does not belong to the system it will 
be forwarded as long as forwarding is enabled.

> 2) For packets received on interface eth0
> 
> Now the system will be listening for http, telnet and ftp connections 
> on their fixed port numbers. The system will also be listening for 
> SIP connections to a fixed port - say 5060. Such packets obviously 
> need to be sent to the CPU. Does that mean I have to check the 
> destination port number of all the packets received?
> 
> IF Dest port of packet == 80 (http) OR 21(ftp) OR 23(telnet) OR 
> 5060(sip). (Does this becomes a single rule or more than one?) THEN 
> send packet to the CPU ELSE goto below rules

No.  Again, any packets coming in with a destination IP belonging to the 
system will be passed up in to the system for processing.

> For all other packets received, the rule will be (for the example 
> above):
> 
> IF Source IP == 192.168.1.100 and destination port == 10000. Again 
> does this become 2 different rules? If I also check the source port 
> of the packet here, will that add a new rule? THEN send the packet to 
> DSP1. This will require a DNAT I think. ELSE drop the packet.

This is one rule with multiple conditions to it.  If this or other rules 
are not matched, have a final rule or chain default policy to drop the 
packet.

> Now I intend to (horribly) support 256 such calls and I need to 
> figure out the minimal rules that would be required.

Can you provide a list of source / destination IPs and ports or a 
pattern there of?  I'll look at it and see how many rules I think would 
be needed (with and with out the optimizations that I spoke of).

> (Ofcourse, I see above that there would be some (don't know how many) 
> problems when an external device with IP = 192.168.2.51 wants to talk 
> to my system, But we'll get to it later.)

Heh.  This is another reason why I suggest that you not have your 
external IP configured on the DSPs because if you need to change it, you 
will have to change configs on your DSPs too.

Now this brings up a question as to whether this is a config for a 
specific install or if this is to be more dynamic and installed a bunch 
of places.  If it is the former corners can be cut, but if it is the 
later, care should be taken to take these types of things in to account.



Grant. . . .