Re: yet/last problem with masquerading

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, 13 Oct 2002, Michael Schwendt wrote:

> On Sun, 13 Oct 2002 10:16:04 +0200 (CEST), Jean Francois Ortolo wrote:
> 
> > > >   I presume my script should contain these few instructions:
> > > > 
> > > >   --- Beggining of the script
   <..snip..>
> > > >   route add -net 192.168.1.0 netmask 255.255.255.0  /
> > > >                              gw ${IPADDR} dev eth1 
> > > >   --- End of the script
> > > 
   <..snip..>
> 
> What type of ADSL connection is it? 
> 

  I don't know that yet. Probably PPPoE, from a look to the /sbin/ifup 
script, I acknowledged this is the only one xDSL connection type available 
in RedHat 8.0, I might be wrong. I'll inquire about that with the isp I 
have in view.

> What do you mean with "route between eth0 and eth1"? The route 
> between eth0 and eth1, so traffic from the LAN would find its way
> into the Internet and vice versa, would be the "default route" from
> your router via PPP/ADSL to the Internet. Usually, pppd would create
> the default route (into Internet). And on your client hosts in the
> LAN you would only need a default route to your gateway (the
> router):
> 
>   ip route add default via ${YOUR_SERVER_IP}
> or
>   route add default gw ${YOUR_SERVER_IP}
> 

  I know this kind of configuration is mandatory, so the internal 
computers could connect via the router to the Internet, using the 
router as a gateway.

> If $IPADDR in your example is the external IP address of your
> gateway (probably a dynamically assigned IP addr), I don't see how
> above route makes sense. It says that hosts on the network
> 192.168.1.0/24 are reachable via gateway host $IPADDR on eth1. But
> the gateway host is localhost, the router with both eth0 and eth1.
> And you should have a route to 192.168.1.0/24 via eth1 without
> setting it up manually (run "route" or "ip r s" to see).
> 

  I understand well now, the path between eth0 and eth1 is being made by 
the forwarding instruction in my script.

  Otherwise, pppd knows only about eth0, which is the interface connected 
to the ADSL modem. pppd knows nothing about eth1, so pppd is unable to 
make eth0 and eth1 communicate between each other.
 
> >   Indeed, IP Masquerading is able to take into account all that is 
> > required, in order to make an existing connection coming along, if
> > this connection was being requested from inside the lan to the
> > external network.
> > 
> >   However, what happens if the current involved protocol launchs a 
> > request to, let's suppose 113 auth port inside the lan ?
> 
> It would not be masqueraded because in the postrouting chaing you do
> only masquerade packets which go out eth0.
> 
> >   There should be then a new connection coming from the outside
> >   network to 
> > the external address of the lan, with a destination port 113, no ?
> 
> Why "outside network"? It's a connection on the internal interface
> with a local IP address.
> 

  I've badly exprimed myself. I meant 'connection request from the 
Internet to port 113 through my router'. This kind of authentication is 
required by some protocols/services, so the person inside my lan which 
invokes this protocol/service, could authenticate himself.

  This authentication would be requested, after the protocol has been 
initiated by a request for connection coming from an internal lan computer 
to the Internet.

  The problem is: The request from the Internet to the port 113 through my 
router, will be addressed to the external IP of my router, so there is two 
alternatives:

  1) This new request for authentication towards port 113, is part of 
the initial protocol connection. This way, the masquerading translates the
destination IP of the incoming packet ( external IP of my router ), to the 
proper internal IP of the internal computer which initiated the 
connection, then this computer well receives this request for 
authentication, and is able to respond to it.

  2) This new request for authentication towards port 113, is part of a 
entirely new connection request, so what makes the packet will be 
redirected to the proper IP of the internal computer which initiated the 
connection ? 

> >   The whole problem is whether or not this kind of authentification, 
> >   would 
> > involve specifically a new incoming connection. Is it true ?
> 
> Not sure whether I understand you. A connection from the LAN to port
> 113 of your gateway host comes in with a local IP address via the
> internal interface (eth1) and the input chain. A connection from the
> Internet to port 113 of your gateway host comes in with a non-local
> IP addr via the external interface (ppp => eth0) and the input chain
> and the external IP of as destination address.
> 
> 

In my case, the service/protocol, after having been requested from an 
internal computer in the lan, to the Internet via my router, would involve 
an incoming request for authentication, which should be directed to the
internal computer, the problem being to precisely know, whether or not 
this incoming request for authentication is part of an entirely new 
connection, or is part of the actual connection.

  Many thank for your help.

  I fully apologize for my newbieness.

  Best regards.

  Jean Francois Ortolo







[Index of Archives]     [Fedora General Discussion]     [Red Hat General Discussion]     [Centos]     [Kernel]     [Red Hat Install]     [Red Hat Watch]     [Red Hat Development]     [Red Hat 9]     [Gimp]     [Yosemite News]

  Powered by Linux