Re: Wrong remote IP, bug or feature?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 9/29/2013 6:08 AM, Lars Mueller wrote:


Another poster suggested "ipcp-accept-remote."  I don't believe that
answer to be correct.  That option actually *allows* the peer to
change the address.  The default is that if the address is specified,
then the peer cannot change it, but can refuse it outright.

The usual way to specify a required IP address is via the
/etc/ppp/chap-secrets file.  For example:

remoteuser * userpassword ip.user.com

where "remoteuser" is the remote user's name, "userpassword" is the
user's password or quoted passphrase, and "ip.user.com" is a symbolic
or numeric (dotted quad) IP address.  The IP addresses allowed for a
given peer can be specified as a space separated list, prefixed with
"!" to exclude an address, or as a subnet range n.n.n.n/m.  The range
form can optionally include a "+" sign to indicate that the local
device unit number (the "X" in "pppX") plus 1 is added to the address,
so each user gets a unique address within the specified range.  A
typical configuration on an access server looks like:

joeuser * "Joe's Passphrase" 10.14.15.1/24

You can also include special pppd options to apply to a given peer by
appending "--" and then the options desired.  Obviously, as you must
get through both LCP and authentication to get to the point of setting
those options, the only useful options here are ones that apply to the
NCPs (e.g., "novj").

See the pppd man page for details.  There's a lot you can control
here.  If you want to get really fancy, you can write your own plug-in
for pppd that sets the allowed_address_hook pointer, and you can do
any arbitrary sort of validation you like there.

One caveat: I know pppd well, but I don't know squat about pptpd.  The
options it provides look a little odd to me, given that the normal way
to restrict IP address selection is with the authentication files.

Another caveat: the restrictions here necessarily apply ONLY to the
address negotiated and then configured on the local IP interface.
There's no way you can ever "force" a peer to use any particular
address, no matter how much you may want to.  At best, the addresses
negotiated constitute advice to the peer.  You can do slightly better
by setting up packet filters to get rid of "spoofed" source addresses
- -- using, of course, your own configuration data and not bits supplied
by the (untrusted?) peer.  Of course, doing so will break many
multi-homed systems and simple load balancing schemes, so it's up to
you to determine how much to inconvenience the user.

About the options you have configured:



This one may be a mistake.  It's possible you may need this if the
peer has known implementation bugs, but I strongly suggest omitting
this first and setting it *only* if absolutely required for a broken peer.

I doubt it's needed here, as the AHDLC "peer" is entirely internal to
the pptp implementation.  If the "peer" is broken, it means that your
local pptpd is broken.



This is very likely wrong for an access server.  You don't want to
treat your remote user as your default route to connect to the
Internet, do you?  Ordinarily, a remote user connecting to an access
server doesn't play the role of default route.

If you were hoping that this option would *supply* a default route to
the peer, it does not.  There's (quite intentionally) no way to do
that in PPP.



That combination is a little weird.  You're telling pppd to use an MRU
that's less than the default of 1500 but also not to bother telling
the peer about the restriction.  I don't think that makes sense.  I
suggest setting *either* "mru 1450" if you really want the peer to
send smaller packets (by telling it to do so) *or* setting just
"default-mru" if you don't want to tell the peer anything about the
MRU setting (allowing it to assume whatever it wants), and not both.



These probably don't do what you expect.  All of the "refuse-*"
authentication options control the how the local system (i.e., this
access server) identifies itself to its peer.  By specifying these,
you're saying that you don't want to use any of those protocols if the
peer demands authentication from you.

But the remote system isn't going to do that, and if it did, it
wouldn't find any compatible secrets in any of the /etc/ppp/*-secrets
files, so what you're specifying here is actually already the default.



That doesn't seem useful on a virtual link, such as pptp.  The point
of the "lock" option is to control access to a physical serial port
that might be used for both dial-in and dial-out access.  The UUCP
lock file provides a way that applications can detect that the serial
port is in use, and either wait for it to become idle or return an
error to the user.  Clearly, physical serial ports are not in use
here.  See the man page for details.



No need to specify both of these; "novj" is more than enough.  If
you're going to do this, I'd suggest adding "nopcomp" and "noaccomp"
as well.  Those options mean something for a serial link, but not much
for a virtual link.



That's not really needed.  You're not logging on stdout here.  I
suppose it's harmless, although I do recommend that specifying as
*FEW* options as possible (and accepting the default for the rest) is
really the right way to go.  The code is written so that good defaults
are intentionally chosen.  As new options are added (and old ones
retired), you don't want to be put in the position of playing "catch
up" with each change.

Finally, note that for the "proxyarp" function to work here, you're
going to need an Ethernet (or other broadcast-type) interface
configured with an IP address somewhere in the 10.14.15.0/24 range
(perhaps .1?).  If you don't have that, then the option will be ignored.

- -- 
James Carlson         42.703N 71.076W         <carlsonj@xxxxxxxxxxxxxxx>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)

iEYEARECAAYFAlJIpLIACgkQ6TIHA1NkzvD/nACdF3kT3pc5aFeXv9lhtJvhDsQy
+AUAni5cFLmYiOXtLJ5ZMMQVF+q4/HCT
=/3+k
-----END PGP SIGNATURE-----
--
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Audio Users]     [Linux for Hams]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Fedora Users]

  Powered by Linux