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