PPPD server routing problem? Mandrake/mgetty/pppd/D-link router

Hello Everyone.

Hopefully someone one can point me in a direction as I am fresh out of
ideas.

I have built a PPPD server for a single inbound ppp dial-in conection on my
Mandrake Linux 9.1 box using mgetty and pppd.

Overall network connection is as follows:

Internet <--> DSL modem/D-Link router <--> PPPD server <--> dialin client

I have the client making a connection and can send packet requests out into
the internet.

The problem appears to be that the packets go out from the client to the
internet just fine. But when the inbound packet responses come back from
the internet they hit the pppd server box and they are not passed back to
the ppp0 connection. [based on what I am seeing in tcpdump for both ppp0
and eth0 on the pppd server.]

If someone could point me in a direction or possibly give me some hints how
to fix this, it would be greatly appreciated.

Thank you

Luther

martin02 wrote:
> Overall network connection is as follows:
>
> Internet <--> DSL modem/D-Link router <--> PPPD server <--> dialin client
>
> I have the client making a connection and can send packet requests out into
> the internet.
>
> The problem appears to be that the packets go out from the client to the
> internet just fine. But when the inbound packet responses come back from
> the internet they hit the pppd server box and they are not passed back to
> the ppp0 connection. [based on what I am seeing in tcpdump for both ppp0
> and eth0 on the pppd server.]

Try sending some information about Your routing and packet filtering
setup...

That responses from the internet return to Your dial-in server shows
that You SNAT those all right, but did You SNAT or MASQUERADE them?

Can the client get anything else from that box?


Cheers, Jack.

--
----------------------------------------------------------------------
My personal reading of the string "MicroSoft" expands to "NanoWeak"...

jack wrote:

> martin02 wrote:
>> Overall network connection is as follows:
>>
>> Internet <--> DSL modem/D-Link router <--> PPPD server <--> dialin client
>>
>> I have the client making a connection and can send packet requests out
>> into the internet.
>>
>> The problem appears to be that the packets go out from the client to the
>> internet just fine. But when the inbound packet responses come back from
>> the internet they hit the pppd server box and they are not passed back to
>> the ppp0 connection. [based on what I am seeing in tcpdump for both ppp0
>> and eth0 on the pppd server.]
>
> Try sending some information about Your routing and packet filtering
> setup...
>
> That responses from the internet return to Your dial-in server shows
> that You SNAT those all right, but did You SNAT or MASQUERADE them?
>
> Can the client get anything else from that box?
>
>
> Cheers, Jack.
>

Jack,

Thank you for taking the time to reply.

=====
Answer 1 and Answer 2
The last time I worked on MASQ and packet filtering we were using IPCHAINS
in Mandrake v8.x. The paradigm for is sufficiently different with IPTABLES
that they spin me around for a loop and hadn't gotten a grasp on how they
work, so I haven't touched them yet.

I seem to have an opportunity. Neither IPCHAINS nor IPTABLES are installed.
I wonder how I missed that. Probably because I got lazy using a hardware
router and installed Mandi v9 clean using defaults.

So regarding your routing and packet filtering question, whatever the
defaults are for Mandrake 9.0/9.1 w/o IPCHAINS and IPTABLES installed. The
routing instructions I currently use are at the end of this reply as part
of the modified config entries below.

Basically a clean slate to work with.

=====
Answer 3
The client can ping and receive replies inside the local LAN and from the
D-Link router itself, but not pull down any files from the web server that
is part of the same box as MGETTY/PPPD. (This might have been a fluke. I
only tested the local web sporadically.)

It can ping beyond the D-Link router (outside the LAN), but the replies are
stopped at the PPPD server. The D-Link's NAT is probably nailing me here.

=====
Speculation
With the D-Link is running some NAT to get it back to the PPPD server box.
I am pretty sure that the problem is that you can't translate IP addresses
twice out to the internet. Once in the D-link and a second time at the PPPD
server. If it was possible to get the IP address assigned from the D-Link
DHCP server via the ppp0 connection, I am thinking the problem would
correct itself. But I don't know how to do that, or if it is even
possible. That would probably be the most elegant solution.

=====
Configuration
These are the changes from "defaults" so far.

MGETTY - Enable AutoPPP in login.config:
/AutoPPP/ - a_ppp /usr/sbin/pppd auth -chap +pap debug

MGETTY - Added Modem init stuff to mgetty.config:
# For US Robotics Sportster 28.8 with speaker off
port ttyS0
init-chat "" ATZ OK AT&F1M0E1Q0S0=0 OK
answer-chat "" ATA CONNECT \c \r
statistics-file /var/log/statistics.ttyS0

MGETTY - No changes to default dialin.config

PPPD - Changed contents of "options" file <note: I could not get AutoPPP to
fire up a "options.server" file. Some more RTFM me thinks to fix this, but
I do not believe it is important as I don't use pppd for anything else
right now.>
-detach
asyncmap 0
modem
crtscts
lock
proxyarp
netmask 255.255.255.0
ms-dns <IP address to ISP DNS1>
ms-dns <IP address to ISP DNS2>
require-pap
refuse-chap
192.168.0.133:192.168.0.200 <where 1st IP is eth0 and 2nd IP is ppp0>

PPPD - Added a "options.ttyS0" file.
ppp0.myhost.netpp0
192.168.0.133:192.168.0.200 [duplicated entry. see options file.]
ms-dns <IP address to ISP DNS1> [duplicated entry. see options file.]
ms-dns <IP address to ISP DNS2> [duplicated entry. see options file.]

PPPD - Setup "pap-secrets" file for non-linux box user access. The user is
not intended to log into the Linux box at all, although he can if if comes
in via SLIP. <probably should disable SLIP, but not now.>
# Secrets for authentication using PAP
# client server secret IP addresses
user1 * password 192.168.0.200

PPPD - Setup "ip-up.local" file. Currently disabled because there is already
a default route that keeps getting recreated to the D-Link gateway and the
packets sent from ppp0 were getting re-routed backwards back into ppp0
where they came from.
/sbin/route add default $1

HOST - Added entries to "host" file. <these are NOT intended to be internet
resolvable domain names. This was intentional.>
192.168.0.200 ppp0.myhost.net
192.168.0.133 mydialin.myhost.net

INITTAB - Made change to "inittab" file to correct mgetty's default entries
and commented the remaining entries out.
S1:345:respawn:/sbin/mgetty -D -x2 /dev/ttyS0

ROUTING - These are commands entered by hand at the moment. I haven't
decided where to put them yet as I think I need them built when a ppp0
connection is established and torn down when the connection is severed.
The echo commands seemed to do the most work. I haven't decided if I need
the ifconfig and route commands yet.
echo 1 > /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp
ifconfig eth0:0 192.168.0.200
route add -host 192.168.0.200 dev eth0

jack wrote:

> martin02 wrote:
>> Overall network connection is as follows:
>>
>> Internet <--> DSL modem/D-Link router <--> PPPD server <--> dialin client
>>
>> I have the client making a connection and can send packet requests out
>> into the internet.
>>
>> The problem appears to be that the packets go out from the client to the
>> internet just fine. But when the inbound packet responses come back from
>> the internet they hit the pppd server box and they are not passed back to
>> the ppp0 connection. [based on what I am seeing in tcpdump for both ppp0
>> and eth0 on the pppd server.]
>
> Try sending some information about Your routing and packet filtering
> setup...
>
> That responses from the internet return to Your dial-in server shows
> that You SNAT those all right, but did You SNAT or MASQUERADE them?
>
> Can the client get anything else from that box?
>
>
> Cheers, Jack.
>

Oops, I didn't answer your third item correctly.
I was working my way out to more advanced functions.
Ping, Traceroute and a little bit of web browsing to begin with. No point
in trying anything else if Ping and Traceroute don't work.

Luther

martin02 wrote:
> Answer 1 and Answer 2
> The last time I worked on MASQ and packet filtering we were using IPCHAINS
> in Mandrake v8.x. The paradigm for is sufficiently different with IPTABLES
> that they spin me around for a loop and hadn't gotten a grasp on how they
> work, so I haven't touched them yet.
>
> I seem to have an opportunity. Neither IPCHAINS nor IPTABLES are installed.
> I wonder how I missed that. Probably because I got lazy using a hardware
> router and installed Mandi v9 clean using defaults.
>
> So regarding your routing and packet filtering question, whatever the
> defaults are for Mandrake 9.0/9.1 w/o IPCHAINS and IPTABLES installed. The
> routing instructions I currently use are at the end of this reply as part
> of the modified config entries below.
>
> Basically a clean slate to work with.

Unfortunally, I am not familiar with the Mandrake distribution.


> Answer 3
> The client can ping and receive replies inside the local LAN and from the
> D-Link router itself, but not pull down any files from the web server that
> is part of the same box as MGETTY/PPPD. (This might have been a fluke. I
> only tested the local web sporadically.)
>
> It can ping beyond the D-Link router (outside the LAN), but the replies are
> stopped at the PPPD server. The D-Link's NAT is probably nailing me here.



> Speculation
> With the D-Link is running some NAT to get it back to the PPPD server box.
> I am pretty sure that the problem is that you can't translate IP addresses
> twice out to the internet. Once in the D-link and a second time at the PPPD
> server. If it was possible to get the IP address assigned from the D-Link
> DHCP server via the ppp0 connection, I am thinking the problem would
> correct itself. But I don't know how to do that, or if it is even
> possible. That would probably be the most elegant solution.

You can definately masquerade any given connection as many times as You
want or need to do so.

But let's have a look at Your routing configuration:

> =====
> Configuration
> These are the changes from "defaults" so far.
>
> MGETTY - Enable AutoPPP in login.config:
> /AutoPPP/ - a_ppp /usr/sbin/pppd auth -chap +pap debug
>
> MGETTY - Added Modem init stuff to mgetty.config:
> # For US Robotics Sportster 28.8 with speaker off
> port ttyS0
> init-chat "" ATZ OK AT&F1M0E1Q0S0=0 OK
> answer-chat "" ATA CONNECT \c \r
> statistics-file /var/log/statistics.ttyS0
>
> MGETTY - No changes to default dialin.config
>
> PPPD - Changed contents of "options" file <note: I could not get AutoPPP to
> fire up a "options.server" file. Some more RTFM me thinks to fix this, but
> I do not believe it is important as I don't use pppd for anything else
> right now.>
> -detach
> asyncmap 0
> modem
> crtscts
> lock
> proxyarp
> netmask 255.255.255.0
> ms-dns <IP address to ISP DNS1>
> ms-dns <IP address to ISP DNS2>
> require-pap
> refuse-chap
> 192.168.0.133:192.168.0.200 <where 1st IP is eth0 and 2nd IP is ppp0>

What exactly do You want to have this for? - When using PPP, try to use
addresses that are separate from Your eth0-DLink subnet. (See below).


> PPPD - Added a "options.ttyS0" file.
> ppp0.myhost.netpp0
> 192.168.0.133:192.168.0.200 [duplicated entry. see options file.]
> ms-dns <IP address to ISP DNS1> [duplicated entry. see options file.]
> ms-dns <IP address to ISP DNS2> [duplicated entry. see options file.]
>
> PPPD - Setup "pap-secrets" file for non-linux box user access. The user is
> not intended to log into the Linux box at all, although he can if if comes
> in via SLIP. <probably should disable SLIP, but not now.>
> # Secrets for authentication using PAP
> # client server secret IP addresses
> user1 * password 192.168.0.200
>
> PPPD - Setup "ip-up.local" file. Currently disabled because there is already
> a default route that keeps getting recreated to the D-Link gateway and the
> packets sent from ppp0 were getting re-routed backwards back into ppp0
> where they came from.
> /sbin/route add default $1
>
> HOST - Added entries to "host" file. <these are NOT intended to be internet
> resolvable domain names. This was intentional.>
> 192.168.0.200 ppp0.myhost.net
> 192.168.0.133 mydialin.myhost.net
>
> INITTAB - Made change to "inittab" file to correct mgetty's default entries
> and commented the remaining entries out.
> S1:345:respawn:/sbin/mgetty -D -x2 /dev/ttyS0
>
> ROUTING - These are commands entered by hand at the moment. I haven't
> decided where to put them yet as I think I need them built when a ppp0
> connection is established and torn down when the connection is severed.
> The echo commands seemed to do the most work. I haven't decided if I need
> the ifconfig and route commands yet.
> echo 1 > /proc/sys/net/ipv4/ip_forward
> echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp
> ifconfig eth0:0 192.168.0.200
> route add -host 192.168.0.200 dev eth0

Now does the D-Link act as an DHCP server for Your PPPD server? - In
either case, what are the addresses used in Your combinaton?

From what I can say is that You are mixing up eth0:0 and ppp0. - Try
doing like this: The D-Link is connected to the PPPD server via eth0,
and both ends have one IP address in the 192.168.0/24 subnet.
Then, configure pppd so that ppp0 gets 192.168._1_.1 and the remote
peer (that one that dials in) gets 192.168.1.2.
Adjust the routing on the server to use the D-Link via eth0 as default
gw (which is already done, as You say), and add a route to 192.168.1.2
via ppp0.
On the client that You dial-in from, set 192.168.1.1 (the remote server)
as default gateway.

Now from what You had posted earlier, this should work right away on
Your Mandrake system. If not, You need to care about masquerading the
ppp0 connection with iptables, which is fairly simple. In this case,
You might want to ask for more help on that, but if You cant wait:

iptables -t nat -I POSTROUTING -s 192.168.1.2 -o eth0 -j MASQUERADE

Where here, You can choose whether You match the source address
"-s 192.168.1.2" of the peer or the interface "-i ppp0" that those
packets arrive on, since that is essentially the same box.


HTH, else let me know, Jack.

--
----------------------------------------------------------------------
My personal reading of the string "MicroSoft" expands to "NanoWeak"...

My comments interspersed below. Luther

jack wrote:

<snip>

>> =====
>> Configuration
>> These are the changes from "defaults" so far.
>>

>> PPPD - Changed contents of "options" file <note: I could not get AutoPPP
>> to
>> fire up a "options.server" file. Some more RTFM me thinks to fix this,
>> but I do not believe it is important as I don't use pppd for anything
>> else right now.>
>> -detach
>> asyncmap 0
>> modem
>> crtscts
>> lock
>> proxyarp
>> netmask 255.255.255.0
>> ms-dns <IP address to ISP DNS1>
>> ms-dns <IP address to ISP DNS2>
>> require-pap
>> refuse-chap
>> 192.168.0.133:192.168.0.200 <where 1st IP is eth0 and 2nd IP is
>> ppp0>
>
> What exactly do You want to have this for? - When using PPP, try to use
> addresses that are separate from Your eth0-DLink subnet. (See below).

Changed this to 192.168.1.1:192.168.1.2

>> PPPD - Setup "pap-secrets" file for non-linux box user access. The user
>> is not intended to log into the Linux box at all, although he can if if
>> comes
>> in via SLIP. <probably should disable SLIP, but not now.>
>> # Secrets for authentication using PAP
>> # client server secret IP addresses
>> user1 * password 192.168.0.200
>>

Changed this to because this was assigning the IP address to ppp0:
# Secrets for authentication using PAP
# client server secret IP addresses
user1 * password 192.168.1.2


>> PPPD - Setup "ip-up.local" file. Currently disabled because there is
>> already a default route that keeps getting recreated to the D-Link
>> gateway and the packets sent from ppp0 were getting re-routed backwards
>> back into ppp0 where they came from.
>> /sbin/route add default $1

Not sure if I am adding a route to ppp0 correctly. Reactivated ip-up.local
file and changed to the following:

/sbin/route add -host 192.168.1.2 dev ppp0
/sbin/route add -net 192.168.1.1**
echo 1 > /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp

** Added the "net" entry because the route entry by itself didn't work. But
this made no difference. Probably should delete the entry.

The new route does show up in the "route -n" listing once the ppp0
connection has been established.

Destination Gateway Genmask Flags Metric Ref Use
Iface
192.168.1.2 0.0.0.0. 255.255.255.0 U 0 0 0 ppp0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0

>>
>> HOST - Added entries to "host" file. <these are NOT intended to be
>> internet
>> resolvable domain names. This was intentional.>
>> 192.168.0.200 ppp0.myhost.net
>> 192.168.0.133 mydialin.myhost.net
>>

Changed to:
192.168.1.2 ppp0.myhost.net
192.168.1.1 mydialin.myhost.net

>> ROUTING - These are commands entered by hand at the moment. I haven't
>> decided where to put them yet as I think I need them built when a ppp0
>> connection is established and torn down when the connection is severed.
>> The echo commands seemed to do the most work. I haven't decided if I
>> need the ifconfig and route commands yet.
>> echo 1 > /proc/sys/net/ipv4/ip_forward
>> echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp
Moved these 2 entires into ip-up.local

>> ifconfig eth0:0 192.168.0.200
Stopped using this entry

>> route add -host 192.168.0.200 dev eth0
Changed to "route add -host 192.168.1.2 dev ppp0" and moved into ip-up.local

> Now does the D-Link act as an DHCP server for Your PPPD server? - In
> either case, what are the addresses used in Your combinaton?

Yes, the D-Link is set up to assigned IP via DHCP, BUT!! It is also
configured to always assign the same IP address based on the MAC address of
the eth0 card requesting one. So effectively, all devices on the LAN are
assigned the same IP address everytime they request one via DHCP. I had to
run DHCP services on the D-Link to be able to pass the current ISP's DNS
address info out to each local LAN client as the ISP changed them.

The D-Link local LAN is all 192.168.0.x addresses. I think this was what
you were asking for.
D-Link is 192.168.0.1
PPPD server is 192.168.0.133 (for eth0)


> From what I can say is that You are mixing up eth0:0 and ppp0.

I stopped using the "ifconfig eth0:0 192.168.x.x" command.

> - Try doing like this: The D-Link is connected to the PPPD server via
> eth0,
> and both ends have one IP address in the 192.168.0/24 subnet.
> Then, configure pppd so that ppp0 gets 192.168._1_.1 and the remote
> peer (that one that dials in) gets 192.168.1.2.

Did this. See my changes to ip-up.local, pap-secrets and host files above.

> Adjust the routing on the server to use the D-Link via eth0 as default
> gw (which is already done, as You say), and add a route to 192.168.1.2
> via ppp0.

I am not sure I added the route to 192.168.1.2 correctly. See ip-ip.local
changes above. Still pings and recieves responses from anything inside the
192.168.0.x local LAN. It won't pull up the D-Link web server at
192.168.0.1 though. But it will pull up the web server on the PPPD Server
at 192.168.0.133.

> On the client that You dial-in from, set 192.168.1.1 (the remote server)
> as default gateway.

Not possible with the Win98 PPPD Client. PPPD needs to assign the default
gateway to the Win98 client. Apparently, there is no way to do this from
inside PPPD as best I can tell.

The only option is to assign everything in the win98 Client. I don't like
to do this because my ISP keeps changing the DNS servers. Hard coding the
Win98 client would make it unreliable when doing DNS lookups as the ISP
changes the available DNS IP numbers over the course of the day.

I know, I'm 'between a rock and a hard place'. I'll deal with the DNS
problem later once I can get the PPPD client to start listening through the
PPPD server.

>
> Now from what You had posted earlier, this should work right away on
> Your Mandrake system.

Hasn't so far. *sigh*

> If not, You need to care about masquerading the
> ppp0 connection with iptables, which is fairly simple. In this case,
> You might want to ask for more help on that, but if You cant wait:
>
> iptables -t nat -I POSTROUTING -s 192.168.1.2 -o eth0 -j MASQUERADE

Installed iptables.

Your suggested MASQ line above doesn't work by itself. Keeps getting
"iptables:target error" even with or without the PPPD client up and
running.

Manually ran this sequence trying to get your line to be accepted:
modprobe iptable_nat
iptables -P INPUT ACCEPT
iptables -F INPUT
iptables -P OUTPUT ACCEPT
iptables -F OUTPUT
iptables -P FORWARD DROP
iptables -F FORWARD
iptables -t nat -F
iptables -A FORWARD -i eth0 -o ppp0 -m state --state ESTABLISHED,RELATED -j
ACCEPT
iptables -A FORWARD -i ppp0 -o eth0 -j ACCEPT
iptables -A FORWARD -j LOG

Then tried different variations of SNAT/MASQURADE, all result in some sort
of iptables error message:
iptables -t nat -I POSTROUTING -s 192.168.1.2 -o eth0 -j MASQUERADE
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -A POSTROUTING -o eth0 -j SNAT
iptables -t nat -I POSTROUTING -s 192.168.1.2 -o eth0 -j MASQUERADE

It won't take any variation of NAT entry for some reason.

I would have thought that "iptables -L nat" would have generated something,
but it doesn't like that command either.

Maybe I need some POSTROUTING pre-configuration commands up at the beginning
of setting up the inital iptables configuration. Something like:
iptables -P POSTROUTING ACCEPT
iptables -F POSTROUTING

Just guessing here.

===============================
Current output of "iptables -L"
===============================
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere
LOG all -- anywhere anywhere LOG level warning

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

I don't see a "Chain POSTROUTING" entry. Perhaps I didn't pre-configure it
first. My guess is that I haven't sucessfully created a POSTROUTING chain
yet.

====================================
Output of "ifconfig" with PPPD running
====================================
eth0 Link encap:Ethernet HWaddr 00:E0:18:7E:71:55
inet addr:192.168.0.133 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2866 errors:0 dropped:0 overruns:0 frame:0
TX packets:3232 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:1967241 (1.8 Mb) TX bytes:394822 (385.5 Kb)
Interrupt:12 Base address:0x4000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:118 errors:0 dropped:0 overruns:0 frame:0
TX packets:118 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:7762 (7.5 Kb) TX bytes:7762 (7.5 Kb)

ppp0 Link encap:Point-to-Point Protocol
inet addr:192.168.1.1 P-t-P:192.168.1.2 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:296 errors:1 dropped:0 overruns:0 frame:0
TX packets:35 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:29380 (28.6 Kb) TX bytes:10915 (10.6 Kb)

>
> Where here, You can choose whether You match the source address
> "-s 192.168.1.2" of the peer or the interface "-i ppp0" that those
> packets arrive on, since that is essentially the same box.

Doesn't like the "-i ppp0" at all with your suggested command above so far.
And it hasn't been too happy with 192.168.1.2 either.

>
>
> HTH, else let me know, Jack.
>


I really do appreciate your assistance and patience, this "should be" very
easy. But, it's been trial-and-error and a head-banger for me the whole
dad-gum way.

Luther

On Fri, 03 Oct 2003 13:30:21 -0400,
martin02 <(E-Mail Removed)> wrote:
>
> Output of "ifconfig" with PPPD running
> ====================================
> eth0 Link encap:Ethernet HWaddr 00:E0:18:7E:71:55
> inet addr:192.168.0.133 Bcast:192.168.0.255 Mask:255.255.255.0
> UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:2866 errors:0 dropped:0 overruns:0 frame:0
> TX packets:3232 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:100
> RX bytes:1967241 (1.8 Mb) TX bytes:394822 (385.5 Kb)
> Interrupt:12 Base address:0x4000
>
> lo Link encap:Local Loopback
> inet addr:127.0.0.1 Mask:255.0.0.0
> UP LOOPBACK RUNNING MTU:16436 Metric:1
> RX packets:118 errors:0 dropped:0 overruns:0 frame:0
> TX packets:118 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:7762 (7.5 Kb) TX bytes:7762 (7.5 Kb)
>
> ppp0 Link encap:Point-to-Point Protocol
> inet addr:192.168.1.1 P-t-P:192.168.1.2 Mask:255.255.255.255
> UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
> RX packets:296 errors:1 dropped:0 overruns:0 frame:0
> TX packets:35 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:3
> RX bytes:29380 (28.6 Kb) TX bytes:10915 (10.6 Kb)
>

You can double check, but I think 192.168.x.x subnet is all set aside
for local use. Were you given inet addr and P-t-P ips, or did you
select them yourself?

Just checked,

http://www.faqs.org/rfcs/rfc1918.html

You either need to use DHCP, or get information from your ISP on the
correct IPs to use. Unless you're verisign.com you probably can't pick
your external ip; if you could it might work best to pick one that is
routed over the internet. (I've read instructions somewhere about assigning
temporary IPs that will be replaced by DHCP, which looks like what you
might have done, just didn't get the DHCP part quite right.)

Michael C.
--
(E-Mail Removed) http://mcsuper5.freeshell.org/
Registered Linux User #303915 http://counter.li.org/

martin02 wrote:

OK, the changes You made seem to be correct so far. The trouble You
have now comes from Your routing and iptables setup:


> Changed this to 192.168.1.1:192.168.1.2

Good.


>>>PPPD - Setup "ip-up.local" file. Currently disabled because there is
>>>already a default route that keeps getting recreated to the D-Link
>>>gateway and the packets sent from ppp0 were getting re-routed backwards
>>>back into ppp0 where they came from.
>>> /sbin/route add default $1
>
> Not sure if I am adding a route to ppp0 correctly. Reactivated ip-up.local
> file and changed to the following:
>
> /sbin/route add -host 192.168.1.2 dev ppp0
> /sbin/route add -net 192.168.1.1**
> echo 1 > /proc/sys/net/ipv4/ip_forward
> echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp
>
> ** Added the "net" entry because the route entry by itself didn't work. But
> this made no difference. Probably should delete the entry.
>
> The new route does show up in the "route -n" listing once the ppp0
> connection has been established.
>
> Destination Gateway Genmask Flags Metric Ref Use
> Iface
> 192.168.1.2 0.0.0.0. 255.255.255.0 U 0 0 0 ppp0
> 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
> 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
> 0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0

The first entry here should have a mask of 255.255.255.255, and thus
the flags should read "UH". But this doesn't really change the functio-
nality. Your routing table is correct and should work.


>>On the client that You dial-in from, set 192.168.1.1 (the remote server)
>>as default gateway.
>
>
> Not possible with the Win98 PPPD Client. PPPD needs to assign the default
> gateway to the Win98 client. Apparently, there is no way to do this from
> inside PPPD as best I can tell.

Normally, this should be just ok. I'm not too familiar with Win*, but if
it dials into something, the routing should be using the peer as a gate-
way.


>>iptables -t nat -I POSTROUTING -s 192.168.1.2 -o eth0 -j MASQUERADE
>
> Installed iptables.
>
> Your suggested MASQ line above doesn't work by itself. Keeps getting
> "iptables:target error" even with or without the PPPD client up and
> running.

If You get that error, it might have the following reason: In Your
off-the-shelf kernel, normally the matches and targets for iptables
are compiled in properly. Sometimes, they are compiled as modules.
So if You "lsmod", You should see modules with names like "ip_tables*",
"ipt_*" and the like.


> Manually ran this sequence trying to get your line to be accepted:
> modprobe iptable_nat
> iptables -P INPUT ACCEPT
> iptables -F INPUT
> iptables -P OUTPUT ACCEPT
> iptables -F OUTPUT
> iptables -P FORWARD DROP
> iptables -F FORWARD
> iptables -t nat -F
> iptables -A FORWARD -i eth0 -o ppp0 -m state --state ESTABLISHED,RELATED -j
> ACCEPT
> iptables -A FORWARD -i ppp0 -o eth0 -j ACCEPT
> iptables -A FORWARD -j LOG
>
> Then tried different variations of SNAT/MASQURADE, all result in some sort
> of iptables error message:
> iptables -t nat -I POSTROUTING -s 192.168.1.2 -o eth0 -j MASQUERADE
> iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
> iptables -t nat -A POSTROUTING -o eth0 -j SNAT
> iptables -t nat -I POSTROUTING -s 192.168.1.2 -o eth0 -j MASQUERADE

As said, see whether these targets ("MASQUERADE", "SNAT") are available
in Your kernel.


> It won't take any variation of NAT entry for some reason.
>
> I would have thought that "iptables -L nat" would have generated something,
> but it doesn't like that command either.

You forgot the "-t" switch: "iptables -L -t nat" should do the trick,
again as long as the nat table is available.


> Maybe I need some POSTROUTING pre-configuration commands up at the beginning
> of setting up the inital iptables configuration. Something like:
> iptables -P POSTROUTING ACCEPT
> iptables -F POSTROUTING
>
> Just guessing here.
>
> ===============================
> Current output of "iptables -L"
> ===============================
> Chain INPUT (policy ACCEPT)
> target prot opt source destination
>
> Chain FORWARD (policy DROP)
> target prot opt source destination
> ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
> ACCEPT all -- anywhere anywhere
> LOG all -- anywhere anywhere LOG level warning
>
> Chain OUTPUT (policy ACCEPT)
> target prot opt source destination
>
> I don't see a "Chain POSTROUTING" entry. Perhaps I didn't pre-configure it
> first. My guess is that I haven't sucessfully created a POSTROUTING chain
> yet.

Yes and no: "iptables -L" will list the filter table. To list the nat
table with its PREROUTING, POSTROUTING and OUTPUT chains, You need to
add "-t nat" to specify the table to be listed.

In /var/log/messages, You should see some sort of information like:
"iptables: No such table. - Do You need to insmod?"
This would tell You clearly that Your kernel isn't prepared to use
the nat table.


> ====================================
> Output of "ifconfig" with PPPD running
> ====================================
> eth0 Link encap:Ethernet HWaddr 00:E0:18:7E:71:55
> inet addr:192.168.0.133 Bcast:192.168.0.255 Mask:255.255.255.0
> UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:2866 errors:0 dropped:0 overruns:0 frame:0
> TX packets:3232 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:100
> RX bytes:1967241 (1.8 Mb) TX bytes:394822 (385.5 Kb)
> Interrupt:12 Base address:0x4000
>
> lo Link encap:Local Loopback
> inet addr:127.0.0.1 Mask:255.0.0.0
> UP LOOPBACK RUNNING MTU:16436 Metric:1
> RX packets:118 errors:0 dropped:0 overruns:0 frame:0
> TX packets:118 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:7762 (7.5 Kb) TX bytes:7762 (7.5 Kb)
>
> ppp0 Link encap:Point-to-Point Protocol
> inet addr:192.168.1.1 P-t-P:192.168.1.2 Mask:255.255.255.255
> UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
> RX packets:296 errors:1 dropped:0 overruns:0 frame:0
> TX packets:35 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:3
> RX bytes:29380 (28.6 Kb) TX bytes:10915 (10.6 Kb)
>
>
>>Where here, You can choose whether You match the source address
>>"-s 192.168.1.2" of the peer or the interface "-i ppp0" that those
>>packets arrive on, since that is essentially the same box.
>
>
> Doesn't like the "-i ppp0" at all with your suggested command above so far.
> And it hasn't been too happy with 192.168.1.2 either.

OK, the ifconfig information is exactly what You want. This last sen-
tence above goes for the nat table, I assume, because in the filter
table, above, it seems to work with ppp0.

Well, please check Your kernel configuration for nat table support.
Then, try to set the policy of Your FORWARD chain to accept (for
testing, You can later adjust it to Your specific needs). This
should make the httpd of that D-Link accessible for the remote end
of the ppp connection even without masquerading (unless the D-Link
does only accept requests from its own subnet, 192.168.0/24).

I think You're close to the solution of this.


Cheers, Jack.

--
----------------------------------------------------------------------
My personal reading of the string "MicroSoft" expands to "NanoWeak"...

Michael C. wrote:

<<<snip>>>
>
> You can double check, but I think 192.168.x.x subnet is all set aside
> for local use. Were you given inet addr and P-t-P ips, or did you
> select them yourself?
>
> Just checked,
>
> http://www.faqs.org/rfcs/rfc1918.html
>
> You either need to use DHCP, or get information from your ISP on the
> correct IPs to use. Unless you're verisign.com you probably can't pick
> your external ip; if you could it might work best to pick one that is
> routed over the internet. (I've read instructions somewhere about
> assigning temporary IPs that will be replaced by DHCP, which looks like
> what you might have done, just didn't get the DHCP part quite right.)
>
> Michael C.


Yes, you are correct. but your missing how net network is currently built.
I am using PPPD in the opposite direction from the norm.

Internet
|
V
D-Link router - Public IP assigned by DHCP via the ISP
|
V
Local LAN - Private IP addresses assigned by the D-Link router all in the
192.168.0.0 net
|
V
Linux PPPD server - Which is part of the above local LAN. Its eth0 IP is
192.168.0.133
|
V
PPPD Client via dial-in. IP address assigned by the PPPD server above as
198.168.1.2 currently.

The PPPD client is 2 networks away from the actual internet.

The problem is routing, NAT or MASQ. Packets go out, but not all packet
types the are not routed back to the to the PPPD client by the PPPD Server.

The odd thing is that I can ping out from ppp0 to the local LAN IPs and
recieve replies, but when trying to access those same address via a
browser, I can pull the web pages from the PPPD server
(http://192.168.0.133), but it times out on the D-Link's web server
(http://192.168.0.1).

I can also ping internet addresses. I can see those go out from the PPPD
server, through the D-Link router, replies come back in through the D-Link
router all the way back to the PPPD server. But the PPPD server apparently
just discards them and does not route them back to the PPPD client.

Its puzzling that local LAN pings are routed back to ppp0, but web and DNS
requests are not.

Thank you very much for replying and trying to be helpful though.

Luther

On Sat, 04 Oct 2003 10:52:12 -0400,
martin02 <(E-Mail Removed)> wrote:
> Michael C. wrote:
> >
> > Just checked,
> >
> > http://www.faqs.org/rfcs/rfc1918.html
> >
> > You either need to use DHCP, or get information from your ISP on the
> > correct IPs to use. Unless you're verisign.com you probably can't pick
> > your external ip; if you could it might work best to pick one that is
[snip]
>
> Thank you very much for replying and trying to be helpful though.
>
> Luther
>
>
I realized you were running the server about 3 seconds after I posted,
and sent a cancel message. Unfortunately cancel isn't universally
accepted due to abuse in the past. I've gone through trouble
connecting, serving incoming connections is still beyond me.

Michael C.
--
(E-Mail Removed) http://mcsuper5.freeshell.org/
Registered Linux User #303915 http://counter.li.org/