Mikrotik and Sophos IPSec Site to Site

Hi NathanOhara 

Could you please verify that the Ping local service ACL permission is enabled for your VPN zone? Located in System > Administration > Device Access. As well, what are you able to observe when performing a packet capture for this LAN to VPN ICMP traffc?

Regards,

FloSupport | Community Support Engineer

Ethernet Header
Source MAC Address:00:22:0d:12:4b:41
Destination MAC Address: a0:36:9f:bc:de:14
Ethernet Type IPv4 (0x800)

IPv4 Header
Source IP Address:10.0.100.21
Destination IP Address:192.168.87.1
Protocol: ICMP
Header:20 Bytes
Type of Service: 0
Total Length: 84 Bytes
Identification:26043
Fragment Offset:16384
Time to Live: 62
Checksum: 20783

ICMP Header:
Type: 8
Code: 0
Echo ID: 14654
Echo Sequence: 5
Gateway: 0
Fragmentation MTU: 0
Checksum: 18087

Ethernet Header
Source MAC Address:00:22:0d:12:4b:41
Destination MAC Address: a0:36:9f:bc:de:14
Ethernet Type IPv4 (0x800)

IPv4 Header
Source IP Address:10.0.100.21
Destination IP Address:192.168.87.252
Protocol: ICMP
Header:20 Bytes
Type of Service: 0
Total Length: 84 Bytes
Identification:8903
Fragment Offset:16384
Time to Live: 62
Checksum: 37672

ICMP Header:
Type: 8
Code: 0
Echo ID: 14763
Echo Sequence: 8
Gateway: 0
Fragmentation MTU: 0
Checksum: 31536

Here is Rule ID 18

Hi NathanOhara 

It appears from the log entry that your XG is passing the ICMP traffic along properly. Could you please perform a traceroute from the client behind the XG, going to the Mikrotic remote LAN, and verify where the traffic is getting stopped? Have you also tried to pass other types of traffic along the VPN tunnel? (RDP, FTP, etc.)

Thanks,

FloSupport | Community Support Engineer

Yes, I have tried SSH, RDP, etc. nothing works. Traceroute stops at the XG Firewall which is 10.0.0.1

pepsi@10.0.100.21:~$ traceroute 192.168.87.252
traceroute to 192.168.87.252 (192.168.87.252), 30 hops max, 60 byte packets
1 10.0.100.1 (10.0.100.1) 2.881 ms 3.095 ms 3.336 ms
2 10.0.0.1 (10.0.0.1) 0.099 ms 0.087 ms 0.101 ms
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *

What are you able to observe when you perform a TCPDump from the CLI of the XG?
Ex: tcpdump -eni <interface> host 192.168.87.252

Could you also please share the rest of the configuration settings of your firewall rule 18?

Regards,

FloSupport | Community Support Engineer

It seems as if the pings are going through but I am not getting any replies. How do I verify that the data is going through the correct interface?

console> tcpdump 'dst host 192.168.87.252'
tcpdump: Starting Packet Dump
17:25:00.145241 Port1, IN: IP 10.0.100.21 > 192.168.87.252: ICMP echo request, id 22511, seq 4, length 64
17:25:01.153196 Port1, IN: IP 10.0.100.21 > 192.168.87.252: ICMP echo request, id 22511, seq 5, length 64
17:25:02.161222 Port1, IN: IP 10.0.100.21 > 192.168.87.252: ICMP echo request, id 22511, seq 6, length 64
17:25:03.169253 Port1, IN: IP 10.0.100.21 > 192.168.87.252: ICMP echo request, id 22511, seq 7, length 64
17:25:04.177229 Port1, IN: IP 10.0.100.21 > 192.168.87.252: ICMP echo request, id 22511, seq 8, length 64
17:25:05.185235 Port1, IN: IP 10.0.100.21 > 192.168.87.252: ICMP echo request, id 22511, seq 9, length 64
17:25:06.193271 Port1, IN: IP 10.0.100.21 > 192.168.87.252: ICMP echo request, id 22511, seq 10, length 64
17:25:07.201264 Port1, IN: IP 10.0.100.21 > 192.168.87.252: ICMP echo request, id 22511, seq 11, length 64
17:25:08.209305 Port1, IN: IP 10.0.100.21 > 192.168.87.252: ICMP echo request, id 22511, seq 12, length 64
17:25:09.217293 Port1, IN: IP 10.0.100.21 > 192.168.87.252: ICMP echo request, id 22511, seq 13, length 64
17:25:10.225245 Port1, IN: IP 10.0.100.21 > 192.168.87.252: ICMP echo request, id 22511, seq 14, length 64
17:25:11.233409 Port1, IN: IP 10.0.100.21 > 192.168.87.252: ICMP echo request, id 22511, seq 15, length 64
^C
12 packets captured
12 packets received by filter
0 packets dropped by kernel


Here is the traceroute from 192.168.87.252

pepsi@192.168.87.252:~$ traceroute 10.0.100.21
traceroute to 10.0.100.21 (10.0.100.21), 30 hops max, 60 byte packets
1 192.168.87.1 (192.168.87.1) 0.219 ms 0.256 ms 0.302 ms
2 * * *
3 * * *
4 10.0.100.21 (10.0.100.21) 29.278 ms 29.283 ms 29.263 ms

Here is the show vpn connection status from console.

console> show vpn connection status
Status of IKE charon daemon (strongSwan 5.5.3, Linux 3.14.22-Aum, x86_64):
uptime: 7 days, since Feb 07 11:06:49 2018
malloc: sbrk 2555904, mmap 0, used 654976, free 1900928
worker threads: 27 of 32 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 12
loaded plugins: charon aes des rc2 sha2 sha3 sha1 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf curve25519 xcbc cmac hmac attr kernel-netlink socket-default stroke vici xauth-generic xauth-access-server ippool-access-server cop-updown garner-logging error-notify unity
Listening IP addresses:
169.254.234.5
10.0.0.1
67.xxx.xxx.168
192.168.24.1
10.255.0.1
Connections:
Remote-1: 67.xxx.xxx.168...24.xxx.xxx.222 IKEv2, dpddelay=30s
Remote-1: local: [67.xxx.xxx.168] uses pre-shared key authentication
Remote-1: remote: [24.xxx.xxx.222] uses pre-shared key authentication
Remote-1: child: 10.0.100.0/24 === 192.168.87.0/24 TUNNEL, dpdaction=clear
Security Associations (1 up, 0 connecting):
Remote-1[268]: ESTABLISHED 19 minutes ago, 67.xxx.xxx.168[67.xxx.xxx.168]...24.xxx.xxx.222[24.xxx.xxx.222]
Remote-1[268]: IKEv2 SPIs: 16c6ebe3c9b018c1_i* 4c96c2335dbfc1ce_r, rekeying in 60 minutes
Remote-1[268]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
Remote-1{1577}: INSTALLED, TUNNEL, reqid 11, ESP SPIs: ca2388bd_i 085a27cd_o
Remote-1{1577}: AES_CBC_256/HMAC_SHA2_256_128/MODP_2048, 0 bytes_i, 0 bytes_o, rekeying in 27 minutes
Remote-1{1577}: 10.0.100.0/24 === 192.168.87.0/24

Can you try to change the ARP setting on the Mikrotik device for the interface which is the local subnet interface? 

Try to change it it proxy-arp.