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,

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