routing to remote subnets over IPSEC hops
Hi guys, I'm trying to work out how to get traffic from my local LAN to secondary remote IPSEC networks. For example: home <----> work <--> remotesite (where each of the links is an IPSEC tunnel). If I use Forticlient I can do this fine by: - define phase2 dst & src subnets as 0.0.0.0/0.0.0.0 - existing routes from work --> remotesite still function as expected - make sure local client routes 192.168.0.0/16 over IPSEC gateway address - setup policy on fortigate as follows: incoming interface: Forticlient interface outgoing interface: remoteVPN interface incoming subnet: Forticlient Range outgoing subnet: remote range ports etc: as required I can add a specific P2 route by using /ip ipsec policy and this is working OK - but only for the specific subnet that I define in the policy. What I want to do is create a generic policy that only routes traffic via the IPSEC tunnel when it needs to - and not - when it doesn't need to. But... the issue here is I can't define a route - because there's no virtual interface associated with the IPSEC tunnel (whereas on Fortigate you do get a virtual interface that can be referenced in policies / routes etc). And you can't use a standard route, because the gateway in this case is remote (i.e. it's the router at work). If I try to setup a 0/0 P2 it breaks the VPN completely. Any tips for how I might go about making a more generic / scalable approach here?
You cannot route over IPSec, but I do believe you can route afterwards. IPSec matches the source and destination networks before routing and packs/encrypts the packet into the tunnel to send it to the remote endpoint where it will decrypted and forward the packet. Routing and interfaces are not considered in IPSec it just matches the IP Policy, once out at the other end normal router flow should continue. The firewall can cause problems when passing networks so make sure the rules allow the forwarding. So for your example H <-> W <-> R Where H = 192.168.0.0/24 W=172.16.0.0/24 R = 10.0.0.0/8 You would need to allow, H <-> W and H <-> R in the tunnel. The networks can also include larger subnets is possible but watch out for overlaps in the network allocation as if a policy match occurs the packet will go through the IPSec tunnel. The W router should be able to forward/route subets within the 10.0.0.0/8 to other detsinations, but any match with the IPSec policies will result in the packet being passed to the other end. Also take a look at these pages: https://wiki.mikrotik.com/wiki/Manual:Packet_Flow https://wiki.mikrotik.com/wiki/Routing_through_remote_network_over_IPsec If you need routing consider EoIP with IPSec, you can then route and even run routing protocols like OSPF. I run backup links via Internet gateways this way, to replace internal private links if they fail, you just place a high cost on it. On 23/03/2020 12:19 pm, Chris Herrmann wrote:
Hi guys,
I'm trying to work out how to get traffic from my local LAN to secondary remote IPSEC networks. For example:
home <----> work <--> remotesite
(where each of the links is an IPSEC tunnel).
If I use Forticlient I can do this fine by: - define phase2 dst & src subnets as 0.0.0.0/0.0.0.0 - existing routes from work --> remotesite still function as expected - make sure local client routes 192.168.0.0/16 over IPSEC gateway address - setup policy on fortigate as follows: incoming interface: Forticlient interface outgoing interface: remoteVPN interface incoming subnet: Forticlient Range outgoing subnet: remote range ports etc: as required
I can add a specific P2 route by using /ip ipsec policy
and this is working OK - but only for the specific subnet that I define in the policy.
What I want to do is create a generic policy that only routes traffic via the IPSEC tunnel when it needs to - and not - when it doesn't need to.
But... the issue here is I can't define a route - because there's no virtual interface associated with the IPSEC tunnel (whereas on Fortigate you do get a virtual interface that can be referenced in policies / routes etc). And you can't use a standard route, because the gateway in this case is remote (i.e. it's the router at work).
If I try to setup a 0/0 P2 it breaks the VPN completely.
Any tips for how I might go about making a more generic / scalable approach here? _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
The easiest thing to do is use GRE with IPSEC, either with the IPSEC setting in GRE or manually setting them up separately. This way you can set routes for the GRE interfaces in the routing table. An alternative you could explore is to srcnat/masquerade the subnet in question to the subnet that is going over the tunnel. Regards, Jason Hecker <https://www.upandrunningtech.com.au/> <https://www.upandrunningtech.com.au/> On Mon, 23 Mar 2020, at 13:31, Darren Clissold wrote:
You cannot route over IPSec, but I do believe you can route afterwards.
IPSec matches the source and destination networks before routing and packs/encrypts the packet into the tunnel to send it to the remote endpoint where it will decrypted and forward the packet. Routing and interfaces are not considered in IPSec it just matches the IP Policy, once out at the other end normal router flow should continue. The firewall can cause problems when passing networks so make sure the rules allow the forwarding.
So for your example H <-> W <-> R Where H = 192.168.0.0/24 W=172.16.0.0/24 R = 10.0.0.0/8 You would need to allow, H <-> W and H <-> R in the tunnel. The networks can also include larger subnets is possible but watch out for overlaps in the network allocation as if a policy match occurs the packet will go through the IPSec tunnel.
The W router should be able to forward/route subets within the 10.0.0.0/8 to other detsinations, but any match with the IPSec policies will result in the packet being passed to the other end.
Also take a look at these pages: https://wiki.mikrotik.com/wiki/Manual:Packet_Flow https://wiki.mikrotik.com/wiki/Routing_through_remote_network_over_IPsec
If you need routing consider EoIP with IPSec, you can then route and even run routing protocols like OSPF. I run backup links via Internet gateways this way, to replace internal private links if they fail, you just place a high cost on it.
On 23/03/2020 12:19 pm, Chris Herrmann wrote:
Hi guys,
I'm trying to work out how to get traffic from my local LAN to secondary remote IPSEC networks. For example:
home <----> work <--> remotesite
(where each of the links is an IPSEC tunnel).
If I use Forticlient I can do this fine by: - define phase2 dst & src subnets as 0.0.0.0/0.0.0.0 - existing routes from work --> remotesite still function as expected - make sure local client routes 192.168.0.0/16 over IPSEC gateway address - setup policy on fortigate as follows: incoming interface: Forticlient interface outgoing interface: remoteVPN interface incoming subnet: Forticlient Range outgoing subnet: remote range ports etc: as required
I can add a specific P2 route by using /ip ipsec policy
and this is working OK - but only for the specific subnet that I define in the policy.
What I want to do is create a generic policy that only routes traffic via the IPSEC tunnel when it needs to - and not - when it doesn't need to.
But... the issue here is I can't define a route - because there's no virtual interface associated with the IPSEC tunnel (whereas on Fortigate you do get a virtual interface that can be referenced in policies / routes etc). And you can't use a standard route, because the gateway in this case is remote (i.e. it's the router at work).
If I try to setup a 0/0 P2 it breaks the VPN completely.
Any tips for how I might go about making a more generic / scalable approach here? _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
participants (3)
-
Chris Herrmann
-
Darren Clissold
-
Jason Hecker