Connection from inside to aliased address on firewall.

Brian Adams bigb@satx.rr.com
Thu, 27 Apr 2000 21:33:19 -0500


--------------AC896EC18A554FC475B1FB09
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Sorry if I miss understand, but why not just make dns or /etc/hosts point to
external ip?
B

Rusty Russell wrote:

> In message <39060CA3.2F321A2B@rocketrange.no> you write:
> > Hello!
>
> Hi Sture!
>
> > Firewall box has three NIC's:
> > eth0 to Internet
> > eth1 to Private net
> > eth2 to DMZ
> >
> > Now to my problem:
> > I've got one machine in the private net that everybody, from everywhere,
> > should be allowed to access. What I've done is to make an alias on eth0
> > representing this one machine. When others connect to this IP on some
> > spesific port the connection are DNAT'ed to the internal machine. When
> > this one replies to the connection it is beeing SNAT'ed to the aliased
> > IP. This is all well for connections going from outside and inwards to
> > the internal machine, no problem. Trouble is I would also like the other
> > machines (those in DMZ and the private net) to be able to connect to the
> > internal machine using the aliased IP. I followed the instructions in
> > 'Linux 2.4 NAT Howto' that describes how to allow for internal machines
> > to connect on aliased IP's. Like:
> >
> > iptables -t nat -A OUTPUT -d aliased_ip --dport some_port -j DNAT --to
> > internal_machine:some_port
>
> That is for connections on the iptables box itself (OUTPUT is for
> local packets).  Your problem is most likely caused by the generation
> of ICMP redirects which are confusing the clients (and are wrong in
> this case: the packets really do need to go through the iptables box,
> even if the destination is on the same wire):
>
>     echo 0 > /proc/sys/net/ipv4/conf/eth1/send_redirects
>
> > PS! I've had the system running some days now, and have had two reports
> > on network failure for machines behind the firewall. Both beeing on
> > machines running NT4 SP4. Upgrading to SP5 got rid of the problem. Both
> > machines worked perfectly when behind an ipchains firewall. Is it
> > iptables or the new kernel involved that's causing this?
>
> I'd love to see a detailed report of this.  Were they trying to
> connect to the firewall itself (say a proxy?), or simply pass through
> it?  What were the symptoms: DNS lookup failures, connections not
> being established, hanging halfway through?
>
> It could be either...
> Rusty.
> --
> Hacking time.

--
Brian Adams
"I want to tell you my secret now.  I see packets."



--------------AC896EC18A554FC475B1FB09
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
Sorry if I miss understand, but why not just make dns or /etc/hosts point
to external ip?

B

Rusty Russell wrote:

In message <39060CA3.2F321A2B@rocketrange.no> you write:
> Hello!

Hi Sture!

> Firewall box has three NIC's:
> eth0 to Internet
> eth1 to Private net
> eth2 to DMZ
>
> Now to my problem:
> I've got one machine in the private net that everybody, from everywhere,
> should be allowed to access. What I've done is to make an alias on eth0
> representing this one machine. When others connect to this IP on some
> spesific port the connection are DNAT'ed to the internal machine. When
> this one replies to the connection it is beeing SNAT'ed to the aliased
> IP. This is all well for connections going from outside and inwards to
> the internal machine, no problem. Trouble is I would also like the other
> machines (those in DMZ and the private net) to be able to connect to the
> internal machine using the aliased IP. I followed the instructions in
> 'Linux 2.4 NAT Howto' that describes how to allow for internal machines
> to connect on aliased IP's. Like:
>
> iptables -t nat -A OUTPUT -d aliased_ip --dport some_port -j DNAT --to
> internal_machine:some_port

That is for connections on the iptables box itself (OUTPUT is for
local packets).  Your problem is most likely caused by the generation
of ICMP redirects which are confusing the clients (and are wrong in
this case: the packets really do need to go through the iptables box,
even if the destination is on the same wire):

    echo 0 > /proc/sys/net/ipv4/conf/eth1/send_redirects

> PS! I've had the system running some days now, and have had two reports
> on network failure for machines behind the firewall. Both beeing on
> machines running NT4 SP4. Upgrading to SP5 got rid of the problem. Both
> machines worked perfectly when behind an ipchains firewall. Is it
> iptables or the new kernel involved that's causing this?

I'd love to see a detailed report of this.  Were they trying to
connect to the firewall itself (say a proxy?), or simply pass through
it?  What were the symptoms: DNS lookup failures, connections not
being established, hanging halfway through?

It could be either...
Rusty.
--
Hacking time.

-- 
Brian Adams
"I want to tell you my secret now.  I see packets."
  --------------AC896EC18A554FC475B1FB09--