Mailing List Archive

I think as long as you do not use an INPUT queue, leave it blank and
make it default accept, you do not need to use state.

Anything requiring an INPUT target though needs state.

-gc

Florin Andrei wrote:
> I need to build a firewall in front of a cluster of HTTP servers. The
> firewall has 2 interfaces, "inside" (facing the cluster) and "outside"
> (facing the Internet).
> Each server has a private IP address, so the firewall must translate
> each server address to a public address on the external interface (I
> guess that's called 1:1 NAT, it's exactly what a PIX firewall would do
> via a "static (inside,outside) foobar-out foobar-in netmask
> 255.255.255.255" statement).
>
> Since HTTP is the only thing traversing the firewall, I don't really
> need a stateful firewall. In fact, in order to build some redundancy
> into the firewalling layer, a stateless firewall is even better: I
> just build 2 or more stateless firewalls and only transfer the IP and
> MAC if the primary fails - no need to transfer the state.
> Moreover, since the total bandwidth will be very high, that's one more
> reason to not do stateful filtering (less work for the firewall).
>
> The problem is, NAT seems to imply stateful filtering. The moment I
> start playing with the nat table, the ip_conntrack module gets loaded.
>
> Questions:
>
> Is there a way to do NAT on a true stateless firewall? (no conntrack
> loaded)
>
> If the answer to the previous q is negative, can I just ignore
> conntrack and build the filter and nat tables as if conntrack would
> not exist? I'm trying to figure out if there's any interaction with
> conntrack in this scenario, but I don't know netfilter well enough to
> be 100% sure.
>

Florin Andrei wrote:
>
> Is there a way to do NAT on a true stateless firewall? (no conntrack
> loaded)

I stumbled upon "-t raw" and I'm testing it, looks like it does what I
need. I'll do some tests.

Currently the biggest problem is that I can't seem to enable proxy ARP
with DNAT (which should be quite simple, or so I thought), but that's an
entirely different issue.

--
Florin Andrei

http://florin.myip.org/

On 8/2/2007 10:30 PM, Florin Andrei wrote:
> Currently the biggest problem is that I can't seem to enable proxy ARP
> with DNAT (which should be quite simple, or so I thought), but that's an
> entirely different issue.

Dare I ask why you are wanting to use Proxy ARP?



Grant. . . .

Hello,

Florin Andrei a écrit :
[...]
> Since HTTP is the only thing traversing the firewall,

Really ? No ICMP error messages, no outgoing DNS queries ?

> The problem is, NAT seems to imply stateful filtering. The moment I
> start playing with the nat table, the ip_conntrack module gets loaded.

Iptables NAT is stateful by design and requires the connection tracking.
However it does not imply stateful filtering, i.e. the use of connection
tracking matches such as 'state' or 'conntrack' in filtering rules.

> Is there a way to do NAT on a true stateless firewall? (no conntrack
> loaded)

There used to be a stateless NAT implemented in routing code of old
kernels enabled by the option CONFIG_IP_ROUTE_NAT. It could be set up
with 'ip rule' and 'ip route' commands. But it was considered broken and
has been removed since version 2.6.9. However it is still present in
recent 2.4 kernels.

> If the answer to the previous q is negative, can I just ignore conntrack
> and build the filter and nat tables as if conntrack would not exist?

Yes, of course. But keep in mind that iptables NAT is stateful by design.

> I stumbled upon "-t raw" and I'm testing it, looks like it does what I need.

If you mean using the NOTRACK target, this is a bad idea. Packets in the
UNTRACKED state will be ignored by the connection tracking *and* thus by
the stateful NAT which depends on it.

Pascal Hambourg wrote:
> Florin Andrei a écrit :
>> Since HTTP is the only thing traversing the firewall,
>
> Really ? No ICMP error messages, no outgoing DNS queries ?

Right, some ICMP stuff required by TCP, which can also be handled stateless.
DNS is separate. The traffic on the "master blaster" is kept very simple.

>> I stumbled upon "-t raw" and I'm testing it, looks like it does what I
>> need.
>
> If you mean using the NOTRACK target, this is a bad idea. Packets in the
> UNTRACKED state will be ignored by the connection tracking *and* thus by
> the stateful NAT which depends on it.

You're right. :-(
I assume I can still pretend that conntrack does not exist, and just
write the rules as if it was a stateless firewall. It will waste CPU
cycles and memory, but that's fine. I can even tweak the netfilter
parameters so that the connection tracking expires much faster, to keep
the size down.
A stateless firewall will fail over much more quickly and more reliably
than any stateful firewall.

I would use conntrackd, I just don't know how well tested it is in
high-bandwidth high-reliability setups. I may revise that decision, but
right now I'm focusing on stateless.

Security with stateless should not be a problem in such a simple
configuration (only one open port, well-behaved protocol, all traffic
initiated from outside).

Grant Taylor wrote:
>
> Dare I ask why you are wanting to use Proxy ARP?

Well, it's required by DNAT, isn't it? It looks like even SNAT to an
address different than the main IP on the firewall interface requires it
for the return traffic.
I'm snooping the traffic, I see the ARP request for the DNAT'ed address,
but there's no reply. So the firewall must be told to answer that request.

I'm not yet sure why this is so complicated. I remember doing proxy ARP
on Slackware 10 years ago (that was, like, kernel 2.0 or something like
that) and it was a very straightforward job.

<sigh> back to doing tests.

--
Florin Andrei

http://florin.myip.org/

Florin Andrei wrote:
> Grant Taylor wrote:
>>
>> Dare I ask why you are wanting to use Proxy ARP?
>
> Well, it's required by DNAT, isn't it?

I take that back. I figured it out.

I actually tested the idea yesterday, but it failed because one of the
test machines was not configured properly.

To make proxy ARP work with DNAT, an IP alias must be created on the
external interface, with the public IP address of the machine behind the
firewall.

ip address add XXX.YYY.ZZZ.KKK dev eth0

where XXX.YYY... is the public IP address that corresponds to the
private IP address of a server behind the firewall.

It's not even necessary to play with proxy_arp in /proc. Just the IP
alias and DNAT.

--
Florin Andrei

http://florin.myip.org/

Florin Andrei wrote:
> Florin Andrei wrote:
>> Grant Taylor wrote:
>>>
>>> Dare I ask why you are wanting to use Proxy ARP?
>>
>> Well, it's required by DNAT, isn't it?
>
> I take that back. I figured it out.
>
> I actually tested the idea yesterday, but it failed because one of the
> test machines was not configured properly.
>
> To make proxy ARP work with DNAT, an IP alias must be created on the
> external interface, with the public IP address of the machine behind
> the firewall.
>
> ip address add XXX.YYY.ZZZ.KKK dev eth0
>
> where XXX.YYY... is the public IP address that corresponds to the
> private IP address of a server behind the firewall.
>
> It's not even necessary to play with proxy_arp in /proc. Just the IP
> alias and DNAT.
>


I think you could even get away with just creating a static arp entry.

M4

On 08/03/07 14:11, Florin Andrei wrote:
> It's not even necessary to play with proxy_arp in /proc. Just the IP
> alias and DNAT.

Right. I did not think you would really need Proxy ARP, even before I
read why you wanted it. Now that I have read why you wanted it I was
getting ready to reply stating such until I read this statement.



Grant. . . .

Florin Andrei a écrit :
>> Grant Taylor wrote:
>>>
>>> Dare I ask why you are wanting to use Proxy ARP?
>>
>> Well, it's required by DNAT, isn't it?

No it's not. Proxy ARP may be useful as a workaround for broken routing
setups, when the source host thinks the destination host is on the same
link but actually it is behind a router.

[...]
> To make proxy ARP work with DNAT, an IP alias must be created on the
> external interface, with the public IP address of the machine behind the
> firewall.

If you do that you do not need proxy ARP.

> It's not even necessary to play with proxy_arp in /proc. Just the IP
> alias and DNAT.

Right. I guess another way would have been to add a route to the virtual
public IP addresses pool and enable proxy ARP (not tested though).

Martijn Lievaart wrote:
>
> I think you could even get away with just creating a static arp entry.

Like this?

arp -s XXX.YYY.ZZZ.KKK -i eth0 -D eth0 pub

I tested it, but it doesn't seem to work. I see the ARP requests, but
the server does not respond to it.

--
Florin Andrei

http://florin.myip.org/

Florin Andrei wrote:
> Martijn Lievaart wrote:
>>
>> I think you could even get away with just creating a static arp entry.
>
> Like this?
>
> arp -s XXX.YYY.ZZZ.KKK -i eth0 -D eth0 pub
>
> I tested it, but it doesn't seem to work. I see the ARP requests, but
> the server does not respond to it.
>

Bugger. I don't see why, but you have another solution so it's not
important.

M4

On 08/03/07 14:56, Florin Andrei wrote:
> arp -s XXX.YYY.ZZZ.KKK -i eth0 -D eth0 pub

Remember that ARP (cache) entries are just to tell a host where (what
MAC) an IP address (on the same subnet) is at so that the local host
does not have to ARP for it.

> I tested it, but it doesn't seem to work. I see the ARP requests, but
> the server does not respond to it.

Just because traffic may be coming to the correct MAC address, there is
no guarantee that any thing will be listening or responding at that MAC
address for the IP address in question. You would actually have to bind
the IP to the MAC for any thing of value to happen out side of sniffing.



Grant. . . .

Grant Taylor wrote:
> On 08/03/07 14:56, Florin Andrei wrote:
>
>> arp -s XXX.YYY.ZZZ.KKK -i eth0 -D eth0 pub
>>
>
> Remember that ARP (cache) entries are just to tell a host where (what
> MAC) an IP address (on the same subnet) is at so that the local host
> does not have to ARP for it.
>
>
>> I tested it, but it doesn't seem to work. I see the ARP requests, but
>> the server does not respond to it.
>>
>
> Just because traffic may be coming to the correct MAC address, there is
> no guarantee that any thing will be listening or responding at that MAC
> address for the IP address in question. You would actually have to bind
> the IP to the MAC for any thing of value to happen out side of sniffing.
>

I remember using this with host routes. The arp makes the packet arrive,
routing gets it to it's destination. I'm actually surprised the above
does not work. Unfortunately I currently have no setup to test this.
Anyone can explain why it doesn't wwork?

M4

On 8/5/2007 3:16 PM, Martijn Lievaart wrote:
> I remember using this with host routes. The arp makes the packet arrive,
> routing gets it to it's destination. I'm actually surprised the above
> does not work. Unfortunately I currently have no setup to test this.
> Anyone can explain why it doesn't work?

Please keep in mind that ARP is a method to identify the MAC address of
an IP address in the same subnet, nothing more.

If two hosts in the same subnet want to communicate with each other they
will send the traffic to each others MAC address. If the sending host
does not know the MAC address of the target host, the sending host will
then send and ARP request to locate the MAC address of the target host.
Once the sending host knows the MAC address of the target host it will
send the actual traffic directly to the target host.

If two hosts *NOT* in the same subnet want to communicate with each
other they will send the traffic via a (default) gateway. The gateway
in to the target subnet will then send the traffic to the target's MAC
address. If the gateway does not know the MAC address of the target
host it will send an ARP request to locate the MAC address. Once the
gateway knows the MAC address of the target host it will send the actual
traffic directly to the target host.

Consider the following scenario.

+--------+ +-----------------+ +--------+
| Host A +---+ (1) Gateway (2) +---+ Host B |
+--------+ +-----------------+ +--------+

Host A has a static MAC address entry for the Gateway NIC (1).
Gateway has a static MAC address entry for Host A.
Gateway has a static MAC address entry for Host B.
Host B has a static MAC address entry for the Gateway NIC (2).

As long as Host A has a route to Host B by way of Gateway NIC (1) and
Host B has a route to Host A by way of Gateway NIC (2), then hosts A and
B can communicate with each other with out having to use ARP at all.

You stated "... arp makes the packet arrive ...", which I must disagree
with. The sending host sends the traffic to the target hosts / gateways
NIC. Arp is used by the sending host to learn the MAC address of the
target host / gateway in the event that the sending host does not
already know it. Other than converting an IP address to MAC address,
ARP has nothing to do with the communications between two systems.



Grant. . . .

Grant Taylor wrote:
> You stated "... arp makes the packet arrive ...", which I must disagree
> with. The sending host sends the traffic to the target hosts / gateways
> NIC. Arp is used by the sending host to learn the MAC address of the
> target host / gateway in the event that the sending host does not
> already know it. Other than converting an IP address to MAC address,
> ARP has nothing to do with the communications between two systems.
>


The sender wants to send a packet. It uses arp to find out which MAC to
send to. It sends it. The packet arrives at the destination nic. That's
all I ment, not more, not less.

However, having arrived at the nic, the packet is then transfered to the
stack. If the stack does not know about the destination IP, the packet
is dropped by routing, iirc. However, before routing (in PREROUTING) the
destination is changed to something the stack does know about. So how
comes it does not work?

M4

On 08/06/07 00:01, Martijn Lievaart wrote:
> The sender wants to send a packet. It uses arp to find out which MAC to
> send to. It sends it. The packet arrives at the destination nic. That's
> all I ment, not more, not less.

Ok, agreed. The only thing I'll add is that ARP is one way for the
sender to identify the MAC to send the packet to, there are other ways too.

> However, having arrived at the nic, the packet is then transfered to the
> stack. If the stack does not know about the destination IP, the packet
> is dropped by routing, iirc. However, before routing (in PREROUTING) the
> destination is changed to something the stack does know about. So how
> comes it does not work?

I would think that this could work if you caught the packet in time to
re-direct it elsewhere. I will have to go back and re-read this thread
to better respond later (when I have time). At the moment, I agree that
this should work if it is implemented correctly.

So long as you can direct the packet where you want to and there is no
firewalling and / or kernel based filtering like reverse path filters
causing the low level networking to drop the packets this should work.
In fact, the receiving hosts actions is this is the bases for many
different solutions.



Grant. . . .