RADIUS with IPSec

Hi.

I have a scenario where I am using Hotspot on Mikrotik thru IPsec. The only prob is that the RADIUS is hosted in LAN of the IPsec other side and my remote router sends RADIUS requests to the internet.

Is there a possibility to push all internet traffic thru IPSec. I am I dont want any other traffic to pass thru without IPSec.


Pls help..

Pls diagram it. I’m lost in “other side” and “remote” in the same sentence. A photo of a drawing by hand is enough. In general it is possible to configure a default “route” via an IPsec tunnel but maybe you need some exceptions like DNS?

Hi Sindy,

Diagram is attached.

My RADIUS server is on Head Office - 172.16.88.11. I am able to reach all remote LAN IPs of Head office after IPSec is established. The captive portal hosted on 172.16.88.15 pops up automatically on my remote router clients at 10.10.10.2 and 10.10.10.3.

Now the issue is that RADIUS request is not reaching the RADIUS server on the HO. At Mikrotik HeX end RADIUS logs say requests are timed out.

So I want all traffic to forcefully go thru IPSec. Even Internet will be accessed thru Head Office Firewall.

I hope I am able to clarify the requirement now.
Gaurav
New Microsoft PowerPoint Presentation.pptx (103 KB)

Assuming that the left-side Mikrotik only talks to the Radius server, whereas it’s the devices in that Mikrotik’s LAN what talks with the other devices in Fortigate’s LAN, I’d guess it is something in Mikrotik’s configuration what causes it to send the Radius requests from some local IP which the IPsec policy doesn’t match on.

Anyway, regardless whether the solution will consist in fixing this or in sending everything into the tunnel, please follow my automatic signature at the Mikrotik side, plus provide the output of /ip ipsec policy print while the tunnel is up.

Hi Sindy,

The mikrotik talks to entire IP pool of the Firewall side. (172.16.88.0/24)

Pls find ipsec print

ip ipsec policy print
Flags: T - template, X - disabled, D - dynamic, I - invalid, A - active, * - default
0 T * group=default src-address=::/0 dst-address=::/0 protocol=all proposal=default template=yes

1 A src-address=10.10.10.0/24 src-port=any dst-address=172.16.88.0/24 dst-port=any protocol=all action=encrypt
level=use ipsec-protocols=esp tunnel=yes sa-src-address=0.0.0.0 sa-dst-address=1.1.1.1
proposal=proposal1 ph2-count=1

The only new information I’ve got from that is that the policy is a statically configured one. So you may change that policy’s dst-address to 0.0.0.0/0 at Mikrotik side, and the src-address accordingly in the complementary policy for this Mikrotik at the Fortigate side. But I think that it is not necessary and that to solve the issue, it would be sufficient to insert the following rule in /ip firewall nat

chain=srcnat action=src-nat src-address=!10.10.10.0/24 to-addresses=10.10.10.1 dst-address=172.16.88.0/24

before the action=masquerade one, because while the packets from the LAN devices have 10.10.10.x as source address and thus the policy matches on them, the packets sent by the 'Tik itself have its WAN address as a source one and thus the policy ignores them.

But it is just a speculation because you haven’t posted your configuration export.

Hi,

This is not solving the purpose.

I need a flow where all WAN traffic is forced thru IPSec, even Internet traffic. This way RADIUS request from Hotspot server will also compelled to be routed thru IPSec and and can eventually reach the server.

Can you suggest some config for the same?

I’ve already done, it consists merely in changing that IPsec policy’s dst-address from the current 172.16.88.0/24 to 0.0.0.0/0 at 'Tik side and symmetrically changing the src-address at Fortigate side. At Mikrotik side, the IPsec transport traffic is auto-protected against being sent into the tunnel it transports as IPsec transport packets are ignored by IPsec policies so they are not captured and encrypted again ad nauseam, but DNS and everything will get redirected as soon as the tunnel gets up. However, I’m not sure whether the auto-protection also handles control packets; if it doesn’t, you would have to create a manual protection policy, saying action=none src-address=tik’s.wan.ip.address dst-address=fortigate’s.public.ip.address, and place it on top of the existing one.