Access intranet with VPN through PPPoE

I have a home wired Ethernet network (1.1.0.0). One of the macs in this network is a mac mini Server (1.1.1.2). Another device (1.1.1.8) provides some valuable service which I want to use outside over the internet. My ISP gives me internet access through bridge connection at some routing device connected to the same Ethernet network (bridge, no IP). mac mini Server dials PPPoE to ISP and gets its static public 91.122.XXX.XXX IP. mac mini Server uses InternetConectionSharing (switched to start from 1.1.1.1) to give internet to the rest of Ethernet network. With InternetConnection switched on, mac mini Server gets another one local 1.1.1.1 IP.

At mac mini Server I have set up VPN to start from 1.1.1.100. Then I dial VPN to my 91.122.XXX.XXX server from my cellular network (90.30.XXX.XXX) having no access to my home network.

I can use 1.1.1.1 services from that iPhone. But I can not connect to any other device on home network except mac mini Server 1.1.1.1.

When I look at tcpdump it shows:

PPPoE 90.30.XXX.XXX > 91.122.XXX.XXX packet

TCP 1.1.1.1XX > 1.1.1.8 SYN packet

TCP 1.1.1.8 > 1.1.1.1XX SYN ACK packet

So, TCP SYN ACK does not get transmitted back from server over VPN.

How to deal with it? Please help me. Any clue? How to troubleshoot why response does not get back for all devices except server?

In Server.app there is a list of routes that will be provided to VPN clients. But I think that the problem is not on the client side, because client succeedes passing the packet through VPN to server. I think it has something to do with server routing.

I have added 1.1.0.0/255.255.0.0 Private route and it changed nothing. Still VPN client's packets gets to server PPPoE 90.33.XXX.XXX > 91.121.XXX.XXX, then it is unpacked and transmitted over the local network 1.1.1.1XX > 1.1.1.8, then, server responds to 1.1.1.8 > 1.1.1.1XX over that local network and still they doesn't pack to PPPoE for transmission over the VPN back.

What could be wrong? What additional steps should be performed besides default for server routing to behave well in described environment?

For a NAT'd network, please utilize one of the designated private IP address blocks (a subnet within 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16), and out of real and routable public IP address space; if your 1.0.0.0/8 routes should leak out — hopefully your ISP is configured to prevent that from happening — then your network activity could get very much more interesting. Your remote access via VPN may well be running into a routing issue, if there's a better IP route to 1.0.0.0/8 available elsewhere, too. There won't be a public route to one of the private blocks.

Replaced 1.1.1.0/24 to 10.0.0.0/24. Everything is the same both without and with additional 10.0.0.0/24 VPN client route.

Why UNIX stuff is so broken?! Things can't negotiate with each other. Why every step to UNIX from Windows is so painfull and slow? One problem gets behind the other. I can't see them ended. And I'm seriously considering switching back to Windows Server. It is a no way to go. Please, help me, any clue? How UNIX makes its descisions what to do with a network packet? Why does it silently discards it and not transmit via exiting VPN tunnel?

Computers of all kinds are often frustrating. If you like windows by all means use it.

Others are able to use the service you are having problems with. Something specific about your set up is defeating VPN.

Like a firewall issue or conflict on a port needed by VPN.

This might be a clue:

"OS X Server VPN service, Back to My Mac. Note: Configuring Back to My Mac on an AirPort Base Station or Time Capsule in NAT mode will impede connectivity to an OS X Server VPN service behind that NAT."

If Microsoft Windows better meets your needs, then by all means use it. Windows Server is a very capable server operating system environment, and very widely deployed.

I see you're using Internet connection sharing. I prefer to avoid that — trying to get OS X to act as a NAT router has been a longstanding issue, and having it exposed in this fashion tends to allow remote folks to poke directly at it. Short of fairly involved ccommand line configuration sequences, here are very few controls over that capability, as well. Given you're entirely public addresses and with no NAT, I'd tend to expect routing problems with trying to reach that NAT'd network.

In general, I'd have a firewall-gateway-router-NAT box connected to your ISP bridge, and having that handling NAT and either with an embedded VPN server, or with VPN pass-through.

if you don't want to configure that, then you'll probably want to get a second public static (routable) IP address from your ISP, and assign that to your target box. You can then connect directly, without NAT, using that IP address. No passthrough, no NAT.

At least so far, nothing discussed here is specific to Windows or to OS X, either. All of what's being discussed are IP and DNS networking configuration details, and the usual hassles that are VPNs. (I also generally don't prefer to use VPN passthrough, as I've found it to be fussy around NAT.)

VPNs generally do not require specification of routes, though I've had a few cases where I've had to specify one due to the local network and target configuration: Here's an example of adding a route, but this applies to reaching the target network via a working NAT box:

There is no firewalls or NATs between OS X Server and internet. Direct connection through bridge. I can see all the packets going into server. They does not go to VPN back.

I'd either use NAT (and preferably a valid private block), or get a few more public addresses from the ISP network provider. I'd not use the 1.0.0.0/8 block, as that block is a real and routable IPv6 block, and was assigned to APNIC in 2010.

I'd get a firewall in general, as I don't trust OS X Server to keep all of its ports secure against remote probes.

With a firewall (preferably with an embedded VPN server) there's little reason not to use NAT. Well, not unless additional public static IP addresses are available, and available sufficiently cheaply.

NAT also usually expects use of one of the three private address blocks (10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16), and properly-functioning routers will generally prevent those blocks from being presented as routable.

In effect you are using a Mac mini as a router. More often folks use an airport or similar device with NAT as their primary connection. Your problem seems to arise from a conflict between internet connection sharing and vpn on the Mac.

I can't find much documentation on how internet connection sharing works under the covers.

I think you have two choices:

1) acquire a router and put it in front of you Mac. Turn off internet connection sharing.

2) figure out how to override this not well documented feature of osx.

I use to have a Mac pro with two ethernet port configure to be expose to public network

Now, I much prefer to have a router between my Mac and the external network. Mac Server use to a have much more fine control over the firewall. Now I use the router for it. The server does not need to have a public IP, only the router, and forward the service you want to the machine you want.

The Mac Mini only has one ethernet port.

Internet sharing only work from one network interface to another, what do you use, as a second port for internet sharing ?

More Like This

Related Articles

This site contains user submitted content, comments and opinions and is for informational purposes only.
Apple may provide or recommend responses as a possible solution based on the information provided; every potential issue may involve several factors not detailed in the conversations captured in an electronic forum and Apple can therefore provide no guarantee as to the efficacy of any proposed solutions on the community forums.
Apple disclaims any and all liability for the acts, omissions and conduct of any third parties in connection with or related to your use of the site. All postings and use of the content on this site are subject to the Apple Support Communities Terms of Use.