All of lore.kernel.org
 help / color / mirror / Atom feed
* netfilter + masquerade, mutliple i/fs sharing an IP
@ 2009-09-22 16:23 Alex Bligh
  2009-09-22 22:50 ` Pascal Hambourg
  0 siblings, 1 reply; 3+ messages in thread
From: Alex Bligh @ 2009-09-22 16:23 UTC (permalink / raw)
  To: netfilter; +Cc: Alex Bligh

Hi,

I'm trying to set up masquerading on linux with a somewhat unusual 
requirement.
Essentially, I have multiple p2p interfaces (let's call them tun0 .. tun99),
and want them all to NAPT to eth0's IP address (for outgoing connectivity).
Now, that's nice and easy if tun0 .. tun99 have distinct IP addresses. For
reasons we need	not go into, I want to have them all having the same IP
address, i.e. (for ASCII art fans)

                                          [------------------]
                          192.168.1.0/24  [   NAPT gateway   ]
 [ Host A  192.168.1.2] ------------------[ 192.168.1.1      ]
                                     tun0 [                  ] 1.2.3.0/24
                                          [          1.2.3.4 ]---->
                                          [                  ] eth0
 [ Host B  192.168.1.2] ------------------[ 192.168.1.1      ]
                                     tun1 [                  ]
                                          [------------------]

Now, I appreciate that duplicating IP addresses is not in general
a good idea. However, in theory this could work. The complex
part is that when a packet traverses the NAPT left to right, it
needs to record both the input i/f, together with the source IP	
and port. When the reply is translated back, the packet is
going to be destined for 192.168.1.2, but it must be sent out
the same interface as the NAPT table shows the packet is received on,

Doing this the standard way (i.e.
  iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE	
  iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
  iptables -A FORWARD -i tun1 -o eth0 -j ACCEPT
  )
only appears to work when either tun0 OR tun1 are up (but not both).
I suspect this is because on NAPT traversal of the reply packet,
the kernel looks up a next hop, and uses that next hop to determine
which interface to use (using first subnet match).

Is there any way around this? For instance can I used multiple
NAPT tables, one for each inbound i/f?

-- 
Alex Bligh

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: netfilter + masquerade, mutliple i/fs sharing an IP
  2009-09-22 16:23 netfilter + masquerade, mutliple i/fs sharing an IP Alex Bligh
@ 2009-09-22 22:50 ` Pascal Hambourg
  2009-09-22 22:59   ` Alex Bligh
  0 siblings, 1 reply; 3+ messages in thread
From: Pascal Hambourg @ 2009-09-22 22:50 UTC (permalink / raw)
  To: netfilter

Hello,

Alex Bligh a écrit :
> 
>                                           [------------------]
>                           192.168.1.0/24  [   NAPT gateway   ]
>  [ Host A  192.168.1.2] ------------------[ 192.168.1.1      ]
>                                      tun0 [                  ] 1.2.3.0/24
>                                           [          1.2.3.4 ]---->
>                                           [                  ] eth0
>  [ Host B  192.168.1.2] ------------------[ 192.168.1.1      ]
>                                      tun1 [                  ]
>                                           [------------------]
> 
> Now, I appreciate that duplicating IP addresses is not in general
> a good idea. However, in theory this could work. The complex
> part is that when a packet traverses the NAPT left to right, it
> needs to record both the input i/f, together with the source IP	
> and port. When the reply is translated back, the packet is
> going to be destined for 192.168.1.2, but it must be sent out
> the same interface as the NAPT table shows the packet is received on,
> 
> Doing this the standard way (i.e.
>   iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE	
>   )
> only appears to work when either tun0 OR tun1 are up (but not both).
> I suspect this is because on NAPT traversal of the reply packet,

No, this has nothing to do with NAT but with routing.

> the kernel looks up a next hop, and uses that next hop to determine
> which interface to use (using first subnet match).

Correct. Just plain routing. No NAT involved here.

> Is there any way around this? For instance can I used multiple
> NAPT tables, one for each inbound i/f?

I repeat : this has nothing to do with NAT.
You might be interested in the CONNMARK target and the connmark match.

1) Mark packets received on each tunX interface with MARK.
2) Copy the packet mark into the connection mark with CONNMARK.
3) Copy the connection mark of packets received on eth0 into the packet
mark with CONNMARK.
4) Route the packets according to their mark with ip rule & ip route.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: netfilter + masquerade, mutliple i/fs sharing an IP
  2009-09-22 22:50 ` Pascal Hambourg
@ 2009-09-22 22:59   ` Alex Bligh
  0 siblings, 0 replies; 3+ messages in thread
From: Alex Bligh @ 2009-09-22 22:59 UTC (permalink / raw)
  To: Pascal Hambourg, netfilter; +Cc: Alex Bligh



--On 23 September 2009 00:50:04 +0200 Pascal Hambourg 
<pascal.mail@plouf.fr.eu.org> wrote:

> You might be interested in the CONNMARK target and the connmark match.
>
> 1) Mark packets received on each tunX interface with MARK.
> 2) Copy the packet mark into the connection mark with CONNMARK.
> 3) Copy the connection mark of packets received on eth0 into the packet
> mark with CONNMARK.
> 4) Route the packets according to their mark with ip rule & ip route.

Thanks - just what I was looking for.

-- 
Alex Bligh

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2009-09-22 22:59 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-09-22 16:23 netfilter + masquerade, mutliple i/fs sharing an IP Alex Bligh
2009-09-22 22:50 ` Pascal Hambourg
2009-09-22 22:59   ` Alex Bligh

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.