[prev in list] [next in list] [prev in thread] [next in thread] 

List:       netfilter
Subject:    Re: Can netfilter do this?
From:       Daniel Stone <daniel () sfarc ! net>
Date:       2001-06-23 0:56:32
[Download RAW message or body]

On Fri, Jun 22, 2001 at 11:58:44AM +0100, Russell King wrote:
> I'm quickly coming to the conclusion that netfilter isn't able to forfill
> my nat requirements, since I can't find a set of rules that actually work.
> 
> I have the following interfaces on my firewall:
> 
> 	eth0	(internal network)
> 	eth1	(public internet)
> 	cipcb0	(tunnel)
> 
> I want to be able to do the following:
> 
> 1. Outgoing connections from the internal network:
>    a) ftp, ssh, web, (basically random collection of port numbers that
>       I specify) to any public internet address I want to be routed out
>       via eth1 using eth1's IP address using masquerade.
>    b) everything else I want to be SNAT'd via cipcb0 using cipcb0's IP
>       address.

Yeeesss ... um ... you'll need to use this in combination with rule-based
routing AFAICS. Something like:
mangle table - PREROUTING -
	if it's a) - set a MARK
	if it's b) - set another MARK
routing code runs and decides where to go based on the MARK
nat table - POSTROUTING -
	matches on the MARK and decides where to go from there
 
> 2. Outgoing connections from firewall machine:
>    Same as (1) above, but different selection of port numbers

Output NAT is broken bad evil shocking die die die not currently functional.
 
> 3. Incoming connections via cipcb0:
>    a) DNAT'd to relevant internal IP address
>    b) Locally addressed (cipcb0 interface address) delivered locally.

WRT a), if you're talking about the connections that have been set up,  then
SNAT already does that, otherwise both are trivial.

> 4. Incoming connections via eth1:
>    a) a selection of destination port numbers to be DNAT'd to an internal
>       machine.  Reply packets for this connection to be sent via eth1
>       with eth1's IP address.

Yep, DNAT automatically sets up a return rule.

>    b) everything else delivered locally.

Yes.

> 5. eth0 - standard routing rules apply (locally addressed packets delivered
>    locally, otherwise forwarded).

Yes.

> No matter what I do, I seem to end up with connections that use cipcb0 for
> incoming and eth1 with cipcb0's IP address for outgoing or connections that
> use eth1 for incoming and cipcb0 for outgoing with eth1's IP address.
> 
> Obviously re-writing the source address on output depending on the interface
> is going to break everything, so is not an option. ;(

I think you just need to look into -j MARK and policy routing.

:) d

-- 
Daniel Stone						     <daniel@sfarc.net>
<Nuke> "can NE1 help me aim nuclear weaponz????? /MSG ME!!"

[prev in list] [next in list] [prev in thread] [next in thread]