Sorry, I have probably mislead you due to reading what you wrote carelessly. You wrote “with packets being captured” which to me automatically means capturing packets on the interfaces into a .pcap file, so I’ve missed the “in the MT log” part.
As said before, the Mikrotik does not log Phase 2 packets; the !packets in the log settings just prevents the hex dump of the encrypted Phase 1 packets from being included in the log, so only their contents is shown there if this setting is present. I am actually surprised that in the log you have posted now, there are no rows without the packet keyword, so it feels as something else went wrong too.
So my assumption was that you would be logging the connection attempt with the same logging settings as before and using the same command like before, but in parallel you would capture the traffic on the WAN interface using /tool/sniffer/quick, matching on the current public IP address of the phone, into a .pcap file that you would later download and open using Wireshark. But a simpler procedure can be used actually - we do not need to see the transport (Phase 2) packets in a capture file, it is enough to see them counted by the Mikrotik itself. So in parallel to the logging, run /ip/ipsec/installed-sa/print interval=1s when the Strongswan shows the connection as active, and watch whether the SA from the phone to the Mikrotik counts any packets coming in.
Even worse, as I was tuned to debugging the Phase 1 and Phase 2 negotiation, I forgot that you have created some firewall rules on your own; the thing with IPsec is that the payload packets that get decrypted and deencapsulated from the transport ones inherit the in-interface attribute from those transport ones, so if your firewall rules prevent packets that come in via the WAN interface from getting anywhere further without checking whether they came directly or whether they are decapsulated IPsec payload ones, the “pings” from your mobile cannot get responded because the router doesn’t allow the requests to even reach their destination hosts in LAN.
So maybe you’d better postpone any logging and sniffing and start from posting the output of /ip/firewall/export ?
To address your issue, you can try the following steps:
Use TCP for VPN Traffic: By default, IPSec/IKEv2 uses UDP ports 500 and 4500. To get around public WiFi restrictions, you can configure your VPN to use TCP port 443, which is usually open.
Change VPN Server Configuration: Modify your VPN server configuration to listen on TCP port 443 instead of the default UDP ports. This typically involves editing your VPN server’s configuration file. For example, if you’re using strongSwan, add the following lines to your ipsec.conf:
conf
conn your-connection-name
…
leftprotoport=tcp/443
…
Firewall Configuration: Ensure your firewall rules allow TCP traffic on port 443. This might involve adding or modifying rules in your firewall [https://techscrawl.com/]configuration[/url]:
sh
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT
Avoid Port Clashes: Since port 443 is already in use for HTTPS (www-ssl service), you can set up a different subdomain specifically for the VPN traffic and configure it to use port 443. This way, you won’t interfere with your existing HTTPS service.
Configure your web server (e.g., Apache or Nginx) to serve only the root domain and leave the subdomain for VPN.
Update your DNS settings to point the subdomain to the VPN server.
Update Client Configuration: Make sure your VPN client (your Android smartphone) is configured to connect to the VPN using TCP on port 443.
In the VPN settings on your Android device, specify the use of TCP and port 443.
By making these changes, you should be able to use your VPN on public WiFi networks that might be blocking standard VPN ports.
Ok no worries, these commands are new to me so I need to go step by step. I wasn’t aware the ROS terminal window could be used for a second task whilst the ‘/log print…’ command was running?
So, if I understand correctly, I should now do this, once you’ve advised on the firewall settings below:
Using MT terminal: /log print follow-only file=ipsec-start where topics~“ipsec”
Start VPN connection on mobile & mobile data usage with StrongSwan
Wait for StrongSwan connection to appear established in mobile UI
Using MT terminal: /ip/ipsec/installed-sa/print interval=1s
Once the above is running should I then be trying to ping an address on my LAN from the mobile? Should this be a particular port, address and protocol?
It indeed cannot, but you can open multiple terminal windows and use them in parallel, which is what I had in mind.
Yes, you should be trying to create some traffic from the mobile towards and address in your LAN while observing the packet&byte counters to grow (or not). No particular protocol or port are necessary, the IPsec policy doesn’t restrict that.
This is the rule that allows any IPsec payload to get through to LAN, even though it came encrypted via WAN. The next rule prevents the IPsec payload traffic in the opposite direction from hitting the fasttrack-connection rule, which would prevent the IPsec policies from getting the subsequent packets of the connection for inspection. So all the necessary bits are in place in the firewall and a missing/excess firewall rule is not the reason why the pings do not get responded. So the “or not” above is the more likely outcome, but let’s see.
I’m just having a look at doing this latest test but should the following command also show me an extra column or rather how do I add an extra column to show some throughput of data please?
/ip/ipsec/installed-sa/print interval=1s
Flags: S - SEEN-TRAFFIC; E - ESP
Columns: SPI, STATE, SRC-ADDRESS, DST-ADDRESS, ENC-ALGORITHM, ENC-KEY-SIZE
SPI STATE SRC-ADDRESS DST-ADDRESS ENC-ALGORITHM ENC-KEY-SIZE
0 SE 0xB57ABF9 mature {REDACTED - my.phone.ip}:63807 my.tik.pub.ip:4500 aes-gcm 288
1 SE 0x4E6B5B21 mature my.tik.pub.ip:4500 {REDACTED - my.phone.ip}:63807 aes-gcm 288
I also note when trying this test out, when I just had a look at either of the IPSec SA entries in a different ROS window, that they show Auth. Algorithm: none and nothing for Auth. key. Is this something it is meant to be establishing itself or are these empty or set to ‘none’ because I’m using client certs?
Just to clarify at the moment the issue is with getting IPSec/IKEv2 road warrior configuration to work in its conventional form using ports 500 and 4500. This is currently not working with my mobile data connection. For the time being the public WiFi issue has been removed from the scenario to try and establish why the basics aren’t working as expected. There appears to currently be an authentication issue, early on in a connection attempt there are two proposal lists of attributes, not all of which represent what was ticked in the MT proposal. However, a proposal match appears to be made but followed by a KE & DH group mismatch. Although a message is written to the log ‘INVALID_KE_PAYLOAD’ this is only a notification and doesn’t prevent the process from continuing even though it seems to be pursuing the impossible at this stage.
Ah, sorry, I forgot again that in ROS 7 you have to use /ip/ipsec/installed-sa/print detail to see the byte and packet counters. In the basic view, you have just the S (Seen Traffic) indicator which tells you there was some traffic (1 or more packets) but you don’t know the amount. But already the presence of S on both rows you’ve seen means that the SAs are indeed established and used in both directions, so now I am surprised that the pings from the phone stay unresponded.
The presence/absence of auth algorithm and key among parameters of the SA is unrelated to how the peers are authenticated to each other. In case of the transport packets, “authentication” means a verification that the traffic comes from a legitimate source which is used to prevent “replay attacks” where an attacker would record part of traffic and then send it to the recipient. So the receiver uses the auth-algorithm and auth-key to check that received packets have expected sequence numbers ciphered using that algo and key and ignores those that don’t. Some encryption ciphers support encryption alone and thus a separate authenticaton cipher is necessary for the authentication (like in one of my setups, AUTH-ALGORITHM=sha256, ENC-ALGORITHM=aes-cbc) whereas other ciphers have the authentication function integrated into the encryption one (like in your setup, ENC-ALGORITHM=aes-gcm) so no separate authentication algo and key are necessary. And whilst the console only shows columns that have some contents on at least one row, Winbox apparently always shows all of them.
Ok I will rerun the test in a bit. It actually got a bit odder earlier when I tried as I wasn’t getting any response when I pinged my PC but when I tried 192.168.1.1 with ICMP then I received a response, this address relates to the gateway and dns server addresses on my LAN.
Just a brief test here but when the connection was seemingly established, according to StrongSwan, I ran the ‘installed sa’ command which shows some packets present prior to trying to ping my LAN. Only my mobile data is switched on, on the mobile, no WiFi to my LAN. I then used PingTools on the phone to try pinging my PC using the ICMP protocol without any success, 3 packets sent and no repsonses received. However, when I tried the LAN address of my gateway and DNS server I did get a response. The second running of the ‘installed sa’ command took place after both ping attempts had been made.
/ip/ipsec/installed-sa/print detail
Flags: S - seen-traffic; H - hw-aead; A - AH, E - ESP
0 S E spi=0x536EFE3 src-address={REDACTED - my.phone.ip}:63802 dst-address=my.tik.pub.ip:4500 state=mature enc-algorithm=aes-gcm enc-key-size=288
enc-key=“{REDACTED}” addtime=2024-07-27 19:35:57 expires-in=7h59m30s
add-lifetime=6h24m16s/8h21s current-bytes=6344 current-packets=65 replay=128
1 S E spi=0x202FABA8 src-address=my.tik.pub.ip:4500 dst-address={REDACTED - my.phone.ip}:63802 state=mature enc-algorithm=aes-gcm enc-key-size=288
enc-key=“{REDACTED}” addtime=2024-07-27 19:35:57 expires-in=7h59m30s
add-lifetime=6h24m16s/8h21s current-bytes=19854 current-packets=59 replay=128
/ip/ipsec/installed-sa/print detail
Flags: S - seen-traffic; H - hw-aead; A - AH, E - ESP
0 S E spi=0x536EFE3 src-address={REDACTED - my.phone.ip}:63802 dst-address=my.tik.pub.ip:4500 state=mature enc-algorithm=aes-gcm enc-key-size=288
enc-key=“{REDACTED}” addtime=2024-07-27 19:35:57 expires-in=7h58m3s
add-lifetime=6h24m16s/8h21s current-bytes=34158 current-packets=206 replay=128
1 S E spi=0x202FABA8 src-address=my.tik.pub.ip:4500 dst-address={REDACTED - my.phone.ip}:63802 state=mature enc-algorithm=aes-gcm enc-key-size=288
enc-key=“{REDACTED}” addtime=2024-07-27 19:35:57 expires-in=7h58m3s
add-lifetime=6h24m16s/8h21s current-bytes=81195 current-packets=187 replay=128
The default behavior of the Windows firewall is to only respond to ping requests whose source address is in the same subnet like the address being pinged. So if your PC is a Windows one, this is the most likely explanation why you cannot ping it via the tunnel.
Well, since there is so much traffic in both directions, the purpose of seeing whether the pings generate some encrypted traffic in the individual directions becomes kind of irrelevant. Since you can successfully ping the address of the Mikrotik itself through the tunnel, I would assume the IPsec part is working despite the suspicious complaints in the Strongswan log.
And if the DNS server you’ve mentioned above is not the Mikrotik but some other device, it is even confirmed that the firewall rules on the Mikrotik are permissive enough to allow the phone to access devices in the LAN subnet via the tunnel.
Yes it is a Windows PC so that make sense regarding pinging.
As for the amount of traffic does that seem abnormally high considering the connection was only for about a minute with just two ping attempts being made?
I’ve reenabled the port 443 in StrongSwan and found it to be working as far as I can tell to the way it has been over ports 500 and 4500 so I shall take a trip to the library in the next few days to see if this works.
Are you familiar with the settings in StrongSwan? I was wondering if I could narrow the proposal options by setting an IKEv2 algorithm and IPsec/ESP algorithm (these are both string entry fields) to see if that alleviates the more complex handshake that seems to take place at present.
Yes the DNS server is the one in the MT router / ROS, it’s shown alongside the IP for the gateway, they both share the same IP, is that normal?
It doesn’t, since all the traffic of the mobile gets routed via the IPsec tunnel once it is up - I assume you haven’t configured “split tunneling”.
Sure you can reduce the lists of Phase 1 and Phase 2 proposals, but I don’t expect the weird issues we observe to disappear. Only the initial retry with a different set of proposals in Phase 1 will not be there.
Yes, it is normal. Your wording just suggested that you have some Pi-hole or other standalone DNS server; if it was the case, we would be sure that the forward chain of packet handling is working too, but the fact that there was much more bi-directional traffic than what would be proportional to the pinging confirms this as well.