[RFC] unidirectional NAT
Hi, First of all, thanks for the feedback on my tproxy patches. It generally works well for TCP based connections, what I'm up to now is proper support for UDP. The problem with datagram based protocols is that connection tracking (at least in my case involving Zorp) and address translation is done by the userspace proxy. The only features for an UDP proxy is the following: * being able to receive frames originally destined elsewhere (the REDIRECT case) * being able to receive frames from an arbitrary host, originally destined to another arbitrary host (the foreign address listen case) * being able to send frames using an arbitrary source IP/address, to an arbitrary host (the foreign connect case) I use the NAT framework to redirect packets to the local stack, but as a sideeffect NAT translates replies as well. Now I don't want reply translation :), that's why the subject unidirectional NAT, which would mean to translate packets in only one direction. (to be honest the best would be to translate a single packet only) I'm thinking about two possibilities: * yet another flag to ip_nat_setup_info() to set up a single manip only. * free the state associated to UDP packets after the translation was applied. * instead of setting up a NAT translation, call manip_pkt() directly somehow Ideas? -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
Re: [RFC] unidirectional NAT
On Wed, 5 Jun 2002, Balazs Scheidler wrote: The only features for an UDP proxy is the following: * being able to receive frames originally destined elsewhere (the REDIRECT case) * being able to receive frames from an arbitrary host, originally destined to another arbitrary host (the foreign address listen case) * being able to send frames using an arbitrary source IP/address, to an arbitrary host (the foreign connect case) I use the NAT framework to redirect packets to the local stack, but as a sideeffect NAT translates replies as well. Now I don't want reply translation :), that's why the subject unidirectional NAT, which would mean to translate packets in only one direction. (to be honest the best would be to translate a single packet only) I'm thinking about two possibilities: * yet another flag to ip_nat_setup_info() to set up a single manip only. * free the state associated to UDP packets after the translation was applied. * instead of setting up a NAT translation, call manip_pkt() directly somehow I'd combine the third with the new table I wrote about some months ago (working name for the table is 'raw' instead of 'notrack' or 'select'). The proposed new target for the table is 'NOTRACK' so that the selected packet would be skipped by conntrack and NAT as well. If I understand your problem correctly, a target 'NONAT' could then be easily added and you could call manip_pkt as you wish. Regards, Jozsef - E-mail : [EMAIL PROTECTED], [EMAIL PROTECTED] WWW-Home: http://www.kfki.hu/~kadlec Address : KFKI Research Institute for Particle and Nuclear Physics H-1525 Budapest 114, POB. 49, Hungary
Re: [RFC] unidirectional NAT
On Wed, Jun 05, 2002 at 11:48:49AM +0200, Jozsef Kadlecsik wrote: On Wed, 5 Jun 2002, Balazs Scheidler wrote: * yet another flag to ip_nat_setup_info() to set up a single manip only. * free the state associated to UDP packets after the translation was applied. * instead of setting up a NAT translation, call manip_pkt() directly somehow I'd combine the third with the new table I wrote about some months ago (working name for the table is 'raw' instead of 'notrack' or 'select'). The proposed new target for the table is 'NOTRACK' so that the selected packet would be skipped by conntrack and NAT as well. If I understand your problem correctly, a target 'NONAT' could then be easily added and you could call manip_pkt as you wish. Let me think a bit about it. For UDP packets I don't really need conntracking sessions, I only need to translate single packets, but I'd like to avoid messing with IP and UDP header translation myself. So NOTRACK is good for me, I don't need NONAT since I don't need conntrack either. The question is how you mark an skb to avoid tracking? (an idea was to use a flag in nfct, is it still true?) Is you patch available somewhere? -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
Re: [RFC] unidirectional NAT
On Wed, 5 Jun 2002, Balazs Scheidler wrote: Let me think a bit about it. For UDP packets I don't really need conntracking sessions, I only need to translate single packets, but I'd like to avoid messing with IP and UDP header translation myself. So NOTRACK is good for me, I don't need NONAT since I don't need conntrack either. The question is how you mark an skb to avoid tracking? (an idea was to use a flag in nfct, is it still true?) No, I'll go with Rusty's solution: a dummy conntrack entry is used. Is you patch available somewhere? Not yet, but real soon I'll post it :-). Regards, Jozsef - E-mail : [EMAIL PROTECTED], [EMAIL PROTECTED] WWW-Home: http://www.kfki.hu/~kadlec Address : KFKI Research Institute for Particle and Nuclear Physics H-1525 Budapest 114, POB. 49, Hungary
