IPsec tunnel not working

TarekH · Thu Jan 02, 2025 11:56 am

hello
I have an IPsec tunnel set between a Sophos XG and a mikrotik
connection is established but no data is passing
Both devices have public ips
firewall rules set on both devices but still nothing
Sophos engineers checked their side - all is good
what am i missing ?

/interface bridge
add name=bridge-LAN port-cost-mode=short
/interface ethernet
set [ find default-name=ether1 ] mac-address=74:4D:28:A6:86:06 name=ether1-WAN-MAIN-DSL-MODEM
set [ find default-name=ether2 ] mac-address=74:4D:28:A6:86:07
set [ find default-name=ether3 ] mac-address=74:4D:28:A6:86:08
set [ find default-name=ether4 ] mac-address=74:4D:28:A6:86:09
set [ find default-name=ether5 ] advertise=100M-baseT-half,100M-baseT-full,1G-baseT-half,1G-baseT-full mac-address=74:4D:28:A6:86:0A
set [ find default-name=ether10 ] mac-address=74:4D:28:A6:86:0B name=ether6
set [ find default-name=ether9 ] mac-address=74:4D:28:A6:86:0C name=ether7
set [ find default-name=ether8 ] mac-address=74:4D:28:A6:86:0D
set [ find default-name=ether7 ] mac-address=74:4D:28:A6:86:0E name=ether9
set [ find default-name=ether6 ] mac-address=74:4D:28:A6:86:0F name=ether10
/interface wireguard
add listen-port=13231 mtu=1380 name=Mikrotik-Leb
/interface ethernet switch port
set 5 default-vlan-id=0
set 6 default-vlan-id=0
set 7 default-vlan-id=0
set 8 default-vlan-id=0
set 9 default-vlan-id=0
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface lte apn
set [ find default=yes ] ip-type=ipv4 use-network-apn=no
/ip ipsec profile
set [ find default=yes ] dpd-interval=2m dpd-maximum-failures=5
add dh-group=modp2048 enc-algorithm=aes-256 hash-algorithm=sha256 name=socitrans nat-traversal=no
/ip ipsec peer
add address=xxx.xxx.xxx.78/32 exchange-mode=ike2 name=socitrans-peer profile=socitrans
/ip ipsec proposal
add auth-algorithms=sha512,sha256 enc-algorithms=aes-256-cbc,aes-256-ctr,aes-256-gcm name=socitrans-proposal pfs-group=modp2048
/ip pool
add name=dhcp_pool0 ranges=192.168.1.112-192.168.1.199
add name=dhcp_poolVPN ranges=192.168.251.2-192.168.251.254
/ip dhcp-server
add address-pool=dhcp_pool0 interface=bridge-LAN name=dhcp1
/ip smb users
set [ find default=yes ] disabled=yes
/port
set 0 name=serial0
/ppp profile
set *0 only-one=no
add dns-server=192.168.1.1 local-address=dhcp_pool0 name=profile1 only-one=no remote-address=dhcp_poolVPN
/routing bgp template
set default disabled=no output.network=bgp-networks
/routing ospf instance
add disabled=no name=default-v2
/routing ospf area
add disabled=yes instance=default-v2 name=backbone-v2
/system logging action
set 0 memory-lines=1111
set 1 disk-lines-per-file=11111
/interface bridge port
add bridge=bridge-LAN interface=ether2
add bridge=bridge-LAN interface=ether3
add bridge=bridge-LAN interface=ether4
add bridge=bridge-LAN interface=ether5
add bridge=bridge-LAN interface=ether6
add bridge=bridge-LAN interface=ether7
add bridge=bridge-LAN interface=ether8
add bridge=bridge-LAN interface=ether9
add bridge=bridge-LAN interface=ether10
add bridge=bridge-LAN interface=ether11
add bridge=bridge-LAN interface=ether12
add bridge=bridge-LAN interface=ether13
/ip firewall connection tracking
set udp-timeout=10s
/ip neighbor discovery-settings
set discover-interface-list=all
/ip settings
set max-neighbor-entries=8192
/ipv6 settings
set forward=no max-neighbor-entries=8192
/interface l2tp-server server
set default-profile=profile1 enabled=yes keepalive-timeout=60 max-mru=1400 max-mtu=1400 mrru=1600 use-ipsec=yes
/interface list member
add comment=defconf interface=bridge-LAN list=LAN
add comment=defconf interface=ether1-WAN-MAIN-DSL-MODEM list=WAN
/interface ovpn-server server
set auth=sha1,md5
/interface wireguard peers
add allowed-address=192.168.120.0/24,10.125.100.0/24,192.168.1.0/24,192.168.130.0/24 comment=DRC endpoint-address=xxx.xxx.xxx.186 endpoint-port=13231 interface=Mikrotik-Leb is-responder=yes name=peer1 persistent-keepalive=10s public-key=\

/ip address
add address=192.168.1.111/24 interface=bridge-LAN network=192.168.1.0
add address=yyy.yyy.yyy174/29 interface=ether1-WAN-MAIN-DSL-MODEM network=yyy.yyy.yyy168
add address=10.125.100.101/24 interface=Mikrotik-Leb network=10.125.100.0
/ip arp
add address=192.168.1.112 interface=bridge-LAN mac-address=00:45:E2:F6:AB:D7
/ip dhcp-client
add disabled=yes interface=bridge-LAN
/ip dhcp-server network
add address=192.168.1.0/24 dns-server=192.168.1.1 gateway=192.168.1.111
/ip dns
set allow-remote-requests=yes servers=xxxxxxxx
/ip dns static
add address=192.168.88.1 name=router.lan type=A
/ip firefirewall filter
add action=accept chain=forward dst-address=192.168.1.0/24 src-address=192.168.120.0/24
add action=accept chain=forward dst-address=192.168.1.0/24 src-address=192.168.140.0/24
add action=accept chain=forward dst-address=192.168.120.0/24 src-address=192.168.1.0/24
add action=accept chain=forward dst-address=192.168.140.0/24 src-address=192.168.1.0/24
add action=drop chain=forward comment="drop NVR " disabled=yes dst-address=192.168.1.10
add action=accept chain=input protocol=ipsec-esp
add action=accept chain=input protocol=udp src-port=4500
/ip firewall nat
add action=src-nat chain=srcnat out-interface=ether1-WAN-MAIN-DSL-MODEM to-addresses=yyy.yyy.yyy174
add action=accept chain=srcnat disabled=yes dst-address=192.168.140.0/24 log=yes src-address=192.168.1.0/24 to-addresses=yyy.yyy.yyy174
/ip ipsec identity
add peer=socitrans-peer
/ip ipsec policy
add dst-address=192.168.140.0/24 peer=socitrans-peer proposal=socitrans-proposal src-address=192.168.1.0/24 tunnel=yes
/ip route
add disabled=no dst-address=0.0.0.0/0 gateway=yyy.yyy.yyy169
add disabled=no dst-address=192.168.120.0/24 gateway=Mikrotik-Leb routing-table=main suppress-hw-offload=no

TheCat12 · Thu Jan 02, 2025 12:26 pm

Maybe it's the first NAT rule that is src-natting before a packet gets encrypted, after which it cannot be encrypted because the src-address mismatches that of the policy:

/ip firewall nat
add action=src-nat chain=srcnat out-interface=ether1-WAN-MAIN-DSL-MODEM ipsec-policy=out,none to-addresses=yyy.yyy.yyy.174

TarekH · Thu Jan 02, 2025 12:40 pm

i removed everything from NAT and used only your command
same issue no ping whatsoever

TheCat12 · Thu Jan 02, 2025 12:53 pm

Perhaps also a policy template is advisable alongside the tunnel one you've created which would be added to the identity:

/ip ipsec policy group
add name=socitrans-policy-group

/ip ipsec policy
add group=socitrans-policy-group proposal=socitrans-proposal template=yes

/ip ipsec identity
set policy-template-group=socitrans-policy-group

johnson73 · Thu Jan 02, 2025 1:18 pm

/ip firefirewall filter
add action=accept chain=forward dst-address=192.168.1.0/24 src-address=192.168.120.0/24
add action=accept chain=forward dst-address=192.168.1.0/24 src-address=192.168.140.0/24
add action=accept chain=forward dst-address=192.168.120.0/24 src-address=192.168.1.0/24
add action=accept chain=forward dst-address=192.168.140.0/24 src-address=192.168.1.0/24
add action=drop chain=forward comment="drop NVR " disabled=yes dst-address=192.168.1.10
add action=accept chain=input protocol=ipsec-esp
add action=accept chain=input protocol=udp src-port=4500
/ip firewall nat

[/code]

Hello. The problem is on the Mikrotik side, because the correct traffic flow is not defined. There is no correct Input and Forward section. You only have forward rules defined, there is no initial stage Input chain. Traffic will work incorrectly. Rules are executed from top to bottom and the order also matters. And all this also affects the security of the router.
INPUT CHAIN --> To the Router or to Router Services. Directional flow is WAN to Router, and LAN to Router.
FORWARD CHAIN --> Through the Router. Direction flow is LAN to LAN, LAN to WAN, WAN to LAN.
OUTPUT CHAIN --> From the Router. Directional flow is Router to WAN.
Overall it looks like this -

/ip firewall filter
add action=accept chain=input comment="Allow Established,Related" \
    connection-state=established,related,untracked
add action=drop chain=input comment="drop invalid packets" connection-state=\
    invalid
add action=accept chain=input comment="ICMP" 
add action=accept chain=input comment="Allow DNS to local" dst-port=53 \
    in-interface-list=LAN protocol=udp
add action=accept chain=input comment="Allow DNS to local" dst-port=53 \
    in-interface-list=LAN protocol=tcp
add action=accept chain=input comment=L2TP dst-port=500,1701,4500 protocol=udp
add action=accept chain=input comment="IKE IPSec" protocol=ipsec-esp
add action=accept chain=input in-interface-list=LAN
add action=drop chain=input comment="Drop all else"
add action=accept chain=forward comment="defconf: accept in ipsec policy" \
    ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" \
    ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment=Fatsttrack \
    connection-state=established,related hw-offload=yes
add action=accept chain=forward comment="Allow Established,Related" \
    connection-state=established,related,untracked
add action=drop chain=forward comment="Drop Invalid Connections" \
    connection-state=invalid
add action=accept chain=forward comment="Access Internet From LAN" \
    in-interface-list=LAN out-interface-list=WAN
add action=accept chain=forward comment=VPN dst-address-list=Local-LAN \
    src-address-list=VPN
add action=accept chain=forward comment="allow port forwarding" \
    connection-nat-state=dstnat
add action=drop chain=forward comment="Drop everything else"

"example address.."
/ip firewall address-list
add address=192.168.88.0/24 list=Local-LAN
add address=192.168.99.0/24 list=VPN

TarekH · Thu Jan 02, 2025 1:22 pm

Perhaps also a policy template is advisable alongside the tunnel one you've created which would be added to the identity:
Code: Select all
/ip ipsec policy group
add name=socitrans-policy-group

/ip ipsec policy
add group=socitrans-policy-group proposal=socitrans-proposal template=yes

/ip ipsec identity
set policy-template-group=socitrans-policy-group

this was already done before and is crucial for the ipsec tunnel connection success
my problem is not ipsec , it is either firewall or routing

sindy · Thu Jan 02, 2025 1:49 pm

Perhaps also a policy template is advisable alongside the tunnel one you've created which would be added to the identity:
this was already done before and is crucial for the ipsec tunnel connection success

If you had to set up a template (which is missing in your original configuration export, so how was @TheCat supposed to know that), it means that either your own static policy that was present in the export is incompatible with the settings on the Sophos side (the traffic selector, the proposal, or both) or that the Sophos expects your end to only behave as a responder.

So:

post the current configuration export
start pinging some address in 192.168.140.0/24, specifying src-address=192.168.1.111 in order to make the packets match the traffic selector of the policy (without specifying the source address, the router uses the one of the out-interface through which the gateway is reachable, i.e. the WAN one in your case)
post the output of /ip ipsec policy print detail
post the output of /ip ipsec installed-sa print detail while the ping is still running

No need to obfuscate the keys, they are short-lived, but of course don't forget to obfuscate the public addresses, just do it systematically so that each unique public address looks the same at all places and remains unique.

Besides, you should take seriously what @johnson73 wrote - as the default action in firewall, which is taken if the packet did not match any rule, is accept, your firewall rules as they look in the original export are useless - what they do not accept gets accepted anyway by default.

my problem is not ipsec , it is either firewall or routing

At this stage, such a conclusion is premature.

TarekH · Thu Jan 02, 2025 1:53 pm

/ip firefirewall filter
add action=accept chain=forward dst-address=192.168.1.0/24 src-address=192.168.120.0/24
add action=accept chain=forward dst-address=192.168.1.0/24 src-address=192.168.140.0/24
add action=accept chain=forward dst-address=192.168.120.0/24 src-address=192.168.1.0/24
add action=accept chain=forward dst-address=192.168.140.0/24 src-address=192.168.1.0/24
add action=drop chain=forward comment="drop NVR " disabled=yes dst-address=192.168.1.10
add action=accept chain=input protocol=ipsec-esp
add action=accept chain=input protocol=udp src-port=4500
/ip firewall nat

[/code]
Hello. The problem is on the Mikrotik side, because the correct traffic flow is not defined. There is no correct Input and Forward section. You only have forward rules defined, there is no initial stage Input chain. Traffic will work incorrectly. Rules are executed from top to bottom and the order also matters. And all this also affects the security of the router.
INPUT CHAIN --> To the Router or to Router Services. Directional flow is WAN to Router, and LAN to Router.
FORWARD CHAIN --> Through the Router. Direction flow is LAN to LAN, LAN to WAN, WAN to LAN.
OUTPUT CHAIN --> From the Router. Directional flow is Router to WAN.
Overall it looks like this -
Code: Select all
/ip firewall filter
add action=accept chain=input comment="Allow Established,Related" \
    connection-state=established,related,untracked
add action=drop chain=input comment="drop invalid packets" connection-state=\
    invalid
add action=accept chain=input comment="ICMP" 
add action=accept chain=input comment="Allow DNS to local" dst-port=53 \
    in-interface-list=LAN protocol=udp
add action=accept chain=input comment="Allow DNS to local" dst-port=53 \
    in-interface-list=LAN protocol=tcp
add action=accept chain=input comment=L2TP dst-port=500,1701,4500 protocol=udp
add action=accept chain=input comment="IKE IPSec" protocol=ipsec-esp
add action=accept chain=input in-interface-list=LAN
add action=drop chain=input comment="Drop all else"
add action=accept chain=forward comment="defconf: accept in ipsec policy" \
    ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" \
    ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment=Fatsttrack \
    connection-state=established,related hw-offload=yes
add action=accept chain=forward comment="Allow Established,Related" \
    connection-state=established,related,untracked
add action=drop chain=forward comment="Drop Invalid Connections" \
    connection-state=invalid
add action=accept chain=forward comment="Access Internet From LAN" \
    in-interface-list=LAN out-interface-list=WAN
add action=accept chain=forward comment=VPN dst-address-list=Local-LAN \
    src-address-list=VPN
add action=accept chain=forward comment="allow port forwarding" \
    connection-nat-state=dstnat
add action=drop chain=forward comment="Drop everything else"

"example address.."
/ip firewall address-list
add address=192.168.88.0/24 list=Local-LAN
add address=192.168.99.0/24 list=VPN

did not work - a tracert shows the ping arrives from a pc to the router (mikrotik) and then nothing

this is my current firewall

/ip firewall address-list
add address=192.168.1.0/24 list=LAN
add address=192.168.140.0/24 list=VPN
/ip firewall connection tracking
set udp-timeout=10s
/ip firewall filter
add action=accept chain=forward dst-address=192.168.1.0/24 src-address=192.168.120.0/24
add action=accept chain=forward dst-address=192.168.120.0/24 src-address=192.168.1.0/24
add action=accept chain=input comment="Allow Established,Related" connection-state=established,related,untracked
add action=drop chain=input comment="drop invalid packets" connection-state=invalid
add action=accept chain=input comment=ICMP
add action=accept chain=input comment="Allow DNS to local" dst-port=53 in-interface-list=LAN protocol=udp
add action=accept chain=input comment="Allow DNS to local" dst-port=53 in-interface-list=LAN protocol=tcp
add action=accept chain=input comment=L2TP dst-port=500,1701,4500 protocol=udp
add action=accept chain=input comment="IKE IPSec" protocol=ipsec-esp
add action=accept chain=input in-interface-list=LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment=Fatsttrack connection-state=established,related hw-offload=yes
add action=accept chain=forward comment="Allow Established,Related" connection-state=established,related,untracked
add action=drop chain=forward comment="Drop Invalid Connections" connection-state=invalid
add action=accept chain=forward comment=VPN dst-address-list=LAN src-address-list=VPN
add action=accept chain=forward comment=VPN dst-address-list=VPN src-address-list=LAN
add action=accept chain=forward comment="allow port forwarding" connection-nat-state=dstnat
/ip firewall nat
add action=src-nat chain=srcnat ipsec-policy=out,none out-interface=ether1-WAN-MAIN-DSL-MODEM to-addresses=yyy.yyy.yyy.174

TarekH · Thu Jan 02, 2025 2:00 pm

this was already done before and is crucial for the ipsec tunnel connection success
If you had to set up a template (which is missing in your original configuration export, so how was @TheCat supposed to know that), it means that either your own static policy that was present in the export is incompatible with the settings on the Sophos side (the traffic selector, the proposal, or both) or that the Sophos expects your end to only behave as a responder.

So:
post the current configuration export

start pinging some address in 192.168.140.0/24, specifying src-address=192.168.1.111 in order to make the packets match the traffic selector of the policy (without specifying the source address, the router uses the one of the out-interface through which the gateway is reachable, i.e. the WAN one in your case)

post the output of /ip ipsec policy print detail

post the output of /ip ipsec installed-sa print detail while the ping is still running

No need to obfuscate the keys, they are short-lived, but of course don't forget to obfuscate the public addresses, just do it systematically so that each unique public address looks the same at all places and remains unique.

Besides, you should take seriously what @johnson73 wrote - as the default action in firewall, which is taken if the packet did not match any rule, is accept, your firewall rules as they look in the original export are useless - what they do not accept gets accepted anyway by default.

my problem is not ipsec , it is either firewall or routing
At this stage, such a conclusion is premature.

it is the current config - i reposted the IPSEC section for better clarity
ipsec is active, maybe i need to route something ?!

/ip ipsec policy group
add name=socitrans
/ip ipsec profile
set [ find default=yes ] dpd-interval=2m dpd-maximum-failures=5
add dh-group=modp2048 enc-algorithm=aes-256 hash-algorithm=sha256 name=socitrans nat-traversal=no
/ip ipsec peer
add address=xxx.xxx.xxx.78/32 exchange-mode=ike2 name=socitrans-peer profile=socitrans
/ip ipsec proposal
add auth-algorithms=sha512,sha256 enc-algorithms=aes-256-cbc,aes-256-ctr,aes-256-gcm name=socitrans-proposal pfs-group=modp2048
/ip ipsec identity
add peer=socitrans-peer
/ip ipsec policy
add dst-address=192.168.140.0/24 peer=socitrans-peer proposal=socitrans-proposal src-address=192.168.1.0/24 tunnel=yes

johnson73 · Thu Jan 02, 2025 2:06 pm

Where did you get the last rule in the forward section that drops everything? Drop?? And also input? That's not correct.
First we need to have correct traffic rolls and then we can look further at the route and the rest. Was there a restart after the FW rule changes?

TarekH · Thu Jan 02, 2025 2:09 pm

Where did you get the last rule in the forward section that drops everything? Drop?? And also input? That's not correct.

rule 15 is drop invalid connection
i removed the last drop rule as i am working remotely , couldnt risk being disconnected too
i dont think drop will affect the ipsec connection no ?

sindy · Thu Jan 02, 2025 2:15 pm

The configuration in the original post does not configure the policy template you declare to be present in response to the suggestion of @TheCat12. So one of those must be wrong - either you actually did not add the template and misunderstood @TheCat12's suggestion to add a template for a plain static policy you already had, or the export in the OP is not the current one.

If you came here for assistance, you have to cooperate - I gave you diagnostic step to perform.

If you came to quarrel, I'm fine with that too, but I won't participate.

johnson73 · Thu Jan 02, 2025 2:19 pm

Where did you get the last rule in the forward section that drops everything? Drop?? And also input? That's not correct.
rule 15 is drop invalid connection
i removed the last drop rule as i am working remotely , couldnt risk being disconnected too
i dont think drop will affect the ipsec connection no ?

of course if you make changes, you will need to restart, there will be a disconnect.
Firewall entries must be correct for everything to work stably. If you modify the entries, then it will affect the operation.
For incoming traffic that is in the ''Input'' chain, the last entry will always be ''drop all'' and the ''forward'' chain the last entry will also be ''drop-all''. This means that all defined rules are executed and everything else that is not defined is ''dropped''. That is correct.
If after all this it does not work for you, then you need to check whether you have defined the address-list entries correctly. Then the ipsec entries..

TarekH · Thu Jan 02, 2025 2:45 pm

The configuration in the original post does not configure the policy template you declare to be present in response to the suggestion of @TheCat12. So one of those must be wrong - either you actually did not add the template and misunderstood @TheCat12's suggestion to add a template for a plain static policy you already had, or the export in the OP is not the current one.

If you came here for assistance, you have to cooperate - I gave you diagnostic step to perform.

If you came to quarrel, I'm fine with that too, but I won't participate.

Happy new year , you seem to be in a bad mood
i reposted the ipsec config - are these what u r talking about ? or am i still missing something else ?

sindy · Thu Jan 02, 2025 2:55 pm

you seem to be in a bad mood

That's the state of my mind most of the time, nothing to worry about.

i reposted the ipsec config - are these what u r talking about ? or am i still missing something else ?

I gave you an itemized list of the steps aimed to check what is actually going on here. More may be needed depending on the outcome. export shows the manually created configuration, print shows the actual outcome, including dynamically created objects that export cannot show by design.

The export of IPsec you have added into the post above confirms that you did not actually use a template as @TheCat12 suggested - it may not be wrong as such, it just indicates you need to slow down and concentrate

TarekH · Thu Jan 02, 2025 3:01 pm

rule 15 is drop invalid connection
i removed the last drop rule as i am working remotely , couldnt risk being disconnected too
i dont think drop will affect the ipsec connection no ?
of course if you make changes, you will need to restart, there will be a disconnect.
Firewall entries must be correct for everything to work stably. If you modify the entries, then it will affect the operation.
For incoming traffic that is in the ''Input'' chain, the last entry will always be ''drop all'' and the ''forward'' chain the last entry will also be ''drop-all''. This means that all defined rules are executed and everything else that is not defined is ''dropped''. That is correct.
If after all this it does not work for you, then you need to check whether you have defined the address-list entries correctly. Then the ipsec entries..

i rebooted everything - still same thing .. according to the KB i just have to forward the lan subnets from remote to local and from local to remote

TarekH · Thu Jan 02, 2025 3:08 pm

this was already done before and is crucial for the ipsec tunnel connection success
If you had to set up a template (which is missing in your original configuration export, so how was @TheCat supposed to know that), it means that either your own static policy that was present in the export is incompatible with the settings on the Sophos side (the traffic selector, the proposal, or both) or that the Sophos expects your end to only behave as a responder.

So:
post the current configuration export

start pinging some address in 192.168.140.0/24, specifying src-address=192.168.1.111 in order to make the packets match the traffic selector of the policy (without specifying the source address, the router uses the one of the out-interface through which the gateway is reachable, i.e. the WAN one in your case)

post the output of /ip ipsec policy print detail

post the output of /ip ipsec installed-sa print detail while the ping is still running

No need to obfuscate the keys, they are short-lived, but of course don't forget to obfuscate the public addresses, just do it systematically so that each unique public address looks the same at all places and remains unique.

Besides, you should take seriously what @johnson73 wrote - as the default action in firewall, which is taken if the packet did not match any rule, is accept, your firewall rules as they look in the original export are useless - what they do not accept gets accepted anyway by default.

my problem is not ipsec , it is either firewall or routing
At this stage, such a conclusion is premature.

while pinging as you advised

[admin@RB1100-Tradium] > /ip ipsec policy print detail
Flags: T - template; B - backup; X - disabled, D - dynamic, I - invalid, A - active; * - default 
 0   A  peer=socitrans-peer tunnel=yes src-address=192.168.1.0/24 src-port=any dst-address=192.168.140.0/24 dst-port=any protocol=all action=encrypt level=require ipsec-protocols=esp sa-src-address=yyy.yyy.yyy.174 sa-dst-address=xxx.xxx.xxx.78 
        proposal=socitrans-proposal ph2-count=1 ph2-state=established 

 1 T  * group=default src-address=::/0 dst-address=::/0 protocol=all proposal=default template=yes 
[admin@RB1100-Tradium] > /ip ipsec installed-sa print detail
Flags: S - seen-traffic; H - hw-aead; A - AH, E - ESP 
 0  HE spi=0xAE15DFC src-address=xxx.xxx.xxx.78 dst-address=yyy.yyy.yyy.174 state=mature auth-algorithm=sha512 enc-algorithm=aes-cbc enc-key-size=256 
       auth-key="593b6e816fc6049db7b8d2c19d974de71078cada165aa34086b837da46f404abbf35febce66210d6585e667b46811cdcc4297a0aeb3471e4a7f8bdcd8c5afae5" enc-key="d5a740114d7022467b7200deb59c9c561c08a3e150cc892d608253cf40dbddd6" add-lifetime=24m22s/30m28s 
       replay=128 

 1 SHE spi=0xC32C2CC7 src-address=yyy.yyy.yyy.174 dst-address=xxx.xxx.xxx.78 state=mature auth-algorithm=sha512 enc-algorithm=aes-cbc enc-key-size=256 
       auth-key="7c2d5a5535238e9933fea2a243247c9fb90f3609463ef046054e16cfc872caf60e4fe62329ede5be1605a3e4b96ae4e1a87ad5ff7dec453e83f3b7f1701d9efb" enc-key="45ae398837a52cc4d74631ef3f159d3e72f2f04a6bcc6788e4e85027c6c1e32e" addtime=2025-01-02 14:55:43 
       expires-in=19m50s add-lifetime=24m22s/30m28s current-bytes=12176 current-packets=161 replay=128 
[admin@RB1100-Tradium] >

sindy · Thu Jan 02, 2025 3:34 pm

OK. According to your configuration export, xxx.xxx.xxx.78 is the Sophos and yyy.yyy.yyy.174 is your Tik. The /ip ipsec installed-sa print detail shows that the security association from the Tik to the Sophos does carry traffic (there is the S indicator in the leftmost column, and there are the current-bytes=12176 and current-packets=161 values), whereas the one in the opposite direction is totally silent. So the device you ping at the Sophos side may not be responding (Windows devices by default ignore ping requests that do not come from the local subnet), or the Sophos may even not accept the incoming encrypted pings, or the routing of the responses is wrong.

So it may be a routing issue or a firewall one, but not on the Mikrotik side.

The firewall needs to be sorted out as well - I understand your concerns regarding losing remote access, but leaving the management of the device accessible from the whole internet is not the way to go.

TarekH · Thu Jan 02, 2025 4:07 pm

OK. According to your configuration export, xxx.xxx.xxx.78 is the Sophos and yyy.yyy.yyy.174 is your Tik. The /ip ipsec installed-sa print detail shows that the security association from the Tik to the Sophos does carry traffic (there is the S indicator in the leftmost column, and there are the current-bytes=12176 and current-packets=161 values), whereas the one in the opposite direction is totally silent. So the device you ping at the Sophos side may not be responding (Windows devices by default ignore ping requests that do not come from the local subnet), or the Sophos may even not accept the incoming encrypted pings, or the routing of the responses is wrong.

So it may be a routing issue or a firewall one, but not on the Mikrotik side.

The firewall needs to be sorted out as well - I understand your concerns regarding losing remote access, but leaving the management of the device accessible from the whole internet is not the way to go.

i understand , time to recheck with sophos then
the thing is i can ping from sophos to mikrotik

TarekH · Thu Jan 02, 2025 4:24 pm

so i dont know what happened
i am now able to ping the sophos from behind the mikrotik and from the sophos itself to the mikrotik but not behind the sophos
i think i need a route on the sophos end or another firewalll rule

you guys are awesome

sindy · Thu Jan 02, 2025 4:32 pm

the thing is i can ping from sophos to mikrotik

When you do that, you should see both the installed-sa to count packets and bytes; if the pings from the Sophos are the only traffic and you run /ip ipsec installed-sa print detail interval=1s, you should see the packet counters in both directions to grow by one every second.

The behavior where one side can ping the other but not vice versa is a normal one for stateful firewalls - whether the packet between two addresses will pass through or not depends on which party has initiated that connection. The typical behavior is that a firewall allows connections that an "inside" client establishes towards "outside" servers (aka outbound connections), but not inbound ones. It is also normal that a VPN tunnel from a business partner is considered an "external" domain too, hence firewall rules are still applied to policy where the partner is allowed to connect and where not.

so i dont know what happened
i am now able to ping the sophos from behind the mikrotik

This suggests yet another possibility - since both the IPsec peers use public addresses, the SA transport packets are bare ESP ones. If all you need to make pings from Mikrotik side to Sophos side succeed is to ping from the Sophos side to the Mikrotik one first, it means that the firewall at Sophos side only accepts ESP from addresses to which it has itself sent an ESP packet before.

As for your remote access to management of the Tik - am I right to assume you access the router via the Wireguard tunnel? Or do you connect directly to the yyy.yyy.yyy.174 address using Winbox?

johnson73 · Thu Jan 02, 2025 7:34 pm

so i dont know what happened
i am now able to ping the sophos from behind the mikrotik and from the sophos itself to the mikrotik but not behind the sophos
i think i need a route on the sophos end or another firewalll rule

If everything is ok with your firewall rules (as in my example), then look at what is happening with the NAT section.
When creating a tunnel with a ''other'' router, we create a standard masquerade for our subnet and if necessary, create an additional masquerade for the other subnet (for example, video or other).
Srcnat addresses must be above Masquarade, otherwise the rules policy will work incorrectly. Srcnat will be your IP subnets and Dstnat will be Sophos remote subnets.
Then add the Sophos subnet to the ''Route list'' and specify the output (Wan). You need to pay attention to the ''DH Group''. In my case, the connection is to the Fortigate FW, yours will probably be similar. The DH on both sides must match.
I have created many tunnels this way and have no problems. In my case, the Mikrotik version everywhere is 7.16.2 I don't know what version you have.

Of course, there is always the possibility of running Wireguard

TarekH · Fri Jan 03, 2025 12:21 pm

Sorry guys im in congo and power is not always present

1 - yes i access the router via wireguard
2- made the sophos initiate the connection and reduces all the encryption and authentication to AES256 and SHA256 and DH2048 only (i also removed all static routes from or to the mikrotik 192.168.1.0/24)
3 - I only used these firewall rules - but disabling the nat didnt affect the network

add action=accept chain=forward connection-state=established,related dst-address=192.168.1.0/24 src-address=192.168.140.0/24
add action=accept chain=forward connection-state=established,related dst-address=192.168.140.0/24 src-address=192.168.1.0/24
add action=accept chain=srcnat dst-address=192.168.140.0/24 src-address=192.168.1.0/24

sindy · Fri Jan 03, 2025 1:17 pm

The description below only deals with Wireguard and SSH/Winbox, and is aimed to illustrate how the firewall works. So you need to adjust it to your actual environment and add whatever additional accept rules are necessary for other things (like the IPsec) to work before applying the last steps. The best would be to experiment with this on a router that is on your table before using it on the one half a globe away, but it is designed in such a way that it was reasonably safe even in the latter case.

If you manage the router using Wireguard, what you have to ensure is that

the Wireguard transport packets are accepted in ip firewall filter if they arrive to the public address and listen-port via the WAN interface (example: chain=input in-interface-list=WAN protocol=udp dst-port=13231 action=accept)
the wireguard transport packets the router itself sends are accepted in ip firewall filter (this is typically ahieved by doing nothing, as there are usually no rules in filter chain output that handles them, I just mention it to make the picture complete)
the management packets for the router itself that come in via the Wireguard tunnel from the proper sourec address are accepted (example: chain=input in-interface=wg-1 src-address=wireguard.address.of.your.laptop protocol=tcp dst-port=22,8291 action=accept - this will allow SSH and Winbox connections (if these services listen on their default ports)
the response packets the router sends are accepted (again, unless you have some reasons to add rules to filter/output, ths is done by default)

Once you add those rules, you can check that they actually work without losing access - if you look at them in Winbox/WebFig or you use /ip firewall filter print stats while connected using Winbox via Wireguard, you must see the byte and packet counters of those rules to grow. If they do, it is time to add another rule, chain=input connection-state=established,related action=accept to the very beginning (top) of the input chain in filter. This rule will handle both the Wireguard transport packets and the Winbox/SSH ones that belong to already existing connections, so the "wireguard" one will only count a single packet when you re-connect Wireguard from a new address or after more than 3 minutes and the "winbox/ssh" one will only count a single packet when you initiate a new connection (you can have multiple Winbox connections at the same time). The actual purpose of that "accept established or related" rule is to accept answers to requests the router itself has sent, like DNS queries or time updates.
Once that is done, you can add a chain=input action=passthrough comment=abc123 rule to the very end (bottom) of the input chain in filter. Next, add a scheduler item: /system/scheduler/add start-time=hh:mm:ss name=recover on-event={/ip firewall filter disable [find comment=abc123]}, setting hh:mm:ss to 5 minutes in future. After those 5 minutes, you should see the run counter of the scheduler to show 1 and the rule to be disabled. If this the case, you can change the start-time again to 10 minutes in future, change the action of the rule from passthrough to drop, and disconnect Winbox and then Wireguard for 5 minutes. After 5 minutes, connect Wireguard and Wireshark again, it should go without issues. If not, wait another 5 minutes and the scheduler will disable the drop rule so you can start looking what is wrong.

IPsec tunnel not working

IPsec tunnel not working

Re: IPsec tunnel not working

Re: IPsec tunnel not working

Re: IPsec tunnel not working

Re: IPsec tunnel not working

Re: IPsec tunnel not working

Re: IPsec tunnel not working

Re: IPsec tunnel not working

Re: IPsec tunnel not working

Re: IPsec tunnel not working

Re: IPsec tunnel not working

Re: IPsec tunnel not working

Re: IPsec tunnel not working

Re: IPsec tunnel not working

Re: IPsec tunnel not working

Re: IPsec tunnel not working

Re: IPsec tunnel not working

Re: IPsec tunnel not working

Re: IPsec tunnel not working

Re: IPsec tunnel not working

Re: IPsec tunnel not working

Re: IPsec tunnel not working

Re: IPsec tunnel not working

Re: IPsec tunnel not working

Who is online