I want to forward only some destination address to the wireguard table, but I can’t figure out the cause of the problems with macOS. Please tell me what’s wrong with the setup
Current CHR:
The screenshot doesn’t show how the Router and Windows machine resolve ping.eu…
What is the IPv4 address that macOS machine obtains from its LAN, can you confirm its network configuration (DHCP?) doesn’t overlap with the IPsec network?
X:\Windows\System32>ping ping.eu
Pinging ping.eu [88.198.46.60] with 32 bytes of data:
Reply from 88.198.46.60: bytes=32 time=63ms TTL=53
Reply from 88.198.46.60: bytes=32 time=63ms TTL=53
Reply from 88.198.46.60: bytes=32 time=63ms TTL=53
Reply from 88.198.46.60: bytes=32 time=62ms TTL=53
Ping statistics for 88.198.46.60:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 62ms, Maximum = 63ms, Average = 62ms
[macOS:ping ping.eu
PING ping.eu (88.198.46.60): 56 data
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
Request timeout for icmp_seq 7
Request timeout for icmp_seq 8
Request timeout for icmp_seq 9
^C
--- ping.eu ping statistics ---
11 packets transmitted, 0 packets received, 100.0% packet bytes loss
Judging by the trace in the previous screenshot, the packets from macOS 192.168.1.3 are stuck at CHR 192.168.1.1.
The IPv4 address on mac OS can be any on several ISP, but it does not overlap in any way 192.168.0.0/16.
Maybe CHR cannot route ping.eu into the wireguard1.
From your description it appears to me that the very same route works for the Windows machine. I also don’t immediately see in the config that RouterOS would treat Windows traffic any different from macOS traffic.
To rule out the firewall, set identity’s notrack-chain to prerouting. With this setting RouterOS will dynamically add rules in /ip/firewall/raw after the connection is established. Make sure you have something like “chain=forward action=accept connection-state=untracked” high enough for this to work.
Would you mind sharing netstat -rn -f inet and ifconfig -a inet from the macOS machine after the IPsec connection is established?
I also tried to do it on iOS, the problem is the same - everything works through ike2, but sites from the dst-address-list do not load.
Sorry, i cant see “chain=forward action=accept connection-state=untracked” in raw with enabled identity’s “notrack-chain”.
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
options=1203<RXCSUM,TXCSUM,TXSTATUS,SW_TIMESTAMP>
inet 127.0.0.1 netmask 0xff000000
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=424<VLAN_MTU,TSO4,CHANNEL_IO>
inet 192.168.200.128 netmask 0xffffff00 broadcast 192.168.200.255
utun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
utun1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 2000
utun2: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1000
ipsec0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
options=6463<RXCSUM,TXCSUM,TSO4,TSO6,CHANNEL_IO,PARTIAL_CSUM,ZEROINVERT_CSUM>
inet 192.168.1.3 --> 192.168.1.3 netmask 0xffffffff
Everything appears as expected. At this point I’d start probing with /tool/sniffer and Wireshark to see where the traffic gets dropped.
Are you positive that the Windows machine indeed routes traffic to ping.eu via IPsec connection? It might be possible that it fails just like macOS / iOS, but then successfully routes (leaks) traffic via its normal gateway.
