Re : iptables resources consumed

Re : iptables resources consumed

[Elison Niven]

Hi,

Comments inline.

> Ok... Now it is starting to sound like you want any and all traffic to 
> / from the DSPs to go through the bridge (eth0 & eth2) like normal 
> *except* for traffic to / from the control port.  Now you are wanting to 
>  send the control port traffic somewhere other than though eth0.  Do I 
> have this correct?

I just want to send the control port traffic to a local process on the CPU.

> At first glance this would seem nice.  However I've dealt with software 
> that believes that any traffic coming in on a port is from a specific 
> source and as such there has to be multiple different ports to identify 
> multiple different sources.  Just make sure that you are not dealing 
> with any thing like there here.

Yes, I will surely check this.

> I don't see how the DSP would even know what IP it would need to fake 
> as, much less believe that it would do it. 

This is actually quite simple. The DSP has the ability to fake its source IP
address. The DSP can be configured to output packets with a different source
IP.

> Besides, if it did, it would tend to break the IP routing / NATing that is
being done (same > > subnet on multiple interfaces).

I didn't actually get this. Can you possibly throw some light on this?

I take it that both eth0 and eth2 will be in different subnets. The DSPs
will have their IP addresses in the same subnet as that of eth2.

If the DSP sends packets with a fake source IP - that of eth0, how would it
break the IP routing / NATing being done? The default gateway of the DSPs is
eth2. Because the DSPs send packets to the *outer world addresses*, the
packets reach eth2. The rule on eth2 is to send them as it is out from eth0.

Regarding the DSP control packets: Such packets will be directed to IP =
eth2. All other packets (that are routed out through eth0) will have a
different destination IP. So that should make the rule simpler on eth2.

Best Regards,
Elison

Re: Re : iptables resources consumed

[Grant Taylor]

On 7/3/2008 8:40 AM, Elison Niven wrote:
> I just want to send the control port traffic to a local process on 
> the CPU.

Ok, that's a simple "REDIRECT" target.  Redirect effectively takes any 
traffic coming in (through) and interface and changes the destination IP 
to be that of the interface that the packet came in on.

> Yes, I will surely check this.

*nod*

> This is actually quite simple. The DSP has the ability to fake its 
> source IP address. The DSP can be configured to output packets with a 
> different source IP.

Ok...  Is this spoofing for all traffic or just for specific traffic?  I 
can see how this could severally effect things.

> I didn't actually get this. Can you possibly throw some light on 
> this?

If you have a router connected to two different networks with the same 
subnet (i.e. 192.168.1.0/24) on both interfaces and IPs assigned to them 
the kernel will get confused because it can not differentiate which 
interface it is suppose to use when it is told to connect (or send 
traffic to) a given address.  In short, you are left with a question of 
"which interface is suppose to be used".

So, if the DSP spoofs the the IP on eth0, then things are no longer 
standard routing and you have to allow for it.  I *strongly* recommend 
that you not have the same subnet on multiple different (not connected) 
interfaces unless you are bridging.  It /can/ be done, but it makes 
things much more complicated.

> I take it that both eth0 and eth2 will be in different subnets. The 
> DSPs will have their IP addresses in the same subnet as that of eth2.

This is what I expected.

> If the DSP sends packets with a fake source IP - that of eth0, how 
> would it break the IP routing / NATing being done? The default 
> gateway of the DSPs is eth2. Because the DSPs send packets to the 
> *outer world addresses*, the packets reach eth2. The rule on eth2 is 
> to send them as it is out from eth0.

I'm concerned about traffic coming in eth0 going to the DSP connected to 
eth2.  What IP do you send it to, the one being spoofed or the internal 
one?  When the client send this traffic, will the reply come from the 
same IP or will it be a different IP?  I see too much that could go 
wrong in this that should not happen in normal traffic.

*OR* is the IP spoofing not for the source IP of the packets leaving the 
DSP but rather for an IP that is included as a value with in the payload 
in the packet from the DSP, much like FTP packets include the port 
number that they want to use or how you sometimes have to specify an 
external IP for SIP VoIP devices behind a NAT.

> Regarding the DSP control packets: Such packets will be directed to 
> IP = eth2. All other packets (that are routed out through eth0) will 
> have a different destination IP. So that should make the rule simpler 
> on eth2.

Ok, what is the difference in the "control packet(s)" and "all other 
packets that do not match the rules" (from my question last time that 
you just answered)?



Grant. . . .

Re: iptables resources consumed

[Elison Niven]

Hi,

I'd just like to clarify a few things I should have done before.

1) Eth0 and eth2 will always be in different subnets.
2) All RTP traffic that has to be sent to the DSPs will always arrive to
eth0.

> I'm concerned about traffic coming in eth0 going to the DSP connected to 
> eth2.  What IP do you send it to, the one being spoofed or the internal 
> one?  When the client send this traffic, will the reply come from the 
> same IP or will it be a different IP?  I see too much that could go 
> wrong in this that should not happen in normal traffic.

> *OR* is the IP spoofing not for the source IP of the packets leaving the 
> DSP but rather for an IP that is included as a value with in the payload 
> in the packet from the DSP, much like FTP packets include the port 
> number that they want to use or how you sometimes have to specify an 
> external IP for SIP VoIP devices behind a NAT.

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

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.

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

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.

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

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

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

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

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

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.

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

(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.)

Best Regards,
Elison

Re: iptables resources consumed

[Grant Taylor]

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. . . .

re : iptables resources consumed

[Elison Niven]

Hi,

Comments inline.

> 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.

Well, this is not a problem at all. The source IP that the DSP puts in the
*RTP packets* it generates can be changed dynamically at runtime. And it can
be different for different RTP sessions as well, not that I would need to do
it. That apart, this is allowed only for *RTP packets* (this traffic has to
forwarded out from eth0). All other packets (the only ones that remain are
the DSP control packets directed towards my system) use the source IP as the
actual DSP IP address.

> 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.

Ok, but all the packets that I need to send to the DSPs will reach my system
and will have destination IP belonging to my system. They are not needed to
be processed by my system but are to be sent to the DSPs. How do I do that?

> 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).

Well, actually this list is dynamic and can change at runtime. The actual
port numbers and IP addresses depend on the SIP/SDP negotiation.

Thanks a lot for helping me out.

Best regards,
Elison

Re: re : iptables resources consumed

[Grant Taylor]

On 7/4/2008 4:12 AM, Elison Niven wrote:
> Well, this is not a problem at all. The source IP that the DSP puts 
> in the *RTP packets* it generates can be changed dynamically at 
> runtime. And it can be different for different RTP sessions as well, 
> not that I would need to do it. That apart, this is allowed only for 
> *RTP packets* (this traffic has to forwarded out from eth0). All 
> other packets (the only ones that remain are the DSP control packets 
> directed towards my system) use the source IP as the actual DSP IP 
> address.

Ok.  The, I suppose you can spoof the source IP if you want to.

> Ok, but all the packets that I need to send to the DSPs will reach my 
> system and will have destination IP belonging to my system. They are 
> not needed to be processed by my system but are to be sent to the 
> DSPs. How do I do that?

Right, this is why you DNAT them to the DSPs inside.

> Well, actually this list is dynamic and can change at runtime. The 
> actual port numbers and IP addresses depend on the SIP/SDP 
> negotiation.

Uh, this could make for a bit of fun.  It is trivial to write an 
IPTables rule to match based on static source / destination IP and / or 
source / destination port or any combination there of.  However to match 
the dynamic ports, you will need may need a helper to find what is 
negotiated.

Question:  Is filtering out packets from the DSPs other than what you 
have mentioned a must or is it ok if packets leak out.  In other words, 
do they have to be filtered (prevent them from going) out as long as the 
RTP packets go where they are suppose to go?

> Thanks a lot for helping me out.

*nod*  You are welcome.



Grant. . . .