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

Discussion in 'Linux Networking' started by martin02, Sep 29, 2003.

  1. martin02

    martin02 Guest

    Hello Everyone.

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

    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

    martin02, Sep 29, 2003
    1. Advertisements

  2. martin02

    jack Guest

    Try sending some information about Your routing and packet filtering

    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, Sep 29, 2003
    1. Advertisements

  3. martin02

    martin02 Guest


    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.

    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.

    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.>
    asyncmap 0
    ms-dns <IP address to ISP DNS1>
    ms-dns <IP address to ISP DNS2>
    refuse-chap <where 1st IP is eth0 and 2nd IP is ppp0>

    PPPD - Added a "options.ttyS0" file.
    ppp0.myhost.net:ppp0 [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

    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.> ppp0.myhost.net 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
    route add -host dev eth0
    martin02, Sep 30, 2003
  4. martin02

    martin02 Guest

    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.

    martin02, Sep 30, 2003
  5. martin02

    jack Guest

    Unfortunally, I am not familiar with the Mandrake distribution.

    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:
    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).

    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
    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
    via ppp0.
    On the client that You dial-in from, set (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 -o eth0 -j MASQUERADE

    Where here, You can choose whether You match the source address
    "-s" 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.
    jack, Oct 1, 2003
  6. martin02

    martin02 Guest

    My comments interspersed below. Luther

    jack wrote:

    Changed this to

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

    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 dev ppp0
    /sbin/route add -net**
    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 U 0 0 0 ppp0 U 0 0 0 eth0 U 0 0 0 lo UG 0 0 0 eth0

    Changed to: ppp0.myhost.net mydialin.myhost.net
    Moved these 2 entires into ip-up.local
    Stopped using this entry
    Changed to "route add -host dev ppp0" and moved into ip-up.local
    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
    PPPD server is (for eth0)

    I stopped using the "ifconfig eth0:0 192.168.x.x" command.
    Did this. See my changes to ip-up.local, pap-secrets and host files above.
    I am not sure I added the route to 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 though. But it will pull up the web server on the PPPD Server
    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.
    Hasn't so far. *sigh*
    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

    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
    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 -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 -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 -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

    Output of "ifconfig" with PPPD running
    eth0 Link encap:Ethernet HWaddr 00:E0:18:7E:71:55
    inet addr: Bcast: Mask:
    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: Mask:
    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: P-t-P: Mask:
    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)
    Doesn't like the "-i ppp0" at all with your suggested command above so far.
    And it hasn't been too happy with either. :(

    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.

    martin02, Oct 3, 2003
  7. martin02

    Michael C. Guest

    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,


    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.
    Michael C., Oct 4, 2003
  8. martin02

    jack Guest

    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:

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

    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-

    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.

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

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

    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.

    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.
    jack, Oct 4, 2003
  9. martin02

    martin02 Guest

    Michael C. wrote:

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

    D-Link router - Public IP assigned by DHCP via the ISP
    Local LAN - Private IP addresses assigned by the D-Link router all in the net
    Linux PPPD server - Which is part of the above local LAN. Its eth0 IP is
    PPPD Client via dial-in. IP address assigned by the PPPD server above as 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
    (, but it times out on the D-Link's web server

    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.

    martin02, Oct 4, 2003
  10. martin02

    Michael C. Guest

    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.
    Michael C., Oct 4, 2003
  11. Much better! Try adding the line

    /sbin/route add gw $1

    to /etc/ppp/ip-up (or ip-up.local for some distributions that use that
    oddity) on the "server," assuming the server's IP address for the PPP
    interface is still (which it should be).

    No guarantee, I haven't ever done this with a PPP interface.
    Clifford Kite, Oct 4, 2003
  12. martin02

    martin02 Guest

    No problem. Most everything I post is/was/will be has a least one mistake
    of some sort in it (and that is being conservative). ;)

    But thank you again for at least giving it some thought.

    martin02, Oct 4, 2003
  13. Sifting back through the thread, it looks like this has already
    effectively been tried and it failed. You said in one post, where
    the client PPP IP address was changed to, that you
    couldn't access the router web server. Could you access it with the client IP address you started with? If so then you
    can try changing the client IP address back to that and using it in
    place of above.

    I think that whether even that will work is problematical and even
    more problematical if it does work that it will continue to do so.
    It will depend on the range of IP addresses you are
    allowed to use. If you can only use the 133 one for the "server"
    then it isn't likely to work.

    If you have a small subnet alloted to you then assigning a second IP
    address in that subnet to the PPP client should work. Otherwise the
    only solution I can see would be to set up SNAT for the client on the
    server through, and then you should be able to use any
    private IP address (except for the client.
    Clifford Kite, Oct 4, 2003
  14. martin02

    martin02 Guest

    I got knocked back to square 1 a bunch of times and doubled back to re-map
    where pings can go and where they can not go.

    More is going on here than a simple routing or nat problem.

    PPPD client can ping and recieve replies to/from:
    itself -
    the pppd server IP -
    PPPD server eth0 -
    D-Link router -

    PPPD client does not recieve pings back from:
    Another local D-Link LAN client - why????

    PPPD Server can ping and recieve replies to/from:
    itself eth0 -
    PPPD server IP address -
    D-Link router -
    Another LAN client -
    any internet address via Dlink router

    PPPD Server can ping, but does not recieve replies from:
    PPPD Client - why???? The client never sent any replies back
    through If it did reply, I have no idea where it sent them.

    ** the imcp echo request do make it to the PPPD client verified by tracking
    tcpdump -i ppp0 and by observing traffic at the Client, but he PPPD client
    does not respond to them. What the....????

    Been throwing stuff at this problem just to see if I can get it to do
    "anything different" at all.

    I've even added a echo command for ip-up.local:
    echo 1 > /proc/sys/net/ipv4/conf/ppp0/proxy_arp
    I noticed that the "/proc/..../ppp0/" entry will show up once pppd is up and

    Here is route -n:
    Destination Gateway Genmask Flags Metric Ref Use
    Iface UGH 0 0 0 eth0 UGH 0 0 0 ppp0 UH 0 0 0 ppp0 U 0 0 0 eth0 U 0 0 0 lo UG 0 0 0 eth0

    Here is ARP -n:
    Address HWtype HWaddress Flags Mask Iface ether 00:40:2B:13:65:14 C eth0 ether 00:05:5D:21:86:A2 C eth0 * * MP ppp0 * * MP ppp0

    Here is ifconfig:
    eth0 Link encap:Ethernet HWaddr 00:E0:18:7E:71:55
    inet addr: Bcast: Mask:
    RX packets:3531 errors:0 dropped:0 overruns:0 frame:0
    TX packets:5651 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:100
    RX bytes:1729403 (1.6 Mb) TX bytes:774258 (756.1 Kb)
    Interrupt:12 Base address:0x3000

    lo Link encap:Local Loopback
    inet addr: Mask:
    UP LOOPBACK RUNNING MTU:16436 Metric:1
    RX packets:1243 errors:0 dropped:0 overruns:0 frame:0
    TX packets:1243 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:265128 (258.9 Kb) TX bytes:265128 (258.9 Kb)

    ppp0 Link encap:point-to-Point Protocol
    inet addr: P-t-P: Mask:
    RX packets:454 errors:0 dropped:0 overruns:0 frame:0
    TX packets:47 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:3
    RX bytes:43065 (42.0 Kb) TX bytes:3545 (3.4 Kb)

    tcpdump -i ppp0 while being pinged from the PPPD server:
    16:15:02.851780 > icmp: echo request (DF)
    16:15:03.868084 > icmp: echo request (DF)
    16:15:04.868055 > icmp: echo request (DF)
    16:15:05.868092 > icmp: echo request (DF)
    16:15:06.868245 > icmp: echo request (DF)
    16:15:07.868241 > icmp: echo request (DF)
    16:15:08.868245 > icmp: echo request (DF)
    16:15:09.868273 > icmp: echo request (DF)
    16:15:10.868277 > icmp: echo request (DF)
    16:15:11.868250 > icmp: echo request (DF)
    16:15:12.868243 > icmp: echo request (DF)

    PPP version: 2.4.1-9mdk

    martin02, Oct 5, 2003
  15. martin02

    martin02 Guest

    jack wrote:

    Why is there a "NOARP" entry in here for ppp0?

    Would it be useful to figure out how to turn it on?
    Sorry, just scratching my behind (the smart end).

    Thanks, Luther
    martin02, Oct 5, 2003
  16. martin02

    martin02 Guest

    Adding additional gateways has no effect.
    I do have other devices on the local LAN ( but I can be pretty
    much whatever I was IP-wise in this range, with exceptions. (IP's already
    addigned to other computers on the local LAN)

    I created a virtual interface (eth0:0) and assigned it to so
    the pppdserver has 2 separate LAN addresses I "could" assing it to. (D-Link DHCP) and (assigned) all devices on the
    local LAN can ping both.

    Well, from what I've read on any HowTo's that were even vaguely related, I
    have mgetty and pppd working 'as advertised'. When the win98 client is
    dialed in and logged on, I can do any normal operation over ppp that you
    could when connected to the internet. BUT!! only at/with the pppdserver
    machine only. No access to anything beyond the PPPD server. With the
    exception that some pings 'beyond' do work. Go figure.

    That puts me into trying to figure out why iptables keeps giving me a
    "invalid argument" or "invalid target" errors for all my attempts to add a
    POSTROUTING chain. See my other thread here titled:
    " iptables - "invalid argument" error ? "

    You wouldn't think that hooking this up would be so head-bangingly fun!

    martin02, Oct 6, 2003
  17. martin02

    jack Guest

    That's strange. But two things: Firstly, does Your masquerading work
    yet? "iptables -L -n -x -v" and the same with "-t nat" should inform
    You about this. If masquerading does not work, Your box
    may not have a route to through Your pppd server.

    Again, strange. You said it's a Win client, but even those should reply
    to ICMP echo requests. Is there some firewalling enabled on that client
    that prevents it from getting such requests via its own dial-up connect-
    ion? -- Perhaps You could try with a linux box as ppp client.

    You needn't do that, so You shouldn't do that. - It is an IP network,
    and the client and D-Link router are on different subnets.

    I assume that this is the routing table of Your pppd server. The first
    entry is wrong. is a local address that sits on ppp0. The
    second entry is redundant.

    Does this pppd server list its own NIC here?

    Again, using ARP with POINTOPOINT is useless. The name of the proto-
    col, "point-to-point", explains all that.

    Again, can it be that those packets are blocked somehow?

    -- Mmmh, I have to go away now; I'll be back by Tuesday (Oct, 07) night
    CEST. - Sorry for that.

    Cheers, Jack.
    jack, Oct 6, 2003
  18. I figured that sub-netting could be byting (sic) you. The DSL TA is
    attached to the server by Ethernet and something is NATing the private
    addresses within some IP range, as evidenced by the fact that it seems
    that some of the other hosts on your LAN can access Internet sites.

    But apparently at least one other host on the LAN can't, so it seems
    here's a subnet assigned to you somewhere. That host had 110 as the last
    octet in it's IP address, which is the last IP address a subnet resulting
    from /28 (14 IP addresses) or smaller sub-netting. The server host ends
    in 113 which is the first host on the subnet above one that includes 110.

    However, saying that subnetting of is causing the problem
    *may* contradict your assertion that

    Local LAN - Private IP addresses assigned by the D-Link router all in
    the net

    but it depends on whether you meant "in the network"
    or not. The "assigned by the D-Link router" bothers me since that
    could mean that the router doles out the IP addresses that it will
    route via DHCP, not unreasonable since there is no sign in your
    posts that PPPoE is directly involved on your side of the router.
    That may mean the IP address assigned to the PPP client is ignored
    by the router.

    *Please note this is all speculation, since I've no experience with
    anything similar to what you have.*

    A straight-forward dial-in to a PPP "server" on a LAN with a subnet
    of routable IP addresses works with proxyarp activated on the server
    LAN interface for the dial-in's IP address (which must belong to the
    LAN subnet) and a default route on the server to an Internet gateway
    on the LAN. This I know because I've done it.
    I was surprised that

    iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

    produced that message. It worked here - without the message - when I
    masqueraded an ISP PPP connection for a host on the same LAN subnet as
    my dial-in host, using iptables version 1.2.6a. Iptables does make my
    head hurt though. :) I started with a firewall/masquerade script off
    the Internet and managed to tailor it to do what I wanted.
    Think of it as "gathering karma."
    Clifford Kite, Oct 6, 2003
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.