VPN Server on Cloud Router at AWS

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?

are you using l2tp over ipsec?

Im using a Mac, or an iPhone

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.

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

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?

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 > > :54385 from > > :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.

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

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.


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.

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.

[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=MachineSecret

/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=
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

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.

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)

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.

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?

Ok, whats the fix?

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

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?

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?

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.