Community discussions

MikroTik App
 
djferdinad
just joined
Topic Author
Posts: 14
Joined: Wed Apr 06, 2022 5:12 am

Push traffic to VPN on AWS

Wed Apr 06, 2022 5:34 am

Good day MK community.

I am new on MK and I am trying to set up a VPN with an AWS CHR. I am able to connect the VPN I've tried OPENVPN and PPTP But I can not make the traffic route to go over the VPN.

I've made a lot of reading a watching videos but with no success.

I would like to start over with the config so lets assume the Server is up and running and the client is on Blank (Factory reset the client) And the VPN is connected.

I would like not to masquerade the IPs since I want to set up an internal service which will be accessed trough the VPN but is important that the service knows what IP to contact when the request is made.

How to route the traffic? Will appreciate your comments
 
AidanAus
Member Candidate
Member Candidate
Posts: 177
Joined: Wed May 08, 2019 7:35 am
Location: Australia
Contact:

Re: Push traffic to VPN on AWS

Thu Apr 07, 2022 9:56 am

I would recommend having the 'topology' image up while reading through this :)
badlol.png
OK lets pretend I didnt rust this in paint in the shortest time possible but lets say we have the following, look at image one, we will have a local address of 88.0/24 and a vpn address of 0.3 on router B and a local lan of 90.0/24 and a vpn address of 0.2 on router A as well as vpn address of 0.1 on the VPN sever. Just a note on that we can re use the same address on the VPN interfaces since they have no subnet and will be point to point addresses :)

Moving on in this situation lets say we have full internet connectivity set up on all the routers, the vpn cloud server is set up and the 2 clients have established a connection.
The behaviour we will see from here is that the VPN server will be able to ping 172.0.0.2 and 0.3, router A will be able to ping 172.0.0.1 but not 0.3 and router B will be able to ping 172.0.0.1 but not 0.2 and none of these routers will be able to ping any of the lan addresses that they are not directly connected two.

Why is this? well when you set up a VPN interface it will not create any routers for you, lets pick on router A, if you looked at its routing table it would have 4 entry's:
1 would be the directly attached route for the lan subnet so it can reach your LAN, 1 would be for the directly attached rout for your ISP connection so it knows how to get to the gateway, 1 would be for your 0.0.0.0/0 route so you can get out to any unknown addresses (the internet mainly) and the last one would be a route saying you can get to 172.0.0.1 through your VPN interface.

In the routes I mentioned there is nothing to do with the other lan addresses or even how to get to the 172.0.0.3 address, so once we try and either get to 192.168.88.0/24 or to 172.0.0.3 from router A it will look through those list of routers and try and find what matches it, since we dont have a specific route for it in there it will end up going out your ISP route to the internet rather than going through the tunnel.

To fix this on router A we need to make a route entry saying how to get to this address, we make a route for this saying the destination address is 192.168.88.0/24 and then have the gateway as the VPN interface going to the cloud server. NOTE only do this on point to point addresses never use the interface on anything with a subnet if it is not a directly attached route
Ok so now we have the extra route the traffic will now be put through the VPN tunnel up the the cloud server but once it reaches there the cloud server doesnt have a route on how to get to the 192.168.88.0/24 route either so instead of going through the other interface it will be sent out through the internet again and fail.
So you guessed it we will be adding a route on the VPN server on how to get to the 88.0/24 subnet.

Once this is done our packet will finally be able to get from the local lan on router A to the local lan on router B :D the next question is if the traffic is getting to router B from A why does my pings not work?
answer to that is while the traffic is able to now get to router B it has to return, router B will look at the source of this traffic and see it was from 192.168.89.0/24 subnet, since it will not have a route for this subnet it will throw this traffic out to the internet and it will never return.
I bet you can see a pattern here :) it is just the same as router A, so on router B we will need to apply a route with the destination of 89.0 going through its VPN interface so it can hit the cloud server then on the cloud server you need to set a route with the destination of 89.0/24 going through the router A's von interface :)

Questions are 100% welcome as my explanation is probably as sloppy as my picture
You do not have the required permissions to view the files attached to this post.
 
turnip
Frequent Visitor
Frequent Visitor
Posts: 86
Joined: Wed Sep 11, 2013 7:01 pm

Re: Push traffic to VPN on AWS

Thu Apr 07, 2022 10:35 am

You need to disable source/destination check on the EC2 instance.
Either from Actions -> Networking -> Change Source/Derstination Check, or through the CLI:
aws ec2 modify-instance-attribute --instance-id=<instance-id> --no-source-dest-check
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 19109
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Push traffic to VPN on AWS

Thu Apr 07, 2022 1:01 pm

Use wireguard!
 
djferdinad
just joined
Topic Author
Posts: 14
Joined: Wed Apr 06, 2022 5:12 am

Re: Push traffic to VPN on AWS

Sun Apr 10, 2022 6:37 am

I would recommend having the 'topology' image up while reading through this :)
badlol.png
OK lets pretend I didnt rust this in paint in the shortest time possible but lets say we have the following, look at image one, we will have a local address of 88.0/24 and a vpn address of 0.3 on router B and a local lan of 90.0/24 and a vpn address of 0.2 on router A as well as vpn address of 0.1 on the VPN sever. Just a note on that we can re use the same address on the VPN interfaces since they have no subnet and will be point to point addresses :)

Moving on in this situation lets say we have full internet connectivity set up on all the routers, the vpn cloud server is set up and the 2 clients have established a connection.
The behaviour we will see from here is that the VPN server will be able to ping 172.0.0.2 and 0.3, router A will be able to ping 172.0.0.1 but not 0.3 and router B will be able to ping 172.0.0.1 but not 0.2 and none of these routers will be able to ping any of the lan addresses that they are not directly connected two.

Why is this? well when you set up a VPN interface it will not create any routers for you, lets pick on router A, if you looked at its routing table it would have 4 entry's:
1 would be the directly attached route for the lan subnet so it can reach your LAN, 1 would be for the directly attached rout for your ISP connection so it knows how to get to the gateway, 1 would be for your 0.0.0.0/0 route so you can get out to any unknown addresses (the internet mainly) and the last one would be a route saying you can get to 172.0.0.1 through your VPN interface.

In the routes I mentioned there is nothing to do with the other lan addresses or even how to get to the 172.0.0.3 address, so once we try and either get to 192.168.88.0/24 or to 172.0.0.3 from router A it will look through those list of routers and try and find what matches it, since we dont have a specific route for it in there it will end up going out your ISP route to the internet rather than going through the tunnel.

To fix this on router A we need to make a route entry saying how to get to this address, we make a route for this saying the destination address is 192.168.88.0/24 and then have the gateway as the VPN interface going to the cloud server. NOTE only do this on point to point addresses never use the interface on anything with a subnet if it is not a directly attached route
Ok so now we have the extra route the traffic will now be put through the VPN tunnel up the the cloud server but once it reaches there the cloud server doesnt have a route on how to get to the 192.168.88.0/24 route either so instead of going through the other interface it will be sent out through the internet again and fail.
So you guessed it we will be adding a route on the VPN server on how to get to the 88.0/24 subnet.

Once this is done our packet will finally be able to get from the local lan on router A to the local lan on router B :D the next question is if the traffic is getting to router B from A why does my pings not work?
answer to that is while the traffic is able to now get to router B it has to return, router B will look at the source of this traffic and see it was from 192.168.89.0/24 subnet, since it will not have a route for this subnet it will throw this traffic out to the internet and it will never return.
I bet you can see a pattern here :) it is just the same as router A, so on router B we will need to apply a route with the destination of 89.0 going through its VPN interface so it can hit the cloud server then on the cloud server you need to set a route with the destination of 89.0/24 going through the router A's von interface :)

Questions are 100% welcome as my explanation is probably as sloppy as my picture

Thank you for your elaborate and demostrative instructions, for sure it gave me a clue of what is happening. So I did some research too and found this article
viewtopic.php?t=56254#p287503

Which indeed helped me, now my traffic (partially and all, whatever I want) is going to the VPN.

However I am facing another issue. I have a server that needs to send/receive packet from the same source and ports it is asked for.

At the moment the CHR is masquerading the IP and it is not working, I tried to change masquerade rule to same but still not working

Any advise?
 
djferdinad
just joined
Topic Author
Posts: 14
Joined: Wed Apr 06, 2022 5:12 am

Re: Push traffic to VPN on AWS

Sun Apr 10, 2022 6:39 am

You need to disable source/destination check on the EC2 instance.
Either from Actions -> Networking -> Change Source/Derstination Check, or through the CLI:
aws ec2 modify-instance-attribute --instance-id=<instance-id> --no-source-dest-check
I did this also, It was not a MUST ( I did it after achieve the traffic going to the VPN) but I am sure it will help.

Thanks

Who is online

Users browsing this forum: abdullanetworking, cmmike, mtkvvv and 51 guests