On Wed, Mar 27, 2002 at 02:56:56PM +0100, Henrik Nordstrom wrote: > Please don't forget UDP.
I won't. I definitely want UDP as well. > > For UDP you need to save the original destination, and then implement a > control message extension for sending this to userspace together with the > packet in response to a recvmsg() call, or hack the kernel to return the > original destination in IP_PKTINFO (would be the most natural I think). > > See earlier post from me for a lengthy discussion on how one can do this in > the current NAT scheme. If you same the address in the actual skb then this > becomes even easier. In case of IP_PKTINFO only only two lines.. > > Reviewing the existing sockopt options the following seems like the correct > calls: > > * For TCP, return the original destination in getsockopt(SOL_IP, > IP_PKTOPTIONS...) > > * For UCP, return the original destination in the IP_PKTINFO recvmsg control > message, and if possible, use the same to allow the application to control > the source address when sending packets using sendmsg(). ok. I originally wanted to have separate getsockopt calls, but it's better to use already established ones. The only possible problem that I need to tocuh the networking core which I want to avoid touching. > What I do not quite get is how TPROXY is supposed to handle return traffic, > fragmented packets or ICMP, if you are doing stateless NAT. It doesn't handle currently any of them. Fragmentation can be solved by defragmenting incoming packets. (they are destined to the local ip stack anyway) ICMP can be handled in the prerouting hook looking up possible transparent proxy entries. > Also, who is responsible for making sure the application protocol is NAT:ed > properly in TPROXY. For example FTP PASV. Is it the kernel, or is it the > userspace proxy responsibility to get the correct (foreign) IP address in > such case? And what about "related" connections such as an FTP data channel? Of course the proxy itself. How it currently works in Zorp (with kernel 2.2): * the FTP command channel is redirected to the proxy * when a PASV command is sent, a non-local bind is performed to bind to the server's IP & random port * the PASV reply is rewritten to contain information about the allocated port * the data channel is established when the client connects to the socket the firewall allocated * the connection to the server is then established by the proxy > > Sorry if I am making things overly complex here.. > > In my view (as an application developer, not netfilter hacker) the problems > with the standard netfilter approach are: > > 1. Cannot easily support non-local bind, to allow the userspace proxy > application to masquerade as the client > > 2. Cannot get the original destination of a redirected UDP packet in an easy > manner (might be possible by parsing /proc/net/ip_conntrack and quess which > is the correct "connection"...) > > 3. conntrack adds yet another state table, with a bunch of new DOS > conditions one must worry about.. conntrack will not be involved in TPROXY, though I want them to interoperate. -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
