mpd configure and route issues

• Previous message: Jilles Tjoelker: "Re: Opieaccess file, is this normal?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

To: <freebsd-security@freebsd.org>
Date: Fri, 25 Jun 2004 14:06:36 -0400

I have searched google high and low for answers to this...and I have gotten
many examples, howto, etc...but they all seem to have a slightly different
configuration, and therefore, slightly different problems. Unfortunately,
not enough of them show the network layout, along with the configuration, so
it's hard to tell why certain IP are being used, and were they are on the
network. I have what could be considered a fairly standard setup, and I'll
bet an easy fix, but I'm just missing something.

I have a single FreeBSD box that I'm setting up as a firewall / gateway /
vpn for test purposes.

External network: x.x.0.208/28
Internal network: y.y.1.0/24

FreeBSD 4.10-STABLE - mpd 3.19
Internal: fxp0: inet y.y.1.1 netmask 0xffffff00 broadcast y.y.1.255
External: dc0: inet x.x.0.222 netmask 0xfffffff0 broadcast x.x.0.223

Without any mpd stuff started:
Destination Gateway Flags Refs Use Netif Expire
default x.x.0.209 UGSc 2 15 dc0
x.x.0.208/28 link#2 UC 1 0 dc0
x.x.0.209 00:00:c5:94:ba:48 UHLW 3 0 dc0 1194
localhost localhost UH 0 0 lo0
y.y.1 link#1 UC 0 0 fxp0

Running ipfilter and ipnat, both of which work great. I have a rule set,
but for testing purposes here, until I get this working, I do a pass in/out
quick on all interfaces. ip.forward is on, and NAT is working. So as a
firewall and gateway, I'm good, just no joy with the VPN yet.

I will leave off most of the extra information about
auth/crypt/compress/etc...since that whole part appears to be working just
fine, I'm able to connect and authenticate. Also, for simplicity sake,
assume just one VPN connection, if I get this working, I can see from the
examples how to setup the rest.

My first main question is in regards to putting the internal VPN connections
in the same subnet as the existing internal LAN. Some people seem to, some
don't. Either would be fine by me, but neither appears to work. The
majority appear to just put the incoming IPs right in a range on their
existing subnet, so I would assume that to be the standard method. So,
let's say I want to put my incoming client at y.y.1.5, put this in my
config:

set ipcp ranges y.y.1.1/32 y.y.2.5/32

Now, y.y.1.1 is already the existing IP of this machine internally, and is
now also going to be the termination point for the tunnel. Is this normal?
It would appear to me that this could create conflict in routing. I tried
making it y.y.1.2/32, no luck. Also, I wanted to make sure my external IP
is in the right place, which it apepars to be, this part is working, I'm
able to connect externally:

set pptp self x.x.0.222

So with things setup this way, I fire it up, no errors:

Jun 25 13:46:46 <daemon.info> cap mpd: [pptp0] ppp node is "mpd142-pptp0"
Jun 25 13:46:46 <daemon.info> cap mpd: mpd: local IP address for PPTP is
x.x.0.222
Jun 25 13:46:46 <daemon.info> cap mpd: [pptp0] using interface ng0

And as I would expect, ifconfig now shows the new netgraph interface, there
are no changes to the routing table.

ng0: flags=8890<POINTOPOINT,NOARP,SIMPLEX,MULTICAST> mtu 1500

I then connect my client, after all the authentication goes by without
error, it leaves with:

Jun 25 13:48:47 <daemon.info> cap mpd: [pptp0] IPCP: LayerUp
Jun 25 13:48:47 <daemon.info> cap mpd: y.y.1.1 -> y.y.1.5
Jun 25 13:48:47 <daemon.info> cap mpd: [pptp0] IFACE: Up event
Jun 25 13:48:47 <daemon.info> cap mpd: [pptp0] setting interface ng0 MTU to
1196 bytes
Jun 25 13:48:47 <daemon.info> cap mpd: [pptp0] exec: /sbin/ifconfig ng0
y.y.1.1 y.y.1.5 netmask 0xffffffff -link0
Jun 25 13:48:47 <daemon.info> cap mpd: [pptp0] exec: /sbin/route add
y.y.1.1 -iface lo0
Jun 25 13:48:47 <daemon.info> cap mpd: [pptp0] IFACE: Up event

And my route table now has this added on:

y.y.1.1 lo0 UHS 0 0 lo0
y.y.1.5 192.168.1.1 UH 0 0 ng0

and ifconfig gives me:
        inet y.y.1.1 --> y.y.1.5 netmask 0xffffffff

The first thing that jumps out at me here...lo0 as the interface!?!? That
seems strange, but I don't see how to control this.

>From my client, I can ping y.y.1.5, but not y.y.1.1, so it's not getting
anything back from the other end of the tunnel.

And from the server, I can of course still ping y.y.1.1, but not y.y.1.5, it
gives: ping: sendto: No route to host.

Now, this all seems to make sense to me, as to why it's doing what it's
doing. But I don't know how to tell it to do what I want! I have played
around with static routes and the arp proxy stuff, to no avail. I have
tried moving the VPN clients to a different internal subnet, y.y.2.0/24, and
got different results, but pretty much what I would have expected.

Any help in this matter would be GREATLY appreciated!

-Daniel

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

• Previous message: Jilles Tjoelker: "Re: Opieaccess file, is this normal?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]