8 Replies Latest reply: Sep 19, 2009 9:26 AM by rcp1967
Topher Kessler Level 6 (9,865 points)
I have a Leopard server set up with PPTP and L2TP VPN connections. The VPN works fine, but when I am connected to it I cannot log into the server with standard AFP or SMB protocols. Here's my setup:

(I'm using 192.168.x.x ip addresses as an example. The real ones are different, and all are visible to the internet)

I remotely log into the server (ip: and get a local IP address of, and then when I try to log into the server with AFP:// in the Finder's "Connect to Server" window the connection always times out. However, other machines on the local network can connect to the server just fine. Additionally, if I connect directly to the server remotely with AFP:// it will connect just fine. It's only when I'm connected to THAT SERVER's VPN service that I then cannot log in with AFP or SMB services.

It seems like once you log into OS X server's VPN service, you can no longer connect to the server's other services such as file sharing. Is this correct? If not, is there a way around this?

PM G5 dual 2.5GHz (10.5.8), PB G4 1GHz DVI (10.5.8), MBP 17" 2.66GHz (10.6.0), Mac OS X (10.6), Computers are....yummeh!
  • Robert LaRocca Level 1 (85 points)
    Are you using using the server firewall? What type of gateway (router) are you using? Is your DHCP and VPN IP's overlapping?

    If your using firewall what internal range are you using?

    I've had trouble using and had to switch to (This solved my problem, it was the same as yours. I also stopped using my ABS and got a real router from HP ProCurve.

    The range conflicts with most routers you might also try using a more generic IP schema like 172.16.1.x

    Message was edited by: Robert LaRocca
  • Kostas B Level 1 (90 points)
    You must not use a standard IP range (like 192.168.1.x or 192.168.0.x) if you plan to have VPN connections to the server for many networks (ex. if have sales persons or teleworkers that connects fro hotels or hotspots). You cannot use VPN when connecting from a network which is the same as yours). You should try to use a non "usual" range like

    You should also check if the VPN users group has access to the AFP service.


  • MrHoffman Level 6 (14,849 points)
    To clarify the issue that Kostas B is (quite correctly) referring to here,, and address blocks are all standard and compliant and entirely correct IP address ranges for private networks per RFC 1918.

    The goal here here is to avoid having the same subnet used on both ends of the VPN connection; that tends to confuse VPN routing.

    Given that most of the planet uses some part of the block and usually or (prior to IPv6 or your own public static IP block), it's best to use a subnet in another of the private network blocks.

    (And yes, I'm playing a little loose with the terminology.)
  • Leif Carlsson Level 5 (4,950 points)
    Mr Hoffman entered a typo on his first row but mentions the correct block further down:

    One can try out how big a network you get using a subnetcalculator like this (in this case using


    @ Robert:

    Using "" (which really is will get you a too big network and also block accces to public sites within this block. The only private IP addresses within that block is within the block.
  • fabcatfabcat Level 1 (0 points)
    You seem to have confused everybody by using private addressing as an example. It seems you are actually using a public address for the server. This is part of the problem.

    Lets say for example your server IP is (another example but of a public IP address), when you VPN to, you will have a route set up on your client for to go via your local gateway.

    If you use the terminal on the client and do a "netstat -rn" your will see this /32 route.

    Traffic to will be sent outside of the VPN - unencrypted, and will be blocked by any firewall rules you have set up for traffic coming from the untrusted Internet. If your VPN server gets your client to set up a route for, traffic destined for will go via the VPN except for traffic to the VPN server itself on Your firewall rules will no doubt be blocking AFP and SMB from the Internet, and this includes your client.

    There are various ways around this problem.
    - You could set up a second IP address on the VPN server, you VPN to one IP address, and then you can use the AFP/SMB services on the other IP address.
    - Alternatively, if you have a separate firewall, you could set up port forwarding of the various vpn ports from the firewall IP to the VPN server IP, then you get your client to VPN to the firewall IP, and you will be able to use AFP/SMB on the VPN server IP. You can do this port forwarding even though you will be port forwarding to public addresses rather than private.

    People who put the VPN server on private addressing behind a NAT firewall will not see this issue.

    Hope I haven't been too confusing.

    Good luck.

  • Leif Carlsson Level 5 (4,950 points)
    I was "confused" too (apparantly didn't read the initial post very well).

    One thought: if the VPN server gives public IPs to VPN clients those IPs will be vulnerable for access from Internet (when tunnel is up, VPN user is connected) so protecting those IPs with the OS X firewall in the server is probably a good idéa...
  • rcp1967 Level 1 (0 points)
    I'm a bit of a layman, so I didn't entirely understand the suggested solution above, but since my scenario is different, it may not apply anyway.

    - VPN over wireless to domain name (not IP) - connects fine
    - attempt to SMB to fails - 10.5 presented dialog with SMB shares to choose from
    - ping via Terminal successful (18-35ms response time)
    - tested with other machine (iBook on 10.5) with same settings from the same location, works fine
    - IPv6 disabled on VPN interface (heard that resolved other issues)

    I have no control over the server in a "we don't support Mac" environment.

    Any ideas?
  • rcp1967 Level 1 (0 points)
    sorry, just noticed the discussing area (server). I would love to hear any answers, but will re-post over in SL client.