A more correct approach would be to have recvmsg() attach the
original addresses to the UDP message if requested by the
application, but I am not entirely sure on how to design this proper
(ipv4 needs to call into conntrack to find the original addresses of
the skb). I strongly suspect an additional ip->netfilter hook is
required... In recvmsg principle this should be similar to how the
IP_PKTINFO message (see IP(7)) works for non-NAT:ed traffic.
Suggestion on how one could implement an IP_ORIGADDRS control message
1. Extend the af_inet.cmsg_flags with an additional bit for
IP_ORIGADDRS. (the IP_CMSG_ bits are defined at the top of
ip_sockglue.c)
2. Extend ip_setsockopt to accept IP_ORIGADDRS and set the
corresponding bit in af_inet.cmsg_flags. Similar for ip_getsockopt
for reading the current option status.
3. Create an in_origaddrs structure containing
struct in_origaddrs {
struct in_addr ioa_srcaddr;
struct in_addr ioa_dstaddr;
unsigned short int ioa_srcport;
unsigned short int ioa_dstport;
};
4. Create a hook in ip_sockglue.c where conntrack can install the
routine for getting the original skb addresses. Have conntract copy
the addresses into the above structure for simplicity. The NAT:ed skb
has an conntrack entry attached so conntrack can easily find the
original addressing information given the skb.
5. Create the routine for generating the new control message in
ip_sockglue.c, using the above hook to get the addressing information
from conntrack. See the other control message routines for a
template..
Note: If the conntrack address lookup hook isn't installed or if
conntrack doesn't find a corresponding conntrack entry for the skb
then don't return a IP_ORIGADDRS control message.
Regards
Henrik Nordström
MARA Systems AB
On Friday 08 March 2002 17:25, Igor Vrdoljak wrote:
> First, thanks for your swift response.
>
> The thing is that I am trying to redirect UDP traffic :-)
>
> Now, I've written code for parsing ip_conntrack file, so, if you
> could tell me what are those issues I would be grateful (I must
> decide what method to use).
>
> Thanks in advance
>
> Igor
>
> ----- Original Message -----
> From: "Henrik Nordstrom" <[EMAIL PROTECTED]>
> To: "Igor Vrdoljak" <[EMAIL PROTECTED]>;
> <[EMAIL PROTECTED]>
> Sent: Friday, March 08, 2002 3:27 PM
> Subject: Re: getting original destination address after DNAT
>
> > This data is accessible using a getsockopt() call, and works
> > perfect for TCP traffic (for UDP traffic there is some minor
> > issues..)
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> > The following fragment should give you the correct destination
> > address both for DNAT/REDIRECT:ed connections and connections
> > made directly to the server.
> >
> > sockaddr_in dst_addr;
> > socklen_t slen = sizeof(dst_addr);
> >
> > getsockname(fd, (struct sockaddr *)&dst_addr, &slen);
> > getsockopt(fd, SOL_IP, SO_ORIGINAL_DST, &dst_addr, &slen)
> >
> > Regards
> > Henrik Nordström
> > MARA Systems AB, Sweden
> >
> > On Wednesday 06 March 2002 16:08, Igor Vrdoljak wrote:
> > > I'm using netfilter (PREROUTING chain) on my router for
> > > redirecting all the trafic passing through designated to
> > > certain port to a local port on my router.
> > >
> > > I'm interested in getting the original dest. address (adress
> > > before DNAT) from my server (which listens on local port on the
> > > router).
> > >
> > > I see there is a /proc/net/ip_conntrack file which shows
> > > connections active on the machine, but I wonder is there easier
> > > way of getting that information other than parsing that file?
> > >
> > > Which would be the easyest way to do this?
