L2TP and PPTP vpn clients connect to the VPN server, no internal networkin

Question

Level 1

8 points

L2TP and PPTP vpn clients connect to the VPN server, no internal networkin

So I have a OS X 10.5.8 VPN server. it is on a real route-able network with a firewall further upstream. I have several client computers but I'll restrict myself to a Macbook pro 10.5.8 for this conversation.

both types of connections (l2tp and pptp) connect and authenticate to the server. both types can not access machines on the lan via the vpn server.

going to an internal webserver gives times, ssh connections to other servers time out. no hint in the client logs (I have the client firewall logging all packets)

basic lay out is main dns is xxx.xxx.242.13 (subnet1, router interface 242.1)
vpn server and 2nd dns server is xxx.xxx.242.130 (subnet2, router interface 242.129)
vpn address range xxx.xxx.242.131 through xxx.xxx.242.136

here's a client connection from the vpnd.log for a l2tp connection (date stamp removed, actually names and numbers obscurred)

2010-01-08 15:10:42 PST Incoming call... Address given to client = xxx.xxx.242.132
Directory Services Authentication plugin initialized
Directory Services Authorization plugin initialized
L2TP incoming call in progress from 'xxx.xxx.41.248'...
L2TP received SCCRQ
L2TP sent SCCRP
L2TP received SCCCN
L2TP received ICRQ
L2TP sent ICRP
L2TP received ICCN
L2TP connection established.
using link 1
Using interface ppp1
Connect: ppp1 <--> socket[34:18]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0x1b57f351> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x5afd4ba7> <pcomp> <accomp>]
lcp_reqci: returning CONFACK.
sent [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x5afd4ba7> <pcomp> <accomp>]
Fri Jan 8 15:10:42 2010 : rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0x1b57f351> <pcomp> <accomp>]
sent [LCP EchoReq id=0x0 magic=0x1b57f351]
sent [CHAP Challenge id=0x12 <ed2ccdfb37378cf70268ff62fe433da0>, name = "VPNservername.FQDN"]
rcvd [LCP EchoReq id=0x0 magic=0x5afd4ba7]
sent [LCP EchoRep id=0x0 magic=0x1b57f351]
rcvd [LCP EchoRep id=0x0 magic=0x5afd4ba7]
rcvd [CHAP Response id=0x12 <ba15b48bbba55ba0dbeb83a847e1a1f600000000000000006dcde615a7a7e08538dc4d00dd851c 195be941d6c763c85b00>, name = "UserName"]
sent [CHAP Success id=0x12 "S=6AB5AFD4706E4CF32F1128709DEBCCC04C28F453 M=Access granted"]
CHAP peer authentication succeeded for UserName
DSAccessControl plugin: User 'UserName' authorized for access
sent [IPCP ConfReq id=0x1 <addr xxx.xxx.242.130>]
sent [ACSCP] 01 01 00 04
rcvd [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
ipcp: returning Configure-NAK
sent [IPCP ConfNak id=0x1 <addr xxx.xxx.242.132> <ms-dns1 xxx.xxx.242.130> <ms-dns3 xxx.xxx.242.13>]
rcvd [ACSCP] 01 01 00 10 01 06 00 00 00 01 02 06 00 00 00 01
sent [ACSCP] 02 01 00 10 01 06 00 00 00 01 02 06 00 00 00 01
rcvd [IPCP ConfAck id=0x1 <addr xxx.xxx.242.130>]
rcvd [ACSCP] 02 01 00 04
sent [ACSP data]
02 00 00 1f 00 0b 00 00 00 00 00 00 00 11 65 61 '..............su'
72 74 68 6b 61 6d 2e 75 63 73 64 2e 65 64 75 'bdomain.domain.edu'
sent [ACSP data]
01 00 00 14 00 0b 00 00 84 ef f2 81 ff ff ff 80 '................'
00 01 00 00 '....'
rcvd [IPCP ConfReq id=0x2 <addr xxx.xxx.242.132> <ms-dns1 xxx.xxx.242.130> <ms-dns3 xxx.xxx.242.13>]
ipcp: returning Configure-ACK
sent [IPCP ConfAck id=0x2 <addr xxx.xxx.242.132> <ms-dns1 xxx.xxx.242.130> <ms-dns3 xxx.xxx.242.13>]
ipcp: up
found interface en0 for proxy arp
local IP address xxx.xxx.242.130
remote IP address xxx.xxx.242.132
rcvd [ACSP data]
02 00 00 08 00 04 00 00 '........'
rcvd [ACSP data]
01 00 00 08 00 04 00 00 '........'

after a l2tp connection is made the client shows:
taz-laptop:~ localcnhn$ ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0 mtu 1280
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ether 00:25:4b:d4:40:7c
media: autoselect status: inactive
supported media: none autoselect 10baseT/UTP <half-duplex> 10baseT/UTP <full-duplex> 10baseT/UTP <full-duplex,flow-control> 10baseT/UTP <full-duplex,hw-loopback> 100baseTX <half-duplex> 100baseTX <full-duplex> 100baseTX <full-duplex,flow-control> 100baseTX <full-duplex,hw-loopback> 1000baseT <full-duplex> 1000baseT <full-duplex,flow-control> 1000baseT <full-duplex,hw-loopback>
fw0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 4078
lladdr 00:25:4b:ff:fe:d4:40:7c
media: autoselect <full-duplex> status: inactive
supported media: autoselect <full-duplex>
en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet6 fe80::226:8ff:fede:3279%en1 prefixlen 64 scopeid 0x6
inet xx2.xx2.41.248 netmask 0xfffff000 broadcast xx2.xx2.47.255
ether 00:26:08:de:32:79
media: autoselect status: active
supported media: autoselect
ppp0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
inet xxx.xxx.242.132 --> xxx.xxx.242.130 netmask 0xffff0000

with the VPN gateway (as seen in System preferences/Networking as being xxx.xxx.242.130 (not the actual lan gateway of xxx.xxx.242.129) and no subnet mask. this might be fine but I don't know VPN structures well enough to comment.

So any thoughts why I can connect (which takes firewall issues out of the way) to the VPN server but can't get internal routing?

other information
the vpn service ->Setting ->client information
Dns Servers
xxx.xxx.242.13
xxx.xxx.242.130
search domains
mysubdomain.domain.edu
network routing definition (this corresponds to the subnet gateway/netmask of a regular client on the subnet as I have it setup)
xxx.xxx.242.129 255.255.255.128 private

macbook pro 13", Mac OS X (10.5.8), lots

Posted on Jan 8, 2010 3:32 PM

Reply

Answer 1

Camelot

Level 9

58,563 points

Jan 8, 2010 8:55 PM in response to OB_Taz

Several points come to mind here.

First off, is your VPN server dual-homed - that is, does it have more than one interface (e.g. a 'public' and a 'private' one)?, or does it just have the single public interface.

Typically the VPN would be setup to accept connections on the public interface and provide access to resources on the separate private interface (typically a 192.168.x.x or 10.x.x.x network).

From your post it looks like (although it's certain since you obfuscated the addresses) you're trying to configure this as a single-link VPN. ick.

When you bring up the link your client is getting an IP address on the public side of the server. Typically this should be on the private side, but if you don't have a private side that's kind of hard to do.

That said, one certain problem is the subnet mask on the VPN link:

ppp0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
inet xxx.xxx.242.132 --> xxx.xxx.242.130 netmask 0xffff0000

I find it extremely unlikely that the subnet mask (which translates to 255.255.0.0) is correct, especially since you mention that the server's subnet mask is 255.255.255.128.

Off hand, I think this is going to be tricky to solve since it involves a deeper understanding of your network topology than you've shared (or may be willing to share). Additionally I'm not even sure Server Admin supports setting up a single-link VPN in which case you'd need to get under the hood and configure the VPN service manually - a daunting task for even seasoned admins.

I'd start by looking at the routing table that the VPN server pushes out to the clients. For sure you need to fix the 255.255.0.0 subnet mask on the VPN link, but you would also need to tell the client to route xxx.xxx.242.128/255.255.255.128 over the VPN link

Reply

Answer 2

Jan 10, 2010 2:10 AM in response to OB_Taz

"basic lay out is main dns is xxx.xxx.242.13 (subnet1, router interface 242.1)
vpn server and 2nd dns server is xxx.xxx.242.130 (subnet2, router interface 242.129)
vpn address range xxx.xxx.242.131 through xxx.xxx.242.136"

Does this mean the server has 2 interfaces active? Doesn't seem so.

If the server only has one interface active and if you want to access the server itself through the VPN you need to add a second (alias) IP to the server which you then use through the VPN. ( I have a DNS with the alias IP using the servername FQDN running in the VPN server which I only give to VPN clients - a bit clumsy since I have to update it manually ).

If you want to reach nodes on other networks/subnets than what the server is on, you also need to turn on ipforwarding in the VPN server. In SA -> NAT setting: "ipforwaring only" = "routing on".
(On if firewall/NAT is on.)

Also that kind of VPN routing subnetmask "mismatch" (from what your "private" settings should result in) - I have seen it appear before when using early revisons of I belive at least 10.4 - 10.6 server. Maybe it's because of the public IPs used.

And it should really read xxx.xxx.242.128 255.255.255.128 private if you wan't access to the VPN server subnet only. But then you can't reach the DNS on the first subnet from a VPN client (depending on getting the right subnetmask from the VPN server and wether the VPN client setting "send all traffic through the VPN" is enabled or not and if ipforwarding is on or not).

So the VPN routing subnetmask needs to be set to incorporate all subnets you want to be able to reach from the VPN clients.

PPTP might appear working (connecting) but could sometimes be hindered by GRE protocol not getting through (see PPP logs in client and/or server - look for something like "unknown protocol" errors - don't remember exactly).

Also if you have the firewall running in the server the ppp0 interface (VPN) might need to be allowed to send traffic to the server. It should be ok if you have a firewall rule (keep-state) which is "wide" enough so it doesn't only say "... via en0 keep-state".

Reply

Answer 3

OB_Taz Author

Level 1

8 points

Jan 11, 2010 10:10 AM in response to Camelot

"is your VPN server dual-homed - that is, does it have more than one interface (e.g. a 'public' and a 'private' one)?, or does it just have the single public interface."

it has the single public interface, and is one of the few ports available through the firewall.

"That said, one certain problem is the subnet mask on the VPN link:

ppp0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
inet xxx.xxx.242.132 --> xxx.xxx.242.130 netmask 0xffff0000

I find it extremely unlikely that the subnet mask (which translates to 255.255.0.0) is correct, especially since you mention that the server's subnet mask is 255.255.255.128."

now that's interesting. not reading the hex, I missed that. any Idea where OS X server stores that information? a plist or a config file somewhere?

"Off hand, I think this is going to be tricky to solve since it involves a deeper understanding of your network topology than you've shared (or may be willing to share). Additionally I'm not even sure Server Admin supports setting up a single-link VPN in which case you'd need to get under the hood and configure the VPN service manually - a daunting task for even seasoned admins."

interestingly enough, I do know that for quite awhile it was working fine. quite awhile as in It was up and running fine from early summer till sometime this december. it was only about three weeks ago I go the first report of not being able to get to the rest of subnet. as for whether or not it supports it, I would think that the mini server (yes yes including 10.6) only has a single link and is listed as supporting VPN.

"I'd start by looking at the routing table that the VPN server pushes out to the clients. For sure you need to fix the 255.255.0.0 subnet mask on the VPN link, but you would also need to tell the client to route xxx.xxx.242.128/255.255.255.128 over the VPN link"

that is the next thing I'll be looking at.

Chris

Reply

Answer 4

OB_Taz Author

Level 1

8 points

Jan 11, 2010 11:09 AM in response to Leif Carlsson

Leif Carlsson wrote:
"basic lay out is main dns is xxx.xxx.242.13 (subnet1, router interface 242.1)
vpn server and 2nd dns server is xxx.xxx.242.130 (subnet2, router interface 242.129)
vpn address range xxx.xxx.242.131 through xxx.xxx.242.136"

Does this mean the server has 2 interfaces active? Doesn't seem so.

only 1 interface.

If the server only has one interface active and if you want to access the server itself through the VPN you need to add a second (alias) IP to the server which you then use through the VPN. ( I have a DNS with the alias IP using the servername FQDN running in the VPN server which I only give to VPN clients - a bit clumsy since I have to update it manually ).

i do not need to access the vpn server via the vpn. I need to access other servers on subnet 1 and subnet 2.

If you want to reach nodes on other networks/subnets than what the server is on, you also need to turn on ipforwarding in the VPN server. In SA -> NAT setting: "ipforwaring only" = "routing on".
(On if firewall/NAT is on.)

neither is on. our firewall is on the router between the subnets. nor is the NAT as all machines have real ip numbers assigned.

Also that kind of VPN routing subnetmask "mismatch" (from what your "private" settings should result in) - I have seen it appear before when using early revisons of I belive at least 10.4 - 10.6 server. Maybe it's because of the public IPs used.

And it should really read xxx.xxx.242.128 255.255.255.128 private if you wan't access to the VPN server subnet only. But then you can't reach the DNS on the first subnet from a VPN client (depending on getting the right subnetmask from the VPN server and wether the VPN client setting "send all traffic through the VPN" is enabled or not and if ipforwarding is on or not).

I am not sure as to why that would be true. if a client in the VPN subnet gets that setup, it merely sends a dns request via the router to subnet1 dns1. a client via the VPN would say I need to get to subnet 1 via the gateway assigned by the vpn. at least as I understand the networking involved. but your right that ican't find the dns via broadcast.

So the VPN routing subnetmask needs to be set to incorporate all subnets you want to be able to reach from the VPN clients.

again I can't see why? the subnets aren't exclusive, merely need to go through the router to talk.

PPTP might appear working (connecting) but could sometimes be hindered by GRE protocol not getting through (see PPP logs in client and/or server - look for something like "unknown protocol" errors - don't remember exactly).

I'll take a look but what would be preventing GRE? no firewall stops GRE.

Also if you have the firewall running in the server the ppp0 interface (VPN) might need to be allowed to send traffic to the server. It should be ok if you have a firewall rule (keep-state) which is "wide" enough so it doesn't only say "... via en0 keep-state".

no local firewall is up and running. we're doing that purely on the router.

Chris

Reply

Answer 5

OB_Taz Author

Level 1

8 points

Jan 12, 2010 2:09 PM in response to Leif Carlsson

So the VPN routing subnetmask needs to be set to incorporate all subnets you want to be able to >reach from the VPN clients.

This was the operative issue. the "network routing definition" isn't quite a routing definition. it doesn't describe the client's available routes. might be better described as "networks you want your clients to see"

so setting them to xxx.xxx.242.0 255.255.255.0 fixed everything.

Reply