Lab 08-03 · PPTP and SSTP: a tunnel to your neighbour's network¶

Your school has two buildings across town. The secretary in one building wants to print on a printer in the other, as if it were next door. Between the buildings there is only the Internet: public, shared, and full of strangers.

Companies solve this every day with a VPN (Virtual Private Network): a tunnel across the Internet that joins two private networks so they behave like one. In this lab you and your neighbour build two of them, with two different protocols, and then make your laptops talk to each other through them.

The pneumatic tube between two buildings¶

Through this module we have pictured the network as a huge public building, and a tunnel as a private pneumatic tube inside it: your packet rides in a capsule (that is encapsulation), and the corridors see only the capsule.

PPPoE (Labs 08-01 and 08-02) was a tube inside one building: it needs a shared Ethernet cable. PPTP and SSTP are tubes that run over IP, so they can cross the whole Internet: from your router to any router you can reach by IP address. Their capsule is an IP packet.

PPTP: the old tube with a cracked glass¶

PPTP (Point-to-Point Tunneling Protocol, RFC 2637, 1999, designed by a group led by Microsoft) carries PPP over IP: a control connection on tcp/1723 and the data inside GRE packets.

GRE (Generic Routing Encapsulation) is not TCP or UDP: it is its own IP protocol, number 47. That detail matters for firewalls and NAT: a rule that opens "port 1723" is not enough, because GRE has no ports at all. RouterOS solves the NAT part with a NAT helper (slide 333): it watches the tcp/1723 conversation and marks the matching GRE packets as related.

SSTP: the tube disguised as a web page¶

SSTP (Secure Socket Tunneling Protocol, Microsoft, first shipped with Windows Vista SP1 and Windows Server 2008) carries PPP inside a TLS connection on tcp/443, the same port as HTTPS.

TLS is the encryption of every https:// web page. Because SSTP looks like normal HTTPS traffic, it usually passes through hotel and office firewalls without special rules (slide 339). Linux has open-source clients too (sstpc, installed on your lab laptops).

TLS needs a certificate on the server.

A certificate is a digital ID card: it says "this public key belongs to 10.0.0.89" and is signed by a certificate authority (CA), the "office" that issues ID cards.

Real websites use CAs that your browser already trusts. In a lab or a company you can be your own CA: create a CA certificate, then use it to sign the server's certificate. That is a self-signed setup: it encrypts perfectly, but only clients told to trust your CA can verify it.

Slide 342: between two RouterOS devices SSTP even works without a certificate, but Windows needs a valid one. We do it properly and create one.

The scenario¶

You are r1; your neighbour is r2. Both routers hang from the class network. Following slide 343, each of you runs one server and one client, so there are two tunnels, one in each direction:

• r1: PPTP server · SSTP client of r2
• r2: SSTP server · PPTP client of r1

Both routers already have the pool, profile and secret from Lab 08-02 (pppoe-pool, pppoe-profile, student / mtcnalab): the same guest list serves every PPP door, PPPoE, PPTP or SSTP. In the virtual lab you play both roles, with one terminal per router.

flowchart LR
    subgraph L1["Your LAN 192.168.88.0/24"]
        PC1["<b>pc1</b><br>192.168.88.x"]
    end
    R1["<b>r1</b><br>WAN 10.0.0.88<br><b>PPTP server</b> · tube end 10.88.0.1"]
    AP["<b>class-ap</b><br>10.0.0.1<br>the 'Internet' between you"]
    R2["<b>r2</b><br>WAN 10.0.0.89<br><b>SSTP server</b> · tube end 10.89.0.1"]
    subgraph L2["Neighbour LAN 192.168.89.0/24"]
        PC2["<b>pc2</b><br>192.168.89.x"]
    end
    PC1 --- R1
    R1 ---|"ether2"| AP
    AP ---|"ether2"| R2
    R2 --- PC2
    R2 -. "pptp-out1 (r2 dials r1)<br>tcp/1723 + GRE" .-> R1
    R1 -. "sstp-out1 (r1 dials r2)<br>tcp/443" .-> R2

The WAN addresses are fixed in this lab so that each of you knows where to dial. In class you would read your WAN address with /ip address print and tell your neighbour. On a real hAP the Internet port is ether1; in the virtual lab ether1 is reserved for the lab itself, so the Internet port is ether2 and the LAN ports start at ether3.

Start the lab¶

Download the lab files and unzip them: 08-03-pptp-sstp.zip. Open a terminal inside the 08-03-pptp-sstp folder.

sudo containerlab deploy -t topology.clab.yml

Three routers take two or three minutes to boot. Then open four terminals:

ssh admin@clab-mtcna-08-03-r1                  # you          (password: admin)
ssh admin@clab-mtcna-08-03-r2                  # neighbour    (password: admin)
docker exec -it clab-mtcna-08-03-pc1 bash      # your laptop
docker exec -it clab-mtcna-08-03-pc2 bash      # neighbour's laptop

Step 1 · Meet your neighbour¶

Before building a tube you must reach the other station. Check that each router sees the other across the class network, and that the guest list from Lab 08-02 is there.

# on r1
/ip address print
/ping 10.0.0.89 count=2
/ppp secret print
/ppp profile print where name=pppoe-profile

The ping to 10.0.0.89 answers, and the secret student with profile pppoe-profile exists (on r2 the profile's local address is 10.89.0.1).

Also note the laptops' addresses: run ip -4 addr show eth1 on pc1 and pc2.

Done when r1 pings 10.0.0.89 and you have written down both laptops' addresses.

Step 2 · r1: switch on the PPTP server¶

PPTP has a single server per router (no "door per interface" as in PPPoE): you just enable it and say which profile and authentication to use.

WinBox: PPP → Interface → PPTP Server: Enabled, Default Profile pppoe-profile, Authentication only mschap2. (On a hAP, QuickSet → VPN Access builds a ready-made PPTP/L2TP server for remote administration, slide 337.)

# on r1
/interface pptp-server server set enabled=yes default-profile=pppoe-profile authentication=mschap2
/interface pptp-server server print

Look at the first line of the output: RouterOS itself warns that PPTP is unsafe.

Done when the server shows enabled: yes.

Step 3 · r2: dial r1 with a PPTP client, and watch it fail¶

WinBox: PPP → Interface → + → PPTP Client. Tab Dial Out: Connect To 10.0.0.88, User student, Password mtcnalab. Leave Add Default Route unticked: we only want the neighbour's LAN through the tube, not the whole Internet (slide 336).

# on r2
/interface pptp-client add name=pptp-out1 connect-to=10.0.0.88 user=student password=mtcnalab disabled=no
/interface pptp-client monitor pptp-out1

The status keeps cycling connecting... / disconnected (press Ctrl+C to stop the monitor). Why? Look at r1's firewall:

# on r1
/ip firewall filter print stats

The counter of "drop all not coming from LAN" keeps growing: r1's input firewall is dropping the knocks on its door, because ether2 is in the list WAN.

Done when you have found the growing drop counter.

Step 4 · r1: open the firewall for PPTP¶

Slide 344: PPTP needs tcp/1723 and GRE. The accept rules must sit above the drop rule, because the firewall reads rules from top to bottom and stops at the first match.

WinBox: IP → Firewall → Filter Rules → +: Chain input, Protocol tcp, Dst. Port 1723, Action accept; a second rule with Protocol gre, Action accept. Drag both above "drop all not coming from LAN".

# on r1
/ip firewall filter add chain=input action=accept protocol=tcp dst-port=1723 comment="PPTP control (tcp/1723)" \
    place-before=[find comment="drop all not coming from LAN"]
/ip firewall filter add chain=input action=accept protocol=gre comment="PPTP data (GRE, IP protocol 47)" \
    place-before=[find comment="drop all not coming from LAN"]

# on r2
/interface pptp-client monitor pptp-out1 once

         status: connected
       encoding: MPPE128 stateless
            mtu: 1450
  local-address: 10.88.0.50
 remote-address: 10.88.0.1

r2 got 10.88.0.50 from your pool, and the data is encrypted with MPPE128. On r1, /ppp active print shows student with service pptp and caller-id 10.0.0.89: over IP, the caller is an IP address, not a MAC.

Done when pptp-out1 on r2 is connected.

Step 5 · r2: make a certificate and switch on the SSTP server¶

Now the modern tube. First r2 becomes its own certificate authority and issues itself an ID card for its WAN address. Signing takes a few seconds; RouterOS shows progress: done.

WinBox: System → Certificates → +: Name lab-ca, Common Name lab-ca, Key Usage key cert. sign and crl sign; Apply, then Sign. Then a second certificate: Name r2-sstp, Common Name 10.0.0.89, Subject Alt. Name IP:10.0.0.89, Key Usage digital signature, key encipherment, tls server; Sign it choosing CA lab-ca.

# on r2
/certificate add name=lab-ca common-name=lab-ca key-usage=key-cert-sign,crl-sign days-valid=3650
/certificate sign lab-ca
/certificate add name=r2-sstp common-name=10.0.0.89 subject-alt-name=IP:10.0.0.89 \
    key-usage=digital-signature,key-encipherment,tls-server days-valid=3650
/certificate sign r2-sstp ca=lab-ca
/certificate print

Flags: K - PRIVATE-KEY; A - AUTHORITY; I - ISSUED; T - TRUSTED
#      NAME     COMMON-NAME  SUBJECT-ALT-NAME
0 KA T lab-ca   lab-ca
1 K I  r2-sstp  10.0.0.89    IP:10.0.0.89

Then the server, and a firewall door for tcp/443 (same reason as Step 4):

WinBox: PPP → Interface → SSTP Server: Enabled, Certificate r2-sstp, Default Profile pppoe-profile, Authentication only mschap2. IP → Firewall: accept tcp dst-port 443 on input, above the drop rule.

# on r2
/interface sstp-server server set enabled=yes certificate=r2-sstp default-profile=pppoe-profile authentication=mschap2
/ip firewall filter add chain=input action=accept protocol=tcp dst-port=443 comment="SSTP (tcp/443)" \
    place-before=[find comment="drop all not coming from LAN"]

Done when the SSTP server is enabled with certificate: r2-sstp.

Step 6 · r1: dial r2 with an SSTP client¶

WinBox: PPP → Interface → + → SSTP Client. Tab Dial Out: Connect To 10.0.0.89, User student, Password mtcnalab, Add Default Route unticked.

# on r1
/interface sstp-client add name=sstp-out1 connect-to=10.0.0.89 user=student password=mtcnalab disabled=no
/interface sstp-client monitor sstp-out1 once

         status: connected
       encoding: AES256-CBC
  local-address: 10.89.0.50
 remote-address: 10.89.0.1

The encryption is now AES-256, a modern cipher, inside TLS. You can see the certificate from a laptop on r2's side (curl speaks TLS to port 443 even though no web page is there):

# on pc2
curl -skv -m 5 https://10.0.0.89/ 2>&1 | grep -E 'subject|issuer'

*  subject: CN=10.0.0.89
*  issuer: CN=lab-ca

Done when sstp-out1 on r1 is connected.

Step 7 · Ping the neighbour's laptop, and find out why it fails¶

Both tubes are up. Time for the real goal: laptop to laptop (slide 344).

# on pc1 (use pc2's address from Step 1)
ping -c 3 -W 2 192.168.89.200

From 10.0.0.1 icmp_seq=1 Destination Net Unreachable

The answer comes from 10.0.0.1, the class gateway, not from pc2. Why did your packet end up there? Ask r1 where it would send it:

# on r1
/ip route print

There is no route to 192.168.89.0/24. The only routes through the tubes are the /32s of the tube ends (10.88.0.50 and 10.89.0.1). So r1 sends the packet to its default route, 10.0.0.1, the class gateway, which has no idea where 192.168.89.0/24 is. A tunnel is a link, not magic: routers still need routes to use it (slide 345).

Done when you can explain why the ping fails.

Step 8 · Route each LAN through a tube¶

Each router sends the neighbour's LAN through its own client interface (slide 345). The gateway is an interface, not an address: the tube has only one other end, so "send it into the tube" is enough.

WinBox: IP → Routes → +: Dst. Address 192.168.89.0/24, Gateway sstp-out1 (on r1); Dst. Address 192.168.88.0/24, Gateway pptp-out1 (on r2).

# on r1
/ip route add dst-address=192.168.89.0/24 gateway=sstp-out1 comment="neighbour LAN through the SSTP tunnel"

# on r2
/ip route add dst-address=192.168.88.0/24 gateway=pptp-out1 comment="neighbour LAN through the PPTP tunnel"

# on pc1
ping -c 3 192.168.89.200
traceroute -n 192.168.89.200

64 bytes from 192.168.89.200: icmp_seq=1 ttl=62 time=0.80 ms
 1  192.168.88.1
 2  10.88.0.50
 3  192.168.89.200

It works. Look closely at hop 2: 10.88.0.50 is r2's address in the PPTP tube, although your packet went out through the SSTP tube. Hop 2 is r2 answering "time exceeded", and r2 sends its answers to your LAN through pptp-out1, so they come from its PPTP address. Your packets go through one tube and the replies come back through the other: an asymmetric path. It works because each router has a route for the other direction.

Run the automatic check from the lab folder on your Ubuntu PC; every line must say PASS:

CLAB_EXEC="docker exec" ./check.sh

Done when pc1 pings pc2 and check.sh passes.

Step 9 (optional) · A Linux laptop as SSTP client¶

Slide 339 says there are open-source SSTP clients for Linux. Dial r2 directly from pc1, without touching r1's tunnels:

# on pc1
sstpc --cert-warn --save-server-route --user student --password mtcnalab 10.0.0.89 \
      usepeerdns require-mschap-v2 noauth nodefaultroute &
sleep 8
ip -4 addr show ppp0
ping -c 2 10.89.0.1
pkill sstpc

ppp0 gets an address from r2's pool (10.89.0.x). --cert-warn tells sstpc to carry on although it does not trust lab-ca: the same "encrypted but not verified" situation as in Step 6.

If something goes wrong¶

Clean up¶

sudo containerlab destroy -t topology.clab.yml --cleanup

Key takeaways¶

• A VPN joins two private networks across a public one with a tunnel; PPTP and SSTP run over IP, so they cross the Internet, unlike PPPoE.
• PPTP uses tcp/1723 + GRE (IP protocol 47) and MPPE; it is insecure (MS-CHAPv2 broken in 2012). Know it for the exam, replace it in real life.
• SSTP hides PPP inside TLS on tcp/443; the server needs a certificate, which you can issue from your own CA on RouterOS (/certificate add + sign).
• Every server needs a hole in the input firewall, placed above the drop rule.
• A tunnel is just a link: to reach the neighbour's LAN you need a static route with the tunnel interface as gateway, on both routers.

Quick check¶

That closes Module 8: three kinds of tube, one idea. Next, Module 9 (Miscellaneous) collects the extra utilities RouterOS gives you to look after a network.