|Daniel Goepp||Jun 25, 2004 6:07 pm|
|Subject:||mpd configure and route issues|
|From:||Daniel Goepp (free...@goepp.com)|
|Date:||Jun 25, 2004 6:07:00 pm|
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!