Re: Connecting subnet over PPP

From: Willie Viljoen (will_at_unfoldings.net)
Date: 11/20/03

  • Next message: chael_at_southgate.ph.inter.net: "FreeBSD beside WinXP" 
    To: "Colin Watson" <sb.mailinglist@lambdabroadband.com>, <freebsd-questions@FreeBSD.ORG>, <freebsd-net@freebsd.org>
Date: Thu, 20 Nov 2003 08:31:28 +0200

    If you are seeing ARP requests for a subnet which is routed, it is more than
    likely that some router somewhere doesn't know it is routed. ARP requests
    are only sent when a system is trying to contact an IP address *it* believes
    to be on the same physical network as itself. Make sure routers on your side
    (before the FreeBSD box) know to route that subnet via the BSD box. Also,
    make sure the subnet mask on the D-Link router at the client side is
    configured correctly.

    If all else fails, you might want to try doing proxyarp with pppoed, this is
    problematic at best though, and should not be used if there is a router on
    the other side, only if clients are routing directly via your pppoed, and if
    the addresses are actually on a physical network on your side, and to be
    "mirrored" to them. This is the wrong way to do it, but it is supported, as
    many ISPs did this in the past... it was the only way to do it with Windows
    NT RAS servers.

    Will
    ----- Original Message -----
    From: "Colin Watson" <sb.mailinglist@lambdabroadband.com>
    To: <freebsd-questions@FreeBSD.ORG>; <freebsd-net@freebsd.org>
    Sent: Thursday, November 20, 2003 3:08 AM
    Subject: Connecting subnet over PPP

    > Hi,
    > I am using the userland ppp with pppoe daemon to setup a pppoe server
    to
    > authenticate incoming clients. I want to route a /29 subnet
    (81.19.79.24/29)
    > to a client. Now I authenticate via a radius server, which frames the IP,
    > Protocol, and route attributes:
    >
    > Framed-Protocol = PPP
    > Framed-IP-Address = 81.19.79.25
    > Framed-Route = 81.19.79.24/29 81.19.79.25 1
    >
    > This appears to assign the connection without problem, and the machines on
    > the clients side of the network, when assigned one of the subnet's IP's
    have
    > no issue pinging out to all hosts. However, when a remote PC attempts to
    > access one of the public IP's - i.e. ping it - this fails. The FreeBSD
    > Gateway / PPPoE Server shows lots of ARP unable to resolve messages - I
    > presume this means it cannot find a mac address for the client. I have
    > checked the routing table - netstat -ran, and an entry is created for the
    > subnet in question (via the returned radius attributes):
    >
    > Internet Dest: Gateway: Flags: Refs: Use: Netif: Expire:
    >
    > 81.19.79.24/29 81.19.79.25 UGSc 1 147 tun0
    > 81.19.79.25 81.19.78.1 UH 0 256 tun0
    > 81.19.79.25 00:05:5b:71.. UHLS2 0 0 ste1
    >
    > A tcpdump of 'ste0' (the PPPoE Daemon Interface) from an IP the clients
    > subnet pinging out, shows that the replies are occuring:
    >
    > 17:29:28.984831 PPPoE [ses 0x1b] 81.19.79.25 > 81.19.79.34: icmp: echo
    > request
    > 17:29:28.984831 PPPoE [ses 0x1b] 81.19.79.34 > 81.19.79.25: icmp: echo
    reply
    >
    > However, if this role is reversed, and a remote IP - in this case
    > 81.19.79.34 (on a different /27 (32->63) network) attempts to ping a PC on
    > the client network:
    >
    > 17:37:45.214386 PPPoE [ses 0x1b] 81.19.79.34 > 81.19.79.25: icmp: echo
    > request
    > 17:37:45.221413 PPPoE [ses 0x1b] 81.19.79.34 > 81.19.79.25: icmp: echo
    > request
    > 17:37:45.223422 PPPoE [ses 0x1b] 81.19.79.34 > 81.19.79.25: icmp: echo
    > request
    > 17:37:45.321455 PPPoE [ses 0x1b] 81.19.79.34 > 81.19.79.25: icmp: echo
    > request
    > 17:37:45.623212 PPPoE [ses 0x1b] 81.19.79.34 > 81.19.79.25: icmp: echo
    > request
    >
    > The client uses a D-Link Router which is set to allow all traffic - It is
    of
    > course possible this is misconfigured, however I would like to know if
    this
    > configuration *should* be working, or if I have made some grevious error
    > somewhere, which is preventing the traffic reaching the clients network.
    >
    > Many Thanks
    >
    > Colin Watson.
    >
    >
    >
    >
    > _______________________________________________
    > freebsd-net@freebsd.org mailing list
    > http://lists.freebsd.org/mailman/listinfo/freebsd-net
    > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
    >
    >

    _______________________________________________
    freebsd-questions@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-questions
    To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org"

  • Next message: chael_at_southgate.ph.inter.net: "FreeBSD beside WinXP"

    Relevant Pages

    • RE: RWW Issues w/SBS2003
      ... I reconfigured the routers on the LAN, placing them on the same subnet. ... This fixed the RWW connect to clients/server issues, ... From your description, we know, the issue relate to the router between ... please connect a client on the subnet A with the same ...
      (microsoft.public.windows.server.sbs)
    • Server in a NAT subet?
      ... connection from outside the subnet to a node in the subnet. ... Basically, the router is what it says on the tin, an IP router? ... server somewhere on the internet: ... The client in the subnet opens a TCP connection to the server,eg, ...
      (comp.os.linux.networking)
    • Re: Troubles with DHCP when using wireless access
      ... You need to configure BOOTP/client on the router giving the ... IP Helper (or DHCP server) address as 192.168.1.10 ... > connecting to a subnet with IPs in the 192.168.1.xxx range. ...
      (microsoft.public.windows.server.networking)
    • Re: Connecting subnet over PPP
      ... If you are seeing ARP requests for a subnet which is routed, ... likely that some router somewhere doesn't know it is routed. ... make sure the subnet mask on the D-Link router at the client side is ...
      (freebsd-net)
    • Re: NAT tables chains
      ... > By sayin returnin packets I mean packets that originated from the LAN ... > hosts due to its request to a remote service thru the router. ... Your client makes a request to your router since it is responsible ...
      (comp.os.linux.networking)