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 -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
