AFP or SMB connection to VPN server?

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 192.168.0.0/24 and had to switch to 192.168.0.0/12 (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 192.168.0.0 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

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 10.17.17.0.

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

Regards

Kostas

To clarify the issue that Kostas B is (quite correctly) referring to here, 192.168.0.0/8, 172.16.0.0/12 and 10.0.0.0/8 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 192.168.0.0/16 block and usually 192.168.0.0/24 or 192.168.1.0/24 (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.)

Mr Hoffman entered a typo on his first row but mentions the correct block further down: 192.168.0.0/16

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

http://jodies.de/ipcalc?host=192.168.123.0&mask1=24&mask2=


@ Robert:

Using "192.168.0.0/12" (which really is 192.160.0.0/12) 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 192.168.0.0/16 block.

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 2.2.2.2 (another example but of a public IP address), when you VPN to 2.2.2.2, you will have a route set up on your client for 2.2.2.2/32 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 2.2.2.2 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 2.2.0.0/16, traffic destined for 2.2.0.0/16 will go via the VPN except for traffic to the VPN server itself on 2.2.2.2/32. 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.

Fabcat

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...

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 192.168.20.198 fails - 10.5 presented dialog with SMB shares to choose from
- ping 12.168.20.198 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?

sorry, just noticed the discussing area (server). I would love to hear any answers, but will re-post over in SL client.