Kevin Tappe wrote:
>may be a problem with firewalling, too.
> After all the help I have received I have managed to get my ISDN connection up with proper authentication, etc. However, I cannot do anything with it - using kISDN under
> X I can see the IP addresses, that packets are being transmitted/received, but there is no response from Netscape, if I try to ping or telnet another server, etc. Is this a
> routing problem?
>
seems to me to be one
Short guide:
before you do anything: get an idea of the IP addressing concept. It's a little bit tricky but not really difficult.
First step: get your box connected to your ISP
second step: get your box connected to your local net. Don't forward IP-packets up to now!
third step: enable masquerading. Don't forward IP-packets up to now!
fourth step: enable firewalling. Now you may begin to
forward IP-packets. Be careful! Read the firewalling HowTo!!
(1.1.1.1 is not really a good idea!)>
> Below is the output of /var/log/messages and /etc/route.conf. In the latter case I assume YaST configured the routing; I have tried different addresses for ippp0 including
> one out of range on my local net, without success. 1.1.1.1 was a frustrated last resort.
>
local (non used) addresses and 1.1.1.1 are ok, they are changed into
real ones when connecting.
YAST defaults to 192.168.0.99 for the local address and
192.168.0.1 for the remote address.
I would propose to accept those values and change your
ethernet's subnet. If that's impossible, be sure to use a network out of
the range of the "private" AND valid IP-addresses. See the firewalling
and ipchains HowTo! net-3 HowTo is too complex for beginners.
Your initial problem may have been that you assigned
the same subnet to two interfaces.
Woe!
> Also, I notice that when conected to the ISP the remote IP is always the same -
> shouls I use this as the Point-to-point partner, or doesn't this matter in YaST's setup?
>
it doesnt matter if you do, but if you do be carefull:
all packets which are not addressed to your localnet will be transmitted
to the globalnet -> i4l will call your provider
Well, the remote id is one thing, but not really important
- what about the local IP? THAT is YOUR address on the internet.
If you want to connect to the Internet, you *must* enter
the **local** IP-address of your ippp0 device as default gateway (YAST
defaults to 192.168.0.99). During the connect, ipppd sets the real adresses
for your local IP and the remote(ISP)'s IP. You had it in your protocol:
ipppd[2754]: rcvd [0][IPCP ConfReq id=0x31 <addr 155.239.75.254>]
ipppd[2754]: sent [0][IPCP ConfAck id=0x31 <addr 155.239.75.254>]
ipppd[2754]: rcvd [0][IPCP ConfReq id=0x32 <addr 155.239.75.254>]
ipppd[2754]: sent [0][IPCP ConfAck id=0x32 <addr 155.239.75.254>]
ipppd[2754]: sent [0][IPCP ConfReq id=0x1 <addr 0.0.0.0>]
ipppd[2754]: rcvd [0][IPCP ConfNak id=0x1 <addr 155.239.75.231>]
pppd[2754]: sent [0][IPCP ConfReq id=0x2 <addr 155.239.75.231>]
ipppd[2754]: rcvd [0][IPCP ConfAck id=0x2 <addr 155.239.75.231>]
ipppd[2754]: local IP address 155.239.75.231
<------ YOUR ADDRESS
ipppd[2754]: remote IP address 155.239.75.254
<------ ISP ADDRESS
after this negotiation your route should look different
(use "route -n")
Hint: Take a look at your interface configuration ("ifconfig").
It may be very interesting.
Note: The packets, you don't want to leave your network can be filtered out with ipchains. Not trivial, but manageable.
Hint1:'** ANY** IP-address which is not local, should apply to a node on the internet, why else should there be a difference betweeen "local"/"private" and "remote"/"official" addresses. Exception: virtual private networks (VPN) and/or tunnelling. Both are advanced topics.
Hint2: Look at the configuration file with YAST. Did You bind ipppd to your ISDN-device?
As I mentioned above, take a look at "ifconfig" as well.> # ISDN (i4l)
> # 192.168.0.1 0.0.0.0 255.255.255.255 ippp0
> # default 192.168.0.1
> 192.168.0.0 0.0.0.0 255.255.255.0 eth0
> 1.1.1.1 0.0.0.0 255.255.255.255 ippp0
>
what is the output of "route -n" while an established connection?
One BIG problem: you didn't mention the release version of SuSE.-Kevin
---------------------------------------------------------------------
To unsubscribe, e-mail: suse-isdn-unsubscribe@suse.com
For additional commands, e-mail: suse-isdn-help@suse.com
- Georg
-------------------------------------------------------------------------
I learned it, why shouldn't you be able to learn
it too?