Homepage di Giacomo.

getsockopt() interface

IPFIRE has been prepared to allow transparent proxying via getsockopt() interface. In this way, a program can obtain the original destination address of a connection being redirected to it. In the following picture, a screenshot has been taken from transparent proxy p3scan, which connects to pop3 server acting as the real mail user agent. As you can see in the second figure, IPFIRE redirects mail agent destination port (110) to port 8110, where p3scan waits for connections. Then proxy retrieves original destination address of popmail server, and connects to it. It receives mail, filters it and sends cleaned messages to mail user agent residing on another machine.

P3Scan screenshot

As you can see above, real server address retrieved from kernel tables is, mail user agent is at Then communication from proxy to pop3 server starts. IPFIRE registers its getsockopt() function into kernel and, when such function is invoked, looks up in destination nat tables to retrieve original destination address of connection. By means of the call to copy_to_user(), old destination address comes to application, who invoked getsockopt specifying as optname integer 200. P3scan sources have been modified to set optname to 200. See man getsockopt to learn more about its usage.
Remember anyway that in ipfi_translation.c kernel module source file optname has been defined:
To use getsockopt() system call, thou can define this constant as above.

IPFIRE transparent proxying

Having a look to the picture above, in the fifth line one can see that host starts a connection to popmail server [PRE]. On node, where p3scan listens, connection gets redirected from remote pop3 server to local proxy, waiting on port 8110 [IN]. Connection is setup between the host where the email client wants to retrieve new messages and proxy. The proxy establishes then a connection to server sending data through device ppp0 [OUT]. A couple of packets are exchanged until proxy sends a packet back to [OUT, line 15]. Things are not already ok at that time because user agent on expects a packet from port 110 not 8110, and from address, not! So, in post routing hook, source port translation has to take place [POST]. The example above illustrates not only transparent proxying capabilities of IPFIRE, but also a case of destination address translation.
To learn more about transparent proxying in IPFIRE, see the related scenario.
As an example, below is reproduced the rule concerned with the example just described, as it appears in IPFIRE configuration file called "translation".


Valid XHTML 1.0!

Top of page
Back to index
Next page (kernel dynamic tables: managing timers and number of entries)
Previous page (Logging levels and implications)