Muggeridge, Matt wrote: > Darren, > ... > The documentation for rewrite has me a little confused. Specifically, > >> If one of these happens to be a static then it will be skipped and the >> next one incremented. As an example: >> >> rewrite out on le0 proto tcp from any to any port = 80 -> >> src 1.0.0.0/8,5000-5999 dst 2.0.0.0/24,6000-6999; >> >> The translated packets would be: >> 1st src=1.0.0.1,5000 dst=2.0.0.1,6000 >> >> 2nd src=1.0.0.2,5000 dst=2.0.0.1,6000 >> >> 3rd src=1.0.0.2,5001 dst=2.0.0.1,6000 >> >> 4th src=1.0.0.2,5001 dst=2.0.0.2,6000 >> >> 5th src=1.0.0.2,5001 dst=2.0.0.2,6001 >> >> 6th src=1.0.0.3,5001 dst=2.0.0.2,6001 >> >> and so on. >> > > In the packet sequence, what is causing the address to increment > sometimes and not at other times? Same question for the ports. The > 'and so on' comment suggests I should see a pattern here, but it eludes > me. >
what is happening here is that there are four fields to work through changes with in the new address part of the rule: source address 1.0.0.0/8 source port 5000-5999 destination address 2.0.0.0/24 destination port 6000-6999 The normal algorithm used to select the 'next' one is just to increment the field. The order in which the fields are iterated through is as listed about. The idea here is to make it more likely that the complete address space gets used. >> encap - encapsulated the packet in a new IP header (this will be >> compatible, I hope, with IPENCAP tunnels elsewhere0 >> divert - encapsulate the packet into an IP+UDP packet >> > > Are you suggesting that 'divert' will only support IP+UDP, or will it > also support IP+TCP? Just to be sure I understand what 'divert' wants > to achieve, can you give an example where the 'divert' rule would be > used? > If I were to do IP+TCP, it would require IPFilter creating its own TCP socket. That's just way too complicated. The idea is that you can use a "divert" rule to do your own NAT'ing of packets but in user space (behind the other end of a UDP socket.) If you divert'd all TCP packets to/from port 21 to a UDP socket, you should be able to implement an FTP proxy that works on packets but is in user space. The data that is received by the program that has the UDP socket open is the IP packet that was received from the wire. What gets sent back will be the IP packet that resumes processing through IPFilter. This is a different take on the divert capability in FreeBSD/Linux today which requires special sockets. Hope this helps. Darren
