Re: Connecting subnet over PPP
From: Colin Watson (sb.mailinglist_at_lambdabroadband.com)
Date: 11/20/03
- Previous message: Alexander Motin: "dummynet & IP fragmentation bug"
- In reply to: Willie Viljoen: "Re: Connecting subnet over PPP"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
To: "Willie Viljoen" <will@unfoldings.net> Date: Thu, 20 Nov 2003 14:29:25 -0000
As I understand it, proxy ARP answers ARP requests on behalf of the
connected parties - Thus ensuring the PPPoE box collates all traffic from
foreign hosts? I have already implemented proxyarp option in ppp, assuming
that it would be necessary for all traffic to be directed to the PPPoE
server, where it would then decide which tun(nel) interface to stuff it
down? - Why is this problematic exactly? Surely, the world will shift
traffic to the PPPoE box, that will then look up the routing table to
determine how to reach the subnet that is asked for (e.g a /29 of a /24
address block)? Could you explain why this is wrong, and an incorrect way to
do it? Not sure I've fully grasped the bad points of PPPoE. And do most
ISP's not do it in this way these days then? Is there another way DSL ISP's
provide their clients with routed IP ranges over PPPoA/PPPoE ?
Many Thanks
Colin.
----- Original Message -----
From: "Willie Viljoen" <will@unfoldings.net>
To: "Colin Watson" <sb.mailinglist@lambdabroadband.com>;
<freebsd-questions@FreeBSD.ORG>; <freebsd-net@freebsd.org>
Sent: Thursday, November 20, 2003 6:31 AM
Subject: Re: Connecting subnet over PPP
> 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-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-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
- Previous message: Alexander Motin: "dummynet & IP fragmentation bug"
- In reply to: Willie Viljoen: "Re: Connecting subnet over PPP"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
