Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

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?

91.122.XXX.XXX:~ me$ sudo netstat -r -n -f inet

Routing tables

Internet:

Destination Gateway Flags Refs Use Netif Expire

default 95.55.16.1 UGSc 79 21465 ppp0

default link#11 UCSI 0 0 bridge1

default 1.1.1.114 UGScI 0 0 ppp1

1.1.1/24 link#11 UC 8 0 bridge1

1.1.1.2 127.0.0.1 UHS 2 756 lo0

1.1.1.113 link#11 UHLWI 0 5 bridge1

1.1.1.114 91.122.XXX.XXX UHr 4 263 ppp1

1.1.1.114 bridge100:cb.2b.64 UHLS2 0 0 bridge1

95.55.16.1 91.122.XXX.XXX UHr 79 0 ppp0

127 127.0.0.1 UCS 0 0 lo0

127.0.0.1 127.0.0.1 UH 18 30108 lo0

91.122.XXX.XXX:~ me$ ifconfig

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384

options=3<RXCSUM,TXCSUM>

inet6 ::1 prefixlen 128

inet 127.0.0.1 netmask 0xff000000

inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1

nd6 options=1<PERFORMNUD>

gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280

stf0: flags=0<> mtu 1280

en0: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500

options=10b<RXCSUM,TXCSUM,VLAN_HWTAGGING,AV>

ether 10:dd:b1:bc:dd:f6

nd6 options=1<PERFORMNUD>

media: autoselect (1000baseT <full-duplex,flow-control,energy-efficient-ethernet>)

status: active

en1: flags=8823<UP,BROADCAST,SMART,SIMPLEX,MULTICAST> mtu 1500

ether 28:cf:e9:02:36:15

nd6 options=1<PERFORMNUD>

media: autoselect (<unknown type>)

status: inactive

en2: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500

options=60<TSO4,TSO6>

ether 32:00:11:e8:d5:a0

media: autoselect <full-duplex>

status: inactive

fw0: flags=8822<BROADCAST,SMART,SIMPLEX,MULTICAST> mtu 4078

lladdr 44:fb:42:ff:fe:1e:8d:5a

media: autoselect <full-duplex>

status: inactive

bridge0: flags=8822<BROADCAST,SMART,SIMPLEX,MULTICAST> mtu 1500

options=63<RXCSUM,TXCSUM,TSO4,TSO6>

ether 12:dd:b1:cb:2b:00

Configuration:

id 0:0:0:0:0:0 priority 0 hellotime 0 fwddelay 0

maxage 0 holdcnt 0 proto stp maxaddr 100 timeout 1200

root id 0:0:0:0:0:0 priority 0 ifcost 0 port 0

ipfilter disabled flags 0x2

member: en2 flags=3<LEARNING,DISCOVER>

ifmaxaddr 0 port 6 priority 0 path cost 0

media: <unknown type>

status: inactive

p2p0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 2304

ether 0a:cf:e9:02:36:15

media: autoselect

status: inactive

ppp0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1492

inet 91.122.XXX.XXX --> 95.55.16.1 netmask 0xff000000

utun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380

inet6 fe80::a9b3:1267:b54b:3c55%utun0 prefixlen 64 scopeid 0xe

inet6 fd18:123a:86a6:4f5f:a9b3:1267:b54b:3c55 prefixlen 64

nd6 options=1<PERFORMNUD>

bridge100: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500

options=3<RXCSUM,TXCSUM>

ether 12:dd:b1:cb:2b:64

inet 1.1.1.1 netmask 0xffffff00 broadcast 1.1.1.255

Configuration:

id 0:0:0:0:0:0 priority 0 hellotime 0 fwddelay 0

maxage 0 holdcnt 0 proto stp maxaddr 100 timeout 1200

root id 0:0:0:0:0:0 priority 0 ifcost 0 port 0

ipfilter disabled flags 0x2

member: en0 flags=3<LEARNING,DISCOVER>

ifmaxaddr 0 port 4 priority 0 path cost 0

media: autoselect

status: active

ppp1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1272

inet 91.122.XXX.XXX --> 1.1.1.114 netmask 0xff000000

OS X Mavericks (10.9.2), Xcode 5

Posted on Apr 19, 2014 6:43 PM

Reply
16 replies

Apr 20, 2014 11:15 AM in response to piperspace

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?

Apr 20, 2014 11:57 AM in response to OZone.

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.

Apr 20, 2014 11:58 AM in response to OZone.

I agree - it does sound like the server is failing to recognize LAN packets directed to your VPN client and route them.


My only other suggestion is to consider using one of the usual private IP ranges on your LAN.


10.x.x.x or 192.168.x.x instead of 1.1.x.x.


The range you are using could be confusing to the server's routing logic. It may be sending them to the internet instead of your VPN client.


Just a suggestion

Apr 20, 2014 12:58 PM in response to MrHoffman

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?

Apr 20, 2014 1:57 PM in response to OZone.

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


See this link:


http://support.apple.com/kb/HT6175?viewlocale=en_US


Good luck.

Apr 20, 2014 2:03 PM in response to OZone.

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:

sudo route add 10.20.30.0/24 -interface ppp0

Apr 27, 2014 8:03 AM in response to OZone.

OZone. wrote:


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.

Apr 27, 2014 12:03 PM in response to OZone.

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.


Here are some links that may help


http://blog.macminicolo.net/post/67570761408/setup-a-vpn-server-with-mavericks-s erver-10-9


https://developer.apple.com/library/mac/documentation/Darwin/Reference/Manpages/ man8/pfctl.8.html


Good luck

Nov 12, 2014 3:31 PM in response to OZone.

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 ?

Access intranet with VPN through PPPoE

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.