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

List:       cipe
Subject:    CIPE and masquerading problems: reported to Linux newsgroups
From:       John Heenan <sad () eagles ! bbs ! net ! au>
Date:       1998-11-01 10:51:13
[Download RAW message or body]

Below is my contribution to bringing CIPE and Linux closer to read world
practical use.  I have made postings or replies relevant to this to both
the LRP and CIPE mailing lists. 

I have put a lot of effort into ensuring the posting is not ambiguous. Not
that this is going to discourage newsgroup noise polluters.

John Heenan

Subject: Linux masquerading bug? Ipautofw, tunneling and CIPE demonstrates?

Newsgroups: comp.os.linux.development.apps,comp.os.linux.networking

Following is a report of regrettable behavior using a number of facilities
in combination with Linux masquerading.

At this stage I am simply looking for an acknowledgment of the problem.
Below is a diagram indicating a test bed setup. Interface device Bcipe
(and Ccipe) are encryption tunnel network devices.


      Bcipe--       --Ccipe
      Bppp---       ---Cppp          
  A   B                   C   D
  |___|                   |___|

192.168.3.0             192.168.2.0


B masquerades all traffic from the 192.168.3.0 network
C masquerades all traffic from the 192.168.2.0 network
C has an ipautofw firewall rule that forwards port 23 telnet traffic to
D

Suppose masquerading is turned off. No problems (if routing and forwarding
rules are appropriate). When masquerading is turned on on both networks I
would expect that when A attempts a TCP connection to D that D thinks it
is obtaining a connection from B instead of A.  I would expect that when
the incoming connection request comes into C for D (from A masqueraded as
from B) that the masquerading software on C would forward the packet onto
D.  I would expect D to reply with a packet for B (to go eventually to A
due to masquerading). At this stage one might wonder if masquerading
software on C, or networking software on relevant machines, is smart
enough to allow replies form D to pass through uninterfered, or be coped
with if interfered, by masquerading software on C.

The answer is no if tunneling (either encryption or pure Linux tunnel
drivers) is used but the answer is yes if there is a direct dial up
network connection between B and C without any tunneling.

I am not knowledgeable enough to know if this is even a bug.  Since a
direct dial up connection works without tunneling I am inclined to think a
bug does exist.

With regard to port forwarding of port 23 traffic on C to D (using
ipautofw and not the new ipportfw utility), this is a separate (but
possibly related) problem. If masquerading is turned on then another
machine on its network (192.168.2.0) cannot get a connection
auto-forwarded to D via C.  However a direct connection can of course be
obtained. Mentioning this problem may help. 

There are practical means of overcoming the masquerading problem. One is
to use more than one network number on a physical network. One network
number is masqueraded, the other is not.

John Heenan
















--
-Message sent by the cipe-l mailing list. To unsubscribe mail majordomo@inka.de

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