The Radius packets can't pass over ipsec with RouterOS

RouterOS General
1

I setup a IPsec client with RouterOS , and the IPsec is up , and I can ping remote private gateway over ipsec.
Other packets can pass over Ipsec.

But when I setup a Radius on RouterOS’s LAN, the Radius request can’t pass through IPsec, the Rasius request send to internet, but meanwhile, the ICMP packets can pass over IPSec.

I set the IPsec policy like this:

[admin@MikroTik] /ip ipsec policy> print
Flags: X - disabled, D - dynamic, I - inactive 
 0   src-address=192.168.88.0/24 src-port=any dst-address=10.110.0.0/16 
     dst-port=any protocol=all action=encrypt level=require ipsec-protocols=esp 
     tunnel=yes sa-src-address=112.25.145.100 sa-dst-address=194.149.213.193 
     proposal=proposal1 priority=0

The Firewall NAT rule like this:

[admin@MikroTik] /ip firewall nat> print
Flags: X - disabled, I - invalid, D - dynamic 
 0   chain=srcnat action=accept src-address=192.168.88.0/24 
     dst-address=10.110.0.0/16 

 1   ;;; default configuration
     chain=srcnat action=masquerade out-interface=ether1-gateway

src-address=192.168.88.0/24 src-port=any dst-address=10.110.0.0/16
is the my private network.

sa-src-address=112.25.145.100 sa-dst-address=194.149.213.193
if the public network.


Then I setup a PC on RouterOS’s LAN, ping 10.110.4.142, it works.
Then I setup a radius client on RouterOS’s LAN, then capture packets on WAN, I found the radius packets send to internet, not pass over ipsec. the radius source IP is 192.168.88.254, and dest IP is 10.110.4.142.

Please help me why the radius packets behavior is different with other normal packets?

2

First of all, you can’t say 0.0.0.0/0 in an IPSec policy (as far as I know).
It wants a specific source and destination.

I took a look at the packet flow diagram, and noticed that src-nat is going to happen in the [|Postrouting|] block before IPSec gets to look at the RADIUS packet.

Depending on how your NAT exemption rules are built, they might miss the Mikrotik’s radius requests, which would cause the packet to get src-natted, which would result in a src IP that doesn’t match the SA.

3

Thanks for your response, I have updated the question, and remove some no needed rule and add the firewall NAT rule.

It’s very strange, other normal packets,like ICMP. HTTP packets, can follow the IPsec policy, pass to remote server:10.110.4.142.
But Radius packets can’t pass over IPsec, it have the same source IP and dest IP as the same as other normal packets.
The packets will be send from 112.25.145.100, but not encrypted and not pass over Ipsec.

4

Which IP is the Radius server and which IP is the radius client?

Because you mention

The packets will be send from 112.25.145.100, but not encrypted and not pass over Ipsec.

If packets from 112.25.145.100 are not encrypted, you are showing us exports from the wrong router (the router hosting 192.168.88.0/24) in the original post.

To debug this, we need to see the setup on the router terminating the IP of which the packets are not encrypted.
I think you are showing us the wrong side of the setup in the initial post.

5

Post your nat table.
/ip firewall nat export compact

IPSec decisions happen after NAT is done, so if the RADIUS request is being translated with masquerade, then IPSec will not see such packets as candidates for the tunnel.

6

Thanks for your help.
I found that:it’s my mistake, I captured the packets of ipsec client’s LAN and WAN, so I make a mistake when I analyze the packets. So it’s not a issue. Just my mistake.
Thanks very much.