VPN Server on Cloud Router at AWS

SomeYoungGuy · Fri Jul 05, 2019 5:11 pm

I get it, PPTP VPN's are bad news because of a bunch of reasons, so Apple removed support for it... but gosh it sure was easier to use... Im attempting to get my mac, or iphone to connect to a hosted Mikrotik that I have in AWS,

I have created am EC2 instance running "Cloud Hosted Router-6-34-1" at AWS, as you know its NATed.

I have opened the UDP port 500 and 4500 on the security group, and have followed a number of posts online (almost all say different things), but cant get the VPN established.

When I try from my mac, it does not connect, the Mikrotik shows a log:

first L2TP UDP packet received from <my live IP>

but then nothing else.

Anyone got a walk-though?

csalcedo · Fri Jul 05, 2019 5:22 pm

are you using l2tp over ipsec?

SomeYoungGuy · Fri Jul 05, 2019 5:29 pm

Im using a Mac, or an iPhone

sindy · Fri Jul 05, 2019 5:44 pm

If you got the "first L2TP packet seen" log message, and you haven't open UDP port 1701 on the firewall in front of the CHR, it is clear that you use L2TP over IPsec and that the IPsec part came up fine (otherwise the L2TP packet would not make it through).

Now it is time to set /system logging add topics=l2tp, then run /log print follow-only where topics~"l2tp" and try to connect your iDevice again. Just bear in mind to connect just one device from the same network at a time - L2TP/IPsec doesn't like two clients connecting from behind the same public IP unless you take special measures which may be above your head for the time being (it's actually above my own head although I have developed that workaround myself). The log should tell you what's wrong; if it doesn't, don't hesitate to copy-paste it here. See the hint in my automatic signature below for anonymisation.

SomeYoungGuy · Fri Jul 05, 2019 5:52 pm

I would assume iphone and Mac use IPSEC...

The output log is still the same:
14:47:12 l2tp,info first L2TP UDP packet received from xxx.xxx.xxx.xxx

SomeYoungGuy · Fri Jul 05, 2019 6:00 pm

I'm suspicious that its to do with NAT... i have nothing on the router other then a blanket masquerade. But my understanding then is that WAS probably are not altering the packets on the way out, so packets may appears to come from the EC2 instance local IP address.

sindy · Fri Jul 05, 2019 6:57 pm

I'm suspicious that its to do with NAT... i have nothing on the router other then a blanket masquerade. But my understanding then is that WAS probably are not altering the packets on the way out, so packets may appears to come from the EC2 instance local IP address.

That doesn't seem plausible to me given that already the IPsec part would have to fail if it was like you suspect. You can check that by running /ip ipsec policy print interval=1s in yet another text window; you should see the policy to appear there for a while. If it does, it is an issue of the L2TP part itself. I am very surprised that you cannot see more than that single l2tp-related message in the log after swicthing on the debug of l2tp; can you post the config export following the hint in my automatic signature?

SomeYoungGuy · Sat Jul 06, 2019 11:50 am

The output is now in debug... but i think there is a lot of personally identifying information...

The one thing that i see a lot of is:

08:29:41 l2tp,debug,packet sent control message (ack) to <my pc live ip>:54385 from <this router LOCAL address>:1701
08:29:41 l2tp,debug,packet tunnel-id=6, session-id=0, ns=1, nr=1
...
... ends with ...
08:29:41 l2tp,debug tunnel 5 received no replies, disconnecting
08:29:41 l2tp,debug tunnel 5 entering state: dead

As described above, im seeing a lot of messages "control" messages etc, referring to this routers local ip address - remember that this router is behind AWS nat router, so my pc cannot reach this routers local ip - if the control messages is expecting a reply to its messages it will need to tell it what the live IP is.

SomeYoungGuy · Sat Jul 06, 2019 12:34 pm

Im running a wrireshark trace on my mac... it seems ESP cannot communicate(no response packets), but the ISAKMP was successful (reply packets found).

I don't mean to sound obvious here... but AWS is extremely popular and Mikrotik is rather popular too... so too are Mac Computers.... I would have thought this would have returned thousands of perfectly working walk-thoughs online.

Screenshot 2019-07-06 at 11.33.41.png

sindy · Sat Jul 06, 2019 12:45 pm

The output is now in debug... but i think there is a lot of personally identifying information...

That's why I advise to use the find&replace functionality of a text editor before posting configurations and logs, as it is easy to miss an occurrence of an address when doing that manually, and also as it may take a long time to edit them manually.

As described above, im seeing a lot of messages "control" messages etc, referring to this routers local ip address - remember that this router is behind AWS nat router, so my pc cannot reach this routers local ip - if the control messages is expecting a reply to its messages it will need to tell it what the live IP is.

That's a relevant concern but you don't take into account how the IPsec in transport mode works. When the L2TP transport packet (UDP packet from port 1701 to whatever port is used at the client side) is sent from the CHR's local address to the public IP from behind which the PC is connecting, the traffic selector of the IPsec policy matches it and "steals" it - the packet is not sent out the chosen interface but encapsulated into an ESP packet which is then sent to the sa-dst-address of the policy. Because there is NAT between the endpoints of the SA (Security Association), the ESP packets are further encapsulated into UDP and become part of the same UDP stream carrying the IKE packets used to establish and control the SAs. And now the part which explains why it doesn't matter that the source IP of the L2TP transport packets is the local private one: as the encapsulation is done in transport mode, not tunnel mode, the ESP packets contain only the payload (L4 and above) of the IP packets being encapsulated, not the IP addresses. So when the IP address of the UDP packet carrying the ESP one changes as it travels to the PC, during decapsulation of the L2TP transport packet from the ESP at the PC side, the L2TP transport packet inherits the source and destination IP addresses from the ESP one. So the CHR sends the transport packet from A (local private IP) to B (the public IP of the router behind which the PC is connected), and the UDP carrying the ESP inherits these addresses. The src-nat at CHR side replaces A by the public IP of the AWS, C, so on the internet we now have a C to B packet. And if the PC doesn't have a public IP itself, the "un-src-nat" at the PC's router side replaces router's public IP B by PC's address D which makes it a C to D packet. So when the L2TP transport packet is decapsulated at the PC end, it has the local private address of the PC as destination and the public IP of the AWS as source.

To your actual issue, as you seem to get nothing else from the PC but the initial L2TP packet, it is likely that the packets sent by the CHR never reach the PC (and your Wireshark capture confirms that). What often happens with IPsec is that people don't realize that the packet must be first routed by the normal routing so that it could be stolen by an IPsec policy, so they don't have routes to the destination subnets handled by the policies and are surprised that the packets aren't delivered. This should, however, not be your case as the IPsec SA is established, so there must be a route towards the PC's public IP (probably the default one).

So I'm afraid I have no more ideas what might be wrong until you post your CHR's configuration, following the anonymisation hints in my automatic signature below.

SomeYoungGuy · Sat Jul 06, 2019 12:59 pm

The debug with replacements for the ip

...
08:29:22 l2tp,debug,packet rcvd control message from <my_live_pc_ip>:54385 to <my_router_local_ip>:1701
08:29:22 l2tp,debug,packet tunnel-id=0, session-id=0, ns=0, nr=0
08:29:22 l2tp,debug,packet (M) Message-Type=SCCRQ
08:29:22 l2tp,debug,packet (M) Protocol-Version=0x01:00
08:29:22 l2tp,debug,packet (M) Framing-Capabilities=0x3
08:29:22 l2tp,debug,packet (M) Host-Name=0x43:6f:6e:72:61:64:73:2d:4d:61:63:42:6f:6f:6b:2d
08:29:22 l2tp,debug,packet 50:72:6f:2e:6c:6f:63:61:6c:00
08:29:22 l2tp,debug,packet (M) Assigned-Tunnel-ID=6
08:29:22 l2tp,debug,packet (M) Receive-Window-Size=4
08:29:22 l2tp,info first L2TP UDP packet received from <my_live_pc_ip>
08:29:22 l2tp,debug tunnel 5 entering state: wait-ctl-conn
08:29:22 l2tp,debug,packet sent control message to <my_live_pc_ip>:54385 from <my_router_local_ip>:1701
08:29:22 l2tp,debug,packet tunnel-id=6, session-id=0, ns=0, nr=1
08:29:22 l2tp,debug,packet (M) Message-Type=SCCRP
08:29:22 l2tp,debug,packet (M) Protocol-Version=0x01:00
08:29:22 l2tp,debug,packet (M) Framing-Capabilities=0x1
08:29:22 l2tp,debug,packet (M) Bearer-Capabilities=0x0
08:29:22 l2tp,debug,packet Firmware-Revision=0x1
08:29:22 l2tp,debug,packet (M) Host-Name="My VPN Server"
08:29:22 l2tp,debug,packet Vendor-Name="MikroTik"
08:29:22 l2tp,debug,packet (M) Assigned-Tunnel-ID=5
08:29:22 l2tp,debug,packet (M) Receive-Window-Size=4
08:29:23 l2tp,debug,packet rcvd control message from <my_live_pc_ip>:54385 to <my_router_local_ip>:1701
08:29:23 l2tp,debug,packet tunnel-id=0, session-id=0, ns=0, nr=0
08:29:23 l2tp,debug,packet (M) Message-Type=SCCRQ
08:29:23 l2tp,debug,packet (M) Protocol-Version=0x01:00
08:29:23 l2tp,debug,packet (M) Framing-Capabilities=0x3
08:29:23 l2tp,debug,packet (M) Host-Name=0x43:6f:6e:72:61:64:73:2d:4d:61:63:42:6f:6f:6b:2d
08:29:23 l2tp,debug,packet 50:72:6f:2e:6c:6f:63:61:6c:00
08:29:23 l2tp,debug,packet (M) Assigned-Tunnel-ID=6
08:29:23 l2tp,debug,packet (M) Receive-Window-Size=4
08:29:23 l2tp,debug,packet sent control message (ack) to <my_live_pc_ip>:54385 from <my_router_local_ip>:1701
08:29:23 l2tp,debug,packet tunnel-id=6, session-id=0, ns=1, nr=1
08:29:23 l2tp,debug,packet sent control message to <my_live_pc_ip>:54385 from <my_router_local_ip>:1701
08:29:23 l2tp,debug,packet tunnel-id=6, session-id=0, ns=0, nr=1
08:29:23 l2tp,debug,packet (M) Message-Type=SCCRP
08:29:23 l2tp,debug,packet (M) Protocol-Version=0x01:00
08:29:23 l2tp,debug,packet (M) Framing-Capabilities=0x1
08:29:23 l2tp,debug,packet (M) Bearer-Capabilities=0x0
08:29:23 l2tp,debug,packet Firmware-Revision=0x1
08:29:23 l2tp,debug,packet (M) Host-Name="My VPN Server"
08:29:23 l2tp,debug,packet Vendor-Name="MikroTik"
08:29:23 l2tp,debug,packet (M) Assigned-Tunnel-ID=5
08:29:23 l2tp,debug,packet (M) Receive-Window-Size=4
08:29:24 l2tp,debug,packet sent control message to <my_live_pc_ip>:54385 from <my_router_local_ip>:1701
08:29:24 l2tp,debug,packet tunnel-id=6, session-id=0, ns=0, nr=1
08:29:24 l2tp,debug,packet (M) Message-Type=SCCRP
08:29:24 l2tp,debug,packet (M) Protocol-Version=0x01:00
08:29:24 l2tp,debug,packet (M) Framing-Capabilities=0x1
08:29:24 l2tp,debug,packet (M) Bearer-Capabilities=0x0
08:29:24 l2tp,debug,packet Firmware-Revision=0x1
08:29:24 l2tp,debug,packet (M) Host-Name="My VPN Server"
08:29:24 l2tp,debug,packet Vendor-Name="MikroTik"
08:29:24 l2tp,debug,packet (M) Assigned-Tunnel-ID=5
08:29:24 l2tp,debug,packet (M) Receive-Window-Size=4
08:29:25 l2tp,debug,packet rcvd control message from <my_live_pc_ip>:54385 to <my_router_local_ip>:1701
08:29:25 l2tp,debug,packet tunnel-id=0, session-id=0, ns=0, nr=0
08:29:25 l2tp,debug,packet (M) Message-Type=SCCRQ
08:29:25 l2tp,debug,packet (M) Protocol-Version=0x01:00
08:29:25 l2tp,debug,packet (M) Framing-Capabilities=0x3
08:29:25 l2tp,debug,packet (M) Host-Name=0x43:6f:6e:72:61:64:73:2d:4d:61:63:42:6f:6f:6b:2d
08:29:25 l2tp,debug,packet 50:72:6f:2e:6c:6f:63:61:6c:00
08:29:25 l2tp,debug,packet (M) Assigned-Tunnel-ID=6
08:29:25 l2tp,debug,packet (M) Receive-Window-Size=4
08:29:25 l2tp,debug,packet sent control message (ack) to <my_live_pc_ip>:54385 from <my_router_local_ip>:1701
08:29:25 l2tp,debug,packet tunnel-id=6, session-id=0, ns=1, nr=1
08:29:26 l2tp,debug,packet sent control message to <my_live_pc_ip>:54385 from <my_router_local_ip>:1701
08:29:26 l2tp,debug,packet tunnel-id=6, session-id=0, ns=0, nr=1
08:29:26 l2tp,debug,packet (M) Message-Type=SCCRP
08:29:26 l2tp,debug,packet (M) Protocol-Version=0x01:00
08:29:26 l2tp,debug,packet (M) Framing-Capabilities=0x1
08:29:26 l2tp,debug,packet (M) Bearer-Capabilities=0x0
08:29:26 l2tp,debug,packet Firmware-Revision=0x1
08:29:26 l2tp,debug,packet (M) Host-Name="My VPN Server"
08:29:26 l2tp,debug,packet Vendor-Name="MikroTik"
08:29:26 l2tp,debug,packet (M) Assigned-Tunnel-ID=5
08:29:26 l2tp,debug,packet (M) Receive-Window-Size=4
08:29:29 l2tp,debug,packet rcvd control message from <my_live_pc_ip>:54385 to <my_router_local_ip>:1701
08:29:29 l2tp,debug,packet tunnel-id=0, session-id=0, ns=0, nr=0
08:29:29 l2tp,debug,packet (M) Message-Type=SCCRQ
08:29:29 l2tp,debug,packet (M) Protocol-Version=0x01:00
08:29:29 l2tp,debug,packet (M) Framing-Capabilities=0x3
08:29:29 l2tp,debug,packet (M) Host-Name=0x43:6f:6e:72:61:64:73:2d:4d:61:63:42:6f:6f:6b:2d
08:29:29 l2tp,debug,packet 50:72:6f:2e:6c:6f:63:61:6c:00
08:29:29 l2tp,debug,packet (M) Assigned-Tunnel-ID=6
08:29:29 l2tp,debug,packet (M) Receive-Window-Size=4
08:29:29 l2tp,debug,packet sent control message (ack) to <my_live_pc_ip>:54385 from <my_router_local_ip>:1701
08:29:29 l2tp,debug,packet tunnel-id=6, session-id=0, ns=1, nr=1
08:29:30 l2tp,debug,packet sent control message to <my_live_pc_ip>:54385 from <my_router_local_ip>:1701
08:29:30 l2tp,debug,packet tunnel-id=6, session-id=0, ns=0, nr=1
08:29:30 l2tp,debug,packet (M) Message-Type=SCCRP
08:29:30 l2tp,debug,packet (M) Protocol-Version=0x01:00
08:29:30 l2tp,debug,packet (M) Framing-Capabilities=0x1
08:29:30 l2tp,debug,packet (M) Bearer-Capabilities=0x0
08:29:30 l2tp,debug,packet Firmware-Revision=0x1
08:29:30 l2tp,debug,packet (M) Host-Name="My VPN Server"
08:29:30 l2tp,debug,packet Vendor-Name="MikroTik"
08:29:30 l2tp,debug,packet (M) Assigned-Tunnel-ID=5
08:29:30 l2tp,debug,packet (M) Receive-Window-Size=4
08:29:33 l2tp,debug,packet rcvd control message from <my_live_pc_ip>:54385 to <my_router_local_ip>:1701
08:29:33 l2tp,debug,packet tunnel-id=0, session-id=0, ns=0, nr=0
08:29:33 l2tp,debug,packet (M) Message-Type=SCCRQ
08:29:33 l2tp,debug,packet (M) Protocol-Version=0x01:00
08:29:33 l2tp,debug,packet (M) Framing-Capabilities=0x3
08:29:33 l2tp,debug,packet (M) Host-Name=0x43:6f:6e:72:61:64:73:2d:4d:61:63:42:6f:6f:6b:2d
08:29:33 l2tp,debug,packet 50:72:6f:2e:6c:6f:63:61:6c:00
08:29:33 l2tp,debug,packet (M) Assigned-Tunnel-ID=6
08:29:33 l2tp,debug,packet (M) Receive-Window-Size=4
08:29:33 l2tp,debug,packet sent control message (ack) to <my_live_pc_ip>:54385 from <my_router_local_ip>:1701
08:29:33 l2tp,debug,packet tunnel-id=6, session-id=0, ns=1, nr=1
08:29:37 l2tp,debug,packet rcvd control message from <my_live_pc_ip>:54385 to <my_router_local_ip>:1701
08:29:37 l2tp,debug,packet tunnel-id=0, session-id=0, ns=0, nr=0
08:29:37 l2tp,debug,packet (M) Message-Type=SCCRQ
08:29:37 l2tp,debug,packet (M) Protocol-Version=0x01:00
08:29:37 l2tp,debug,packet (M) Framing-Capabilities=0x3
08:29:37 l2tp,debug,packet (M) Host-Name=0x43:6f:6e:72:61:64:73:2d:4d:61:63:42:6f:6f:6b:2d
08:29:37 l2tp,debug,packet 50:72:6f:2e:6c:6f:63:61:6c:00
08:29:37 l2tp,debug,packet (M) Assigned-Tunnel-ID=6
08:29:37 l2tp,debug,packet (M) Receive-Window-Size=4
08:29:37 l2tp,debug,packet sent control message (ack) to <my_live_pc_ip>:54385 from <my_router_local_ip>:1701
08:29:37 l2tp,debug,packet tunnel-id=6, session-id=0, ns=1, nr=1
08:29:38 l2tp,debug,packet sent control message to <my_live_pc_ip>:54385 from <my_router_local_ip>:1701
08:29:38 l2tp,debug,packet tunnel-id=6, session-id=0, ns=0, nr=1
08:29:38 l2tp,debug,packet (M) Message-Type=SCCRP
08:29:38 l2tp,debug,packet (M) Protocol-Version=0x01:00
08:29:38 l2tp,debug,packet (M) Framing-Capabilities=0x1
08:29:38 l2tp,debug,packet (M) Bearer-Capabilities=0x0
08:29:38 l2tp,debug,packet Firmware-Revision=0x1
08:29:38 l2tp,debug,packet (M) Host-Name="My VPN Server"
08:29:38 l2tp,debug,packet Vendor-Name="MikroTik"
08:29:38 l2tp,debug,packet (M) Assigned-Tunnel-ID=5
08:29:38 l2tp,debug,packet (M) Receive-Window-Size=4
08:29:41 l2tp,debug,packet rcvd control message from <my_live_pc_ip>:54385 to <my_router_local_ip>:1701
08:29:41 l2tp,debug,packet tunnel-id=0, session-id=0, ns=0, nr=0
08:29:41 l2tp,debug,packet (M) Message-Type=SCCRQ
08:29:41 l2tp,debug,packet (M) Protocol-Version=0x01:00
08:29:41 l2tp,debug,packet (M) Framing-Capabilities=0x3
08:29:41 l2tp,debug,packet (M) Host-Name=0x43:6f:6e:72:61:64:73:2d:4d:61:63:42:6f:6f:6b:2d
08:29:41 l2tp,debug,packet 50:72:6f:2e:6c:6f:63:61:6c:00
08:29:41 l2tp,debug,packet (M) Assigned-Tunnel-ID=6
08:29:41 l2tp,debug,packet (M) Receive-Window-Size=4
08:29:41 l2tp,debug,packet sent control message (ack) to <my_live_pc_ip>:54385 from <my_router_local_ip>:1701
08:29:41 l2tp,debug,packet tunnel-id=6, session-id=0, ns=1, nr=1
08:29:41 l2tp,debug tunnel 5 received no replies, disconnecting
08:29:41 l2tp,debug tunnel 5 entering state: dead
-- Ctrl-C to quit. Space prints separator. New entries will appear at bottom.

SomeYoungGuy · Sat Jul 06, 2019 1:06 pm

[admin@My VPN Server] > export
# jul/06/2019 09:56:04 by RouterOS 6.34.1
# software id =
#
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ppp profile
set *0 only-one=yes
set *FFFFFFFE only-one=yes use-compression=yes use-mpls=no
/interface l2tp-server server
set enabled=yes max-mru=1500 max-mtu=1500
/interface pptp-server server
set enabled=yes max-mru=1500 max-mtu=1500
/ip dhcp-client
add default-route-distance=99 dhcp-options=hostname,clientid disabled=no interface=ether1
/ip firewall mangle
add action=mark-routing chain=prerouting new-routing-mark=b827ebd13eb8 passthrough=no src-address=172.16.0.3
/ip firewall nat
add action=masquerade chain=srcnat
/ip firewall service-port
set ftp disabled=yes
set tftp disabled=yes
set irc disabled=yes
set h323 disabled=yes
set sip disabled=yes
/ip ipsec peer
add address=0.0.0.0/0 exchange-mode=main-l2tp generate-policy=port-override secret=***Machine*Secret***
/ip route
add distance=2 gateway=*F00AB8 routing-mark=b827ebd13eb8
/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set api disabled=yes
set winbox port=<another port>
set api-ssl disabled=yes
/ppp secret
add local-address=10.0.0.1 name=<User1*> password=***** profile=default-encryption remote-address=10.0.0.2
add local-address=172.16.0.1 name=<User1*> password=***** remote-address=172.16.0.2 service=pptp
add local-address=10.0.0.1 name=<User1*> password=***** profile=default-encryption remote-address=10.0.0.3
add local-address=172.16.0.1 name=<User1*> password=***** profile=default-encryption remote-address=172.16.0.3
/system identity
set name="My VPN Server"
/system logging
add topics=l2tp

sindy · Sat Jul 06, 2019 1:40 pm

Nothing strange there (except the non-existent interface used as gateway of the manually added route which is unrelated to the issue).

While the connection attempt is ongoing, do /ip ipsec installed-sa print and check whether the outbound SA (with dst-address=the.ip.of.the.PC's.router) shows any packets/bytes to be sent and whether only two SAs exist in total.

And see what /ip route check the.ip.of.the.PC's.router tells you.

SomeYoungGuy · Mon Jul 08, 2019 9:47 am

This is the results:

/ip ipsec installed-sa print
Flags: A - AH, E - ESP
0 E spi=0x7E507F0 src-address=<live_pc_ip>:4500 dst-address=172.31.1.180:4500 state=mature auth-algorithm=sha1 enc-algorithm=aes-cbc
auth-key="491995ca8480d61xxxxxxxxxxxxxx21d18f2a8ee" enc-key="74f34e9b83d8c13ef7xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxd9078730677ef"
addtime=jul/08/2019 06:29:18 expires-in=59m41s add-lifetime=48m/1h current-bytes=470 replay=128

1 E spi=0xD5633EC src-address=172.31.1.180:4500 dst-address=<live_pc_ip>:4500 state=mature auth-algorithm=sha1 enc-algorithm=aes-cbc
auth-key="9a3f63abdafcb5xxxxxxxxxxxxxxxxxxx0b77c14" enc-key="6d6505b902158269xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx44842589b3787"
add-lifetime=48m/1h replay=128

Googleing "whats my ip" from my mac, show the same <live_pc_ip>

The default route seems fine

/ip route check <live_pc_ip>
status: ok
interface: ether1
nexthop: 172.31.0.1

I'm not sure why this is so difficult.

This really is an almost brand new instance off the shelf from AWS... In fact here is a challenge to anyone (including Mikrotik):
Go to AWS, sign up for a free-tier account, grab the Mikrotik Cloud Hosted Router, boot up your free instance, and get you mac/iphone to create a VPN to the router. Record the steps taken in the router and in AWS, and show them here. Assume that the mac/iphone is internet connected via an ISP, eg fiber or DSL (something you are not in control of)

SomeYoungGuy · Mon Jul 08, 2019 10:02 am

P.S. I created a "allow all" rule on the security group, just to make sure it wasn't the AWS firewall blocking something... same result.

sindy · Mon Jul 08, 2019 10:12 am

If you look at the installed-sa in your recent post, you'll see that the policy from the CHR to the PC did not transport a single packet. This indicates a routing issue at CHR side - the L2TP stack logs sending of packets but the policy doesn't match them. What does the "/ip route check ip.of.pc's router" command show?

SomeYoungGuy · Mon Jul 08, 2019 10:16 am

Ok, whats the fix?

/ip route check <live_pc_ip>
status: ok
interface: ether1
nexthop: 172.31.0.1

SomeYoungGuy · Mon Jul 08, 2019 10:28 am

Ok, so... thinking about this... im making an assumption... form the AWS side, im having to open ports with my typical thinking that the new connection is being established out side AWS, so the security group must open ports etc, to let traffic flow in... but now i have not looked at my ISP side... because well my normal thinking is that we are establishing a connection from inside my network (on my actual PC), and so therefor i don't need to do anything on my router as i have an "any outbound" rule (as is typical in any home/small office).

So, is L2TP - IPSEC - VPN different?? in that there are two "new" connections established...one from the client to the server and the other from the server to the (for the lack of a better word) "client". Although this wouldn't be the client in my case, it would be the router that left my network. I suppose this is why some posts say you can only use one connection "behind" a nated network.

So, Do I now need to DST-NAT my router back to my MAC?

sindy · Mon Jul 08, 2019 10:30 am

Sorry, reading it in a phone, I've missed the route check output in the post with installed-sa. Since the route seems fine, what does "ip ipsec policy print where dynamic" show?

sindy · Mon Jul 08, 2019 10:36 am

Do I now need to DST-NAT my router back to my MAC?

No, you don't. The firewalls can see only the IPsec layer, which is a UDP connection initiated by the client (PC) towards server's port 500, followed by another connection initiated in the same direction but to port 4500 once the existence of NAT is detected. The L2TP connection a) runs inside the IPsec one and as such it is invisible to the intermediate devices, and b) it is also initiated by the client (the PC), so the rule at CHR accepting input traffic to UDP port 1701 is sufficient, as the log shows. Since the outbound SA does not carry any traffic, the issue is inside the CHR.

SomeYoungGuy · Mon Jul 08, 2019 10:38 am

This is the output:

/ip ipsec policy print where dynamic
Flags: T - template, X - disabled, D - dynamic, I - inactive, * - default
0 D src-address=<EC2_live_instance_ip>/32 src-port=any dst-address=<my_route_live_ip>/32 dst-port=any protocol=udp action=encrypt level=require
ipsec-protocols=esp tunnel=no sa-src-address=<EC2_live_instance_ip> sa-dst-address=<my_route_live_ip> priority=2

1 D src-address=<EC2_live_instance_ip>/32 src-port=any dst-address=<my_route_live_ip>/32 dst-port=any protocol=udp action=encrypt level=require
ipsec-protocols=esp tunnel=no sa-src-address=<EC2_live_instance_ip> sa-dst-address=<my_route_live_ip> priority=2

<EC2_live_instance_ip> <- this is the IP i used to actually connect to the VPN Server.

SomeYoungGuy · Mon Jul 08, 2019 10:42 am

Do I now need to DST-NAT my router back to my MAC?
No, you don't. The firewalls can see only the IPsec layer, which is a UDP connection initiated by the client (PC) towards server's port 500, followed by another connection initiated in the same direction but to port 4500 once the existence of NAT is detected. The L2TP connection a) runs inside the IPsec one and as such it is invisible to the intermediate devices, and b) it is also initiated by the client (the PC), so the rule at CHR accepting input traffic to UDP port 1701 is sufficient, as the log shows. Since the outbound SA does not carry any traffic, the issue is inside the CHR.

Awesome... phew, that would have been complicated

sindy · Mon Jul 08, 2019 11:02 am

<EC2_live_instance_ip> <- this is the IP i used to actually connect to the VPN Server.

So it is a public IP? That doesn't make much sense to me but I don't know the AWS environment. Does it assign a public IP to the CHR or what? What do "/ip address print" and "/ip route print" on the CHR show?

SomeYoungGuy · Mon Jul 08, 2019 11:06 am

https://saputra.org/threads/setup-mikro ... server.31/

This guy seems to have a solution, that he said was tested on AWS.

SomeYoungGuy · Mon Jul 08, 2019 11:34 am

<EC2_live_instance_ip> <- this is the IP i used to actually connect to the VPN Server.
So it is a public IP? That doesn't make much sense to me but I don't know the AWS environment. Does it assign a public IP to the CHR or what? What do "/ip address print" and "/ip route print" on the CHR show?

The way AWS work is they cannot attach a "live" ip address to any instance, rather they have a firewall of sorts before the instances, that have a 1:1 forward from the "live" ip (exposed to the world), and the instance IP (attached to the NIC).

By default no traffic is forwarded on from the live ip to the instance ip, however using the security group, you can "allow" traffic inbound (and outbound, but that's default allow all out).

/ip address print
Flags: X - disabled, I - invalid, D - dynamic
# ADDRESS NETWORK INTERFACE
0 D 172.31.1.180/20 172.31.0.0 ether1
1 D 172.16.0.1/32 172.16.0.2 <pptp-User1****>

and

/ip route print
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 S 0.0.0.0/0 *F00AB8 2
1 ADS 0.0.0.0/0 172.31.0.1 99
2 ADC 172.16.0.2/32 172.16.0.1 <pptp-... 0
3 ADC 172.31.0.0/20 172.31.1.180 ether1 0

As you can see normal PPTP VPN connections work.

sindy · Mon Jul 08, 2019 11:43 am

The way AWS work is they cannot attach a "live" ip address to any instance, rather they have a firewall of sorts before the instances, that have a 1:1 forward from the "live" ip (exposed to the world), and the instance IP (attached to the NIC).

By default no traffic is forwarded on from the live ip to the instance ip, however using the security group, you can "allow" traffic inbound (and outbound, but that's default allow all out).

That's what I've supposed but in that case I don't get how the policy may have the public IP (as you've taken the effort to obfuscate it and as you wrote it is the one you've configured as the server address at the client PC) as its src-address because normally the IPsec stack should not even know anything about the public address as AWS dst-nats to its 172.31.1.180.

So if that was a noise and the policy's src-address is 172.31.1.180, I think something is broken in the 6.34.1 as you have two identical policies active at the same time (which is normally impossible), so everything may be properly configured but the policy with no security association linked to it may steal the outgoing packets and be unable to deliver them as it has no SA. The two security associations are both linked to the same policy, not one to each.

SomeYoungGuy · Mon Jul 08, 2019 11:48 am

Clicked "download & Install"... hold thumbs

SomeYoungGuy · Mon Jul 08, 2019 11:58 am

OH MY WORD... it worked!!!

Ok, so it now on "6.45.1" sable.
It rebooted... VPN connecting again failed, something about "no auth method found..." ok, so I went to ipsec peers, and removed what seemed like a converted peer from the old config. I noticed that the peer config is now totally different and contains almost no settings, but i had also noticed in fiddling around earlier that when you enable "Use IPSEC" in the LT2P Server settings, it made a readonly peer with what seemed to be pretty good default settings... So i enabled it there, and set the shared key, and.... Poof... VPN connected!

Wow... Thanks @sindy, awesome help

radrexvalera · Wed Aug 28, 2019 11:26 am

I currently having sleepless nights with AWS VPC too.

Scenario :

One of our clients send a downloaded config file ( Step by Step Instructions ) directly from their AWS VPC for us to configure on our Mikrotik CCR1036 running RouterOS 6.44.5. Unfortunately RouterOS 6.36 is the only available option in the drop down menu on AWS.

I tried to follow the said config file but unfortunately we can't still access the tunnel from AWS.

I hope I can get any helful information to figured this out.

Here's the file from AWS.

! Amazon Web Services
! Virtual Private Cloud

==============================================================================
VPN Connection Configuration
==============================================================================

! AWS utilizes unique identifiers to manipulate the configuration of
! a VPN Connection. Each VPN Connection is assigned an identifier and is
! associated with two other identifiers, namely the
! Customer Gateway Identifier and Virtual Private Gateway Identifier.

! Your VPN Connection ID : vpn-#######
! Your Virtual Private Gateway ID : vgw-#######
! Your Customer Gateway ID : cgw-#######

! This configuration consists of two tunnels. Both tunnels must be configured on your Customer Gateway, but only one of those tunnels should be up at any given time.
! Note that Mikrotik RouterOs does not support Active/Active or Active/Standby setup with AWS hosted VPN solution.

! At this time this configuration has only been tested for RouterOS 6.36, but may work with other versions.

! This configuration uses the Winbox utility to configure the IPsec VPN connection. Winbox is a small utility that allows administration of Mikrotik RouterOS using a fast and simple GUI.
! You can download this utility from: https://mikrotik.com/download

==============================================================================
! IPSec Tunnel #1
==============================================================================

! #1: IPSec Proposal Configuration
!
! An IPsec proposal defines the IPsec parameters for encryption, authentication, Diffie-Hellman, and lifetime.
! Please note, these sample configurations are for the minimum requirement of AES128, SHA1, and DH Group 2.
! Category "VPN" connections in the GovCloud region have a minimum requirement of AES128, SHA2, and DH Group 14.
! You will need to modify these sample configuration files to take advantage of AES256, SHA256, or other DH
! groups like 2, 14-18, 22, 23, and 24.
! Higher parameters are only available for VPNs of category "VPN," and not for "VPN-Classic".

Go to IP Tab --> IPsec --> Proposals

a. Click on "+" button
b. Name: ipsec-vpn-9414f5fd-0
c. Auth. Algorithms: sha1
d. Encr. Algorithms: aes-128-cbc
e. Lifetime: 01:00:00
f. PFS Group: modp1024
g. Select Apply and Ok

!---------------------------------------------------------------------------------
! #2: Internet Key Exchange
!
! A policy is established for the supported ISAKMP encryption, authentication, Diffie-Hellman, lifetime,
! and key parameters. The IKE peer is configured with the supported IKE encryption, authentication, Diffie-Hellman, lifetime, and key
! parameters.Please note, these sample configurations are for the minimum requirement of AES128, SHA1, and DH Group 2.
! Category "VPN" connections in the GovCloud region have a minimum requirement of AES128, SHA2, and DH Group 14.
! You will need to modify these sample configuration files to take advantage of AES256, SHA256, or other DH
! groups like 2, 14-18, 22, 23, and 24.
! Higher parameters are only available for VPNs of category "VPN," and not for "VPN-Classic".
! The address of the external interface for your customer gateway must be a static address.
! Your customer gateway may reside behind a device performing network address translation (NAT). To
! ensure that NAT traversal (NAT-T) can function, you must use the corresponding IP as the "Local Address".

! Create an IKE policy permitting traffic from your local subnet to the VPC subnet.

Go to IP Tab --> IPsec --> Policies

1) Click on "+" button and select the General Tab
a. Src. Address: local subnet/mask
b. Dst. Address: AWS VPC subnet/mask

2) Click on Action Tab
a. Select Tunnel
b. SA Src. Address: $WAN1 IP
c. SA Dst. Address: $Tunnel1 IP
d. Proposal: ipsec-vpn-9414f5fd-0
e. Select Apply and Ok

! Create an IKE policy permitting traffic from the Inside IP associated with your Customer Gateway to the inside IP associated with the Virtual Private Gateway.

Go to IP Tab --> IPsec --> Policies

3) Click on "+" button and select the General Tab
a. Src. Address: 169.254.34.10
b. Dst. Address: 169.254.34.9

4) Click on Action Tab
a. Select Tunnel
b. SA Src. Address: $WAN1 IP
c. SA Dst. Address: $Tunnel1 IP
d. Proposal: ipsec-vpn-9414f5fd-0
e. Select Apply and Ok

Go to IP Tab --> IPsec --> Peers

5) Click on "+" button
a. Address: $Tunnel1 IP
b. Local Address: $WAN1 IP
c. Secret: $Tunnel1 Secret
d. Hash Algorith: sha1
e. Encryption Algorithm: aes-128
d. DH Group: modp1024
f. Lifetime: 08:00:00
g. DPD Interval: 10
h. DPD Maximum Failures: 3
i. Select Apply and Ok

! ----------------------------------------------------------------------------
! #3: Tunnel Interface Configuration
!
! A tunnel interface is configured to be the logical interface associated
! with the tunnel. All traffic routed to the tunnel interface will be
! encrypted and transmitted to the VPC. Similarly, traffic from the VPC
! will be logically received on this interface.
! The address of the interface is configured with the setup for your
! Customer Gateway. If the address changes, the Customer Gateway and VPN
! Connection must be recreated with Amazon VPC.

Go to IP Tab --> Addresses

a. Click on "+" button
b. Address: 169.254.34.10/30
b. Interface: Select the WAN/Outside interface
c. Select Apply and Ok

! ----------------------------------------------------------------------------
! #4: Border Gateway Protocol (BGP) Configuration
!
! BGP is used within the tunnel to exchange prefixes between the
! Virtual Private Gateway and your Customer Gateway. The Virtual Private Gateway
! will announce the prefix corresponding to your VPC.
!
! The local BGP Autonomous System Number (ASN): 65000
! is configured as part of your Customer Gateway. If the ASN must
! be changed, the Customer Gateway and VPN Connection will need to be recreated with AWS.

Go to Routing Tab --> BGP --> Peer

a. Click on "+" button and select the General Tab
b. Name: BGP-vpn-######-0
c. Remote Address: 169.254.34.9
d. Remote AS: 7224
d. Hold Time: 30
e. Keepalive Time: 10
f. Select Apply and Ok

! Your Customer Gateway needs to advertise the local prefixes to AWS. An example for a local prefix with a subnet/mask of 10.0.0.0/16 is provided below:

Go to Routing Tab --> BGP --> Networks

a. Click on "+" button
b. Network: 10.0.0.0/16
c. Select Apply and Ok

! ----------------------------------------------------------------------------
! #5: NAT Exemption
!
! If you are performing NAT on your Customer Gateway, you may have to add a nat exemption rule to permit traffic from your local subnet to the VPC subnet and vice versa.
! This example rule permits all traffic from the local subnet to the VPC subnet.

Go to IP Tab --> Firewall --> NAT

1) Click on "+" button and select the General Tab
a. Chain: srcnat
b. Src. Address: local subnet/mask
c. Dst. Address: AWS VPC subnet/mask

2) Click on Action Tab
a. Action = accept
b. Select Apply and Ok

! Similarly, create a firewall rule permitting traffic from the Inside IP associated with your Customer Gateway to the IP associated with the Virtual Private Gateway.

3) Click on "+" button and select the General Tab
a. Chain: srcnat
b. Src. Address: 169.254.34.10
c. Dst. Address: 169.254.34.9

4) Click on Action Tab
a. Action = accept
b. Select Apply and Ok

! Note that there may be multiple firewall rules configured on your Customer Gateway. These rules may be conflicting with the nat exemption rule.
! It is recommended to position the nat exemption rules such that they are evaluated in an order before any other conflicting policy.
==============================================================================
! IPSec Tunnel #2
==============================================================================

! #1: IPSec Proposal Configuration
!
! An IPsec proposal defines the IPsec parameters for encryption, authentication, Diffie-Hellman, and lifetime.
! Please note, these sample configurations are for the minimum requirement of AES128, SHA1, and DH Group 2.
! Category "VPN" connections in the GovCloud region have a minimum requirement of AES128, SHA2, and DH Group 14.
! You will need to modify these sample configuration files to take advantage of AES256, SHA256, or other DH
! groups like 2, 14-18, 22, 23, and 24.
! Higher parameters are only available for VPNs of category "VPN," and not for "VPN-Classic".

Go to IP Tab --> IPsec --> Proposals

a. Click on "+" button
b. Name: ipsec-vpn-#######-1
c. Auth. Algorithms: sha1
d. Encr. Algorithms: aes-128-cbc
e. Lifetime: 01:00:00
f. PFS Group: modp1024
g. Select Apply and Ok

!---------------------------------------------------------------------------------
! #2: Internet Key Exchange
!
! A policy is established for the supported ISAKMP encryption, authentication, Diffie-Hellman, lifetime,
! and key parameters. The IKE peer is configured with the supported IKE encryption, authentication, Diffie-Hellman, lifetime, and key
! parameters.Please note, these sample configurations are for the minimum requirement of AES128, SHA1, and DH Group 2.
! Category "VPN" connections in the GovCloud region have a minimum requirement of AES128, SHA2, and DH Group 14.
! You will need to modify these sample configuration files to take advantage of AES256, SHA256, or other DH
! groups like 2, 14-18, 22, 23, and 24.
! Higher parameters are only available for VPNs of category "VPN," and not for "VPN-Classic".
! The address of the external interface for your customer gateway must be a static address.
! Your customer gateway may reside behind a device performing network address translation (NAT). To
! ensure that NAT traversal (NAT-T) can function, you must use the corresponding IP as the "Local Address".

! Create an IKE policy permitting traffic from your local subnet to the VPC subnet.

Go to IP Tab --> IPsec --> Policies

1) Click on "+" button and select the General Tab
a. Src. Address: local subnet/mask
b. Dst. Address: AWS VPC subnet/mask

2) Click on Action Tab
a. Select Tunnel
b. SA Src. Address: $WAN1 IP
c. SA Dst. Address: $Tunnel2 IP
d. Proposal: ipsec-vpn-9414f5fd-1
e. Select Apply and Ok

! Create an IKE policy permitting traffic from the Inside IP associated with your Customer Gateway to the inside IP associated with the Virtual Private Gateway.

Go to IP Tab --> IPsec --> Policies

3) Click on "+" button and select the General Tab
a. Src. Address: 169.254.33.6
b. Dst. Address: 169.254.33.5

4) Click on Action Tab
a. Select Tunnel
b. SA Src. Address: $WAN1 IP
c. SA Dst. Address: $Tunnel2 IP
d. Proposal: ipsec-vpn-9414f5fd-1
e. Select Apply and Ok

Go to IP Tab --> IPsec --> Peers

5) Click on "+" button
a. Address: $Tunnel2 IP
b. Local Address: $WAN1 IP
c. Secret: $Tunnel2 Secret
d. Hash Algorith: sha1
e. Encryption Algorithm: aes-128
d. DH Group: modp1024
f. Lifetime: 08:00:00
g. DPD Interval: 10
h. DPD Maximum Failures: 3
i. Select Apply and Ok

! ----------------------------------------------------------------------------
! #3: Tunnel Interface Configuration
!
! A tunnel interface is configured to be the logical interface associated
! with the tunnel. All traffic routed to the tunnel interface will be
! encrypted and transmitted to the VPC. Similarly, traffic from the VPC
! will be logically received on this interface.
! The address of the interface is configured with the setup for your
! Customer Gateway. If the address changes, the Customer Gateway and VPN
! Connection must be recreated with Amazon VPC.

Go to IP Tab --> Addresses

a. Click on "+" button
b. Address: 169.254.33.6/30
b. Interface: Select the WAN/Outside interface
c. Select Apply and Ok

! ----------------------------------------------------------------------------
! #4: Border Gateway Protocol (BGP) Configuration
!
! BGP is used within the tunnel to exchange prefixes between the
! Virtual Private Gateway and your Customer Gateway. The Virtual Private Gateway
! will announce the prefix corresponding to your VPC.
!
! The local BGP Autonomous System Number (ASN): 65000
! is configured as part of your Customer Gateway. If the ASN must
! be changed, the Customer Gateway and VPN Connection will need to be recreated with AWS.

Go to Routing Tab --> BGP --> Peer

a. Click on "+" button and select the General Tab
b. Name: BGP-vpn-#######-1
c. Remote Address: 169.254.33.5
d. Remote AS: 7224
d. Hold Time: 30
e. Keepalive Time: 10
f. Select Apply and Ok

! Your Customer Gateway needs to advertise the local prefixes to AWS. An example for a local prefix with a subnet/mask of 10.0.0.0/16 is provided below:

Go to Routing Tab --> BGP --> Networks

a. Click on "+" button
b. Network: 10.0.0.0/16
c. Select Apply and Ok

! ----------------------------------------------------------------------------
! #5: NAT Exemption
!
! If you are performing NAT on your Customer Gateway, you may have to add a nat exemption rule to permit traffic from your local subnet to the VPC subnet and vice versa.
! This example rule permits all traffic from the local subnet to the VPC subnet.

Go to IP Tab --> Firewall --> NAT

1) Click on "+" button and select the General Tab
a. Chain: srcnat
b. Src. Address: local subnet/mask
c. Dst. Address: AWS VPC subnet/mask

2) Click on Action Tab
a. Action = accept
b. Select Apply and Ok

! Similarly, create a firewall rule permitting traffic from the Inside IP associated with your Customer Gateway to the IP associated with the Virtual Private Gateway.

3) Click on "+" button and select the General Tab
a. Chain: srcnat
b. Src. Address: 169.254.33.6
c. Dst. Address: 169.254.33.5

4) Click on Action Tab
a. Action = accept
b. Select Apply and Ok

! Note that there may be multiple firewall rules configured on your Customer Gateway. These rules may be conflicting with the nat exemption rule.
! It is recommended to position the nat exemption rules such that they are evaluated in an order before any other conflicting policy.
!---------------------------------------------------------------------------------------
!
! Additional Notes and Questions
! - Amazon Virtual Private Cloud Getting Started Guide:
! http://docs.amazonwebservices.com/Amazo ... artedGuide
! - Amazon Virtual Private Cloud Network Administrator Guide:
! http://docs.amazonwebservices.com/Amazo ... AdminGuide
! - Generic VPN tunnel connectivity Connectivity:
! https://aws.amazon.com/premiumsupport/k ... eshooting/
!
!---------------------------------------------------------------------------------------

VPN Server on Cloud Router at AWS

VPN Server on Cloud Router at AWS

Re: VPN Server on Cloud Router at AWS

Re: VPN Server on Cloud Router at AWS

Re: VPN Server on Cloud Router at AWS

Re: VPN Server on Cloud Router at AWS

Re: VPN Server on Cloud Router at AWS

Re: VPN Server on Cloud Router at AWS

Re: VPN Server on Cloud Router at AWS

Re: VPN Server on Cloud Router at AWS

Re: VPN Server on Cloud Router at AWS

Re: VPN Server on Cloud Router at AWS

Re: VPN Server on Cloud Router at AWS

Re: VPN Server on Cloud Router at AWS

Re: VPN Server on Cloud Router at AWS

Re: VPN Server on Cloud Router at AWS

Re: VPN Server on Cloud Router at AWS

Re: VPN Server on Cloud Router at AWS

Re: VPN Server on Cloud Router at AWS

Re: VPN Server on Cloud Router at AWS

Re: VPN Server on Cloud Router at AWS

Re: VPN Server on Cloud Router at AWS

Re: VPN Server on Cloud Router at AWS

Re: VPN Server on Cloud Router at AWS

Re: VPN Server on Cloud Router at AWS

Re: VPN Server on Cloud Router at AWS

Re: VPN Server on Cloud Router at AWS

Re: VPN Server on Cloud Router at AWS

Re: VPN Server on Cloud Router at AWS

Re: VPN Server on Cloud Router at AWS

Who is online