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.

As you can see above, real server address retrieved from kernel tables is 193.70.192.70, mail user agent is at 192.168.0.3. 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:
#define SO_IPFI_GETORIG_DST 200
To use getsockopt() system call, thou can define this constant as above.

Having a look to the picture above, in the fifth line one can see that host 192.168.0.2 starts a connection to popmail server 193.170.192.170 [PRE]. On node 192.168.0.2, 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 193.70.192.70 sending data through device ppp0 [OUT]. A couple of packets are exchanged until proxy sends a packet back to 192.168.0.3 [OUT, line 15]. Things are not already ok at that time because user agent on 192.168.0.2 expects a packet from port 110 not 8110, and from address 193.70.192.70, not 192.168.0.1! 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".