Community discussions

MikroTik App
 
dnordenberg
Member Candidate
Member Candidate
Topic Author
Posts: 126
Joined: Wed Feb 24, 2016 8:00 pm

IPsec site to site tunnels, security issue question?

Mon Mar 22, 2021 2:09 am

Hi!
I have multiple IPsec policies for different local subnets for different purposes and each subnet is used by equipment on a specific ethernet port. Each subnet has a ethernet port assigned to a bridge interface and a matching IP (which is set as gateway on the devices on that ethernet port).

Setup is working fine, devices on each subnet communicats with remote subnets through the different policies. But now my question. Since policies are not bound to a specific interface I guess it would be possible to send in traffic on any port to reach remote subnets other than the intended one for this specific port/subnet by just setting an fixed IP belonging to another subnet? How do I prevent this so each port/subnet can only access the policy intended for that subnet? If VTI (virtual tunnel interface) was supported I would have just placed that VTI in the right bridge together with a ethernet port but without VTI there does not seem to be a way to bind policies to a specific bridge/interface? The only way I can think of to make this secure would be a firewall rule that prevents traffic to/from other subnets than intended for each bridge/port. Is that the correct approach?

Kind regards
David
Last edited by dnordenberg on Mon Mar 22, 2021 12:18 pm, edited 1 time in total.
 
dnordenberg
Member Candidate
Member Candidate
Topic Author
Posts: 126
Joined: Wed Feb 24, 2016 8:00 pm

Re: IPsec site to site tunnels, security issues?

Mon Mar 22, 2021 12:08 pm

My example config below. I want to make sure it doesn't work if a user connects something on bridge_vpn1 and sets and IP of bridge_vpn2 subnet and that way could reach something outside the policy defined for his bridge_vpn1 subnet. I know it would not work straight away because router has another IP set for this subnet but I think the client could still at least send packets to an host on a subnet he shouldn't be able to access by directing the packet to bridge_vpn1 gateway IP but claiming a source IP of bridge_vpn2 subnet, right? But I want this to be really secure so i can be certain a user can not access anything else than the subnet of the correct bridge_vpnX policy.
/interface bridge
add name=WAN
add name=bridge_vpn1
add name=bridge_vpn2
add name=bridge_vpn3
/ip ipsec peer
add address=xxx.xxx.xxx.xxx/32 exchange-mode=ike2 name=ipsec_vpn
/ip ipsec profile
set [ find default=yes ] dh-group=modp1536 enc-algorithm=aes-256 hash-algorithm=sha256 lifetime=12h
/ip ipsec proposal
set [ find default=yes ] auth-algorithms=sha256 enc-algorithms=aes-256-cbc lifetime=1h pfs-group=modp1536
/interface bridge port
add bridge=WAN interface=ether1
add bridge=bridge_vpn1 interface=ether2
add bridge=bridge_vpn2 interface=ether3
add bridge=bridge_vpn3 interface=ether4
add bridge=WAN interface=ether5
/ip address
add address=10.101.1.1/24 interface=bridge_vpn1 network=10.101.1.0
add address=10.151.1.1/24 interface=bridge_vpn2 network=10.151.1.0
add address=10.201.1.1/24 interface=bridge_vpn3 network=10.201.1.0
/ip dhcp-client
add disabled=no interface=WAN
/ip ipsec identity
# Suggestion to use stronger pre-shared key or different authentication method
add my-id=key-id:testvpn peer=ipsec_vpn remote-id=key-id:XXXX secret=XXXXXX
/ip ipsec policy
# For VPN1
add dst-address=10.100.1.0/24 peer=ipsec_vpn sa-dst-address=xxx.xxx.xxx.xxx sa-src-address=xxx.xxx.xxx.xxx src-address=10.101.1.0/24 tunnel=yes
# For VPN2
add dst-address=10.150.1.0/24 peer=ipsec_vpn sa-dst-address=xxx.xxx.xxx.xxx sa-src-address=xxx.xxx.xxx.xxx src-address=10.151.1.0/24 tunnel=yes
# For VPN3
add dst-address=10.200.1.0/24 peer=ipsec_vpn sa-dst-address=xxx.xxx.xxx.xxx sa-src-address=xxx.xxx.xxx.xxx src-address=10.201.1.0/24 tunnel=yes
 
dnordenberg
Member Candidate
Member Candidate
Topic Author
Posts: 126
Joined: Wed Feb 24, 2016 8:00 pm

Re: IPsec site to site tunnels, security issue question?

Tue Mar 23, 2021 7:39 pm

No one who can point me in the right direction here? I don't need a full solution, just an hint on the right approach here. Do I need to create FW rules maybe which would be basically copies of the policies (but inverted)?
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: IPsec site to site tunnels, security issue question?

Tue Mar 23, 2021 10:51 pm

The question you ask has little to do with IPsec policies. If I get you right, what you actually want is to make sure that a device connected to a given interface cannot use an address from a subnet not associated to that interface.

So the permissive firewall rules must match on both in-interface and src-address.

But to prevent the user from getting to the subnet he wants by connecting his device to the corresponding interface, you'd need 802.1x (which can also be fooled to some extent by using a dumb switch, but not to get to a different VLAN/subnet than the one you have the authentication for).
 
dnordenberg
Member Candidate
Member Candidate
Topic Author
Posts: 126
Joined: Wed Feb 24, 2016 8:00 pm

Re: IPsec site to site tunnels, security issue question?

Thu Mar 25, 2021 5:55 pm

Hi! Thank you so much for your answer :)
I don't care what IP a user tries to set but I really don't want him to be able to gain access to networks on another policy than the one I intended for devices connected to the corresponding bridge.

Ok so there isn't a way to "hard tie" a policy for a specific interface or bridge?
Yes that was what I thought for myself too, I create one forward fw rule for each bridge (in-interface) and possible dst-address (which is the policy dst network, not the src-address?).
I don't care if user fakes his IP, it is the dst what is important, he should not reach anything else than his policy dst network :)

Don't think 802.1x is what I'm lookin for? A authorized user could still do tricks to get to the policies I don't want him to have access to I think?
I think this whole setup had been so much easier with VTIs, then I would just place the VTI inside the bridge and that would make sure everything stays inside that bridge (like it would inside a VLAN on a switch). I think I have some troubles with policies being a L3 thing implemented across the device entire L2 but I really would like them to be tied to a specific L2 segment...
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: IPsec site to site tunnels, security issue question?

Fri Mar 26, 2021 9:44 am

While I'd like to have VTIs too, they're still L3 interfaces, so adding them to bridges is not possible.

802.1x only allows an authenticated device to connect to a given port of a switch and eventually make that port an access one to a specific VLAN, but doesn't care about IP addresses in any way.

The IPsec policies' traffic selectors are intended to be restricted at both local and remote subnets, so for a local user with an address from subnet LA to access remote subnet RA, there must be a matching policy, LA <-> RA. If another local user with an address from subnet LB wants to access a remote subnet RB, there must be another matching policy. As there is no LA <-> RB policy, nor a LB <->RA one, preventing the users from spoofing their IP addresses is sufficient to prevent them from reaching remote subnets they shouldn't reach. If you have 0.0.0.0/0 at your end, then of course the access to individual remote subnets doesn't depend on the source address.
 
dnordenberg
Member Candidate
Member Candidate
Topic Author
Posts: 126
Joined: Wed Feb 24, 2016 8:00 pm

Re: IPsec site to site tunnels, security issue question?

Fri Mar 26, 2021 3:36 pm

While I'd like to have VTIs too, they're still L3 interfaces, so adding them to bridges is not possible.
Oh :(
The IPsec policies' traffic selectors are intended to be restricted at both local and remote subnets, so for a local user with an address from subnet LA to access remote subnet RA, there must be a matching policy, LA <-> RA. If another local user with an address from subnet LB wants to access a remote subnet RB, there must be another matching policy. As there is no LA <-> RB policy, nor a LB <->RA one, preventing the users from spoofing their IP addresses is sufficient to prevent them from reaching remote subnets they shouldn't reach. If you have 0.0.0.0/0 at your end, then of course the access to individual remote subnets doesn't depend on the source address.
I'm still not convinced here. What is stopping a user in LA from spoofing his IP as a LB and force the packet to the routers LA interface. My understanding is that since there is no interface matching in policies the router will continue forwarding his packet to RB since to the router this looks like a LB <-> RB communication even when packet has entered a LA interface.
But what will fail later is that any returned packets will not reach the original computer since router will look for the sending IP in LB interfaces and there is no one there with the claimed IP since it is spoofed. But that is not a real security feature since the RB target could be UDP traffic so depending on the protocol harm could be done without any possible return path of the packets.

I could be all wrong here but I can't see what setting would prevent my fears from being true and make it work like you described when there is no strict interface matching in policies :(
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: IPsec site to site tunnels, security issue question?

Fri Mar 26, 2021 3:45 pm

What is stopping a user in LA from spoofing his IP as a LB and force the packet to the routers LA interface?
This rule:
/ip firewall filter add chain=forward in-interface=if_A src-address=!ip.sub.net.A/mask action=drop

To be precise, it doesn't stop the user from sending a packet with a spoofed source address, but it stops such packets from being forwarded The IPsec policy cherry-picks traffic as the very last step of the packet processing, even after src-nat. So packets dropped by the above rule will never reach the policy matching stage.

The above is just an illustrative example, I personally prefer firewall setups that drop everything except what you explicitly tell them not to drop.

Your legal users will let you know quickly that you forgot to allow something. Your illegal users will never complain you forgot to drop something.
 
dnordenberg
Member Candidate
Member Candidate
Topic Author
Posts: 126
Joined: Wed Feb 24, 2016 8:00 pm

Re: IPsec site to site tunnels, security issue question?

Sat Mar 27, 2021 2:50 am

Ah, I thought we were still talking about the situation without fw rules.
Absolutely right, allow rules and then dropp all at the end is a much better approach :)

Thank you!
 
dnordenberg
Member Candidate
Member Candidate
Topic Author
Posts: 126
Joined: Wed Feb 24, 2016 8:00 pm

Re: IPsec site to site tunnels, security issue question?

Thu Apr 01, 2021 8:55 am

While I'd like to have VTIs too, they're still L3 interfaces, so adding them to bridges is not possible.
I think you may be wrong here, at least I hope so ;-)
Yes they are L3 interfaces of course but isn't the whole point of VTIs is that they appear as a virtual hw like interface so you can use them in a L2 manner but of course it won't work with anything else than IP since it is still a L3 tunnel behind the virtual interface....
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: IPsec site to site tunnels, security issue question?

Thu Apr 01, 2021 11:05 am

The whole point of a VTI is that you can use regular routing rather than traffic matching by selectors, which quickly turns into a nightmare if you use more subnets at each end of a link. VTI violates the security concept of IPsec in terms that if you use VTI, traffic matching an existing traffic selector must be accepted even if it arrives through some other path than the IPsec SA bound to that traffic selector, because the two peers of the VTI tunnel must negotiate a traffic selector matching all traffic (0.0.0.0/0 <-> 0.0.0.0/0).

The difference between L2 and L3 interface is not in what you can route through them but in the fact that the L3 ones don't transport the L2 (MAC addresses, Ethertype) headers. Hence no ARP (as it has no purpose there), no ?STP, and no possibility to become a part of a bridge. Examples: IPIP (ipencap), GRE/IP (i.e. not GRETAP), various flavors of PPP (L2TP, PPTP, SSTP) without BCP...

You can use IPsec to encrypt an EoIP tunnel or an L2TP/BCP tunnel - both are L2 tunnels so their interfaces can be made member ports of bridges, but EoIP is Mikrotik's proprietary misuse of GRE and L2TP/BCP is a standard one but only seems to be supported by Mikrotik, so you need a Mikrotik device at both ends. And L2 tunneling has a lot of drawbacks (all the broacast traffic being transported, more overhead per byte of IP payload) and as far as I can see, no advantages for your use case.

Who is online

Users browsing this forum: eworm and 78 guests