Mikrotik IPSEC VPN with no WAN <SOLVED>

I have an IPSEC VPN setup between two sites. The connection is established however I am having a bit of trouble getting the proper traffic to traverse.

Site 1 is where I am having some issues routing. The architecture is as follows: ISP → Main Router → Mikrotik. The Main Router is the gateway for the network 192.168.1.1/24 and the Mikrotik is 192.168.1.100 via static DHCP. The Mikrotik is configured as a bridge and ethernet 2 connects the Mikrotik bridge interface to the Main Router. The Mikrotik has an IPSEC VPN configured to connect to site 2 with a phase 2 of 192.168.1.0/24 and 192.168.2.0/24 on the remote side. What i’d like to happen is the device on ethernet 3 (192.168.1.20) on the Mikrotik route through the VPN. I think the issue is the device on ethernet 3 is the default gateway is the Main Router. I don’t see an easy way to make the Mikrotik be the gateway unless I double NAT which I would like to prevent.

I’ve tried a few things like setting a static route on the Main Router to kick traffic back to the Mikrotik and that kinda works but not exactly. I’ve tried a few different src and dst NATs on the Mikrotik.

Anyone have any ideas? Hopefully the scenario makes some kind of sense!

Hi

You mentioned “Main Router to kick traffic back to the Mikrotik and that kinda works but not exactly”.

Would you mind to elaborate, as this could be the easiest approach.

I added a static route on the main router for 192.168.2.0/24 via 192.168.1.100. This bounces the traffic back into the Mikrotik.

Sure, but what did you meant by " that kinda works but not exactly"

Sorry! I completely miss read that doh… It is hard to explain but the results were not as expected. For example I can ping all throughout the 192.168.1.0/24 network and that works. However, when I try to open a TCP connection I start seeing what I might describe as looping?

For example in wireshark a TCP connection from 192.168.2.10 to 192.168.1.20:

SRC: 192.168.2.10 DST: 192.168.1.20 DATA: TCP SYN
SRC: 192.168.1.20 DST: 192.168.2.10 DATA: TCP SYN/ACK
SRC: 192.168.2.10 DST: 192.168.1.20 DATA: TCP ACK

Connection Established

SRC: 192.168.2.10 DST: 192.168.1.20 DATA: HTTP Request
SRC: 192.168.1.1 DST: 192.168.2.10 DATA: HTTP Response
SRC: 192.168.2.10 DST: 192.168.1.20 DATA: Retransmit request
SRC: 192.168.1.1 DST: 192.168.2.10 DATA: HTTP Response
SRC: 192.168.2.10 DST: 192.168.1.20 DATA: Retransmit request
SRC: 192.168.1.1 DST: 192.168.2.10 DATA: HTTP Response
SRC: 192.168.2.10 DST: 192.168.1.20 DATA: Retransmit request
SRC: 192.168.1.1 DST: 192.168.2.10 DATA: HTTP Response
SRC: 192.168.2.10 DST: 192.168.1.20 DATA: Retransmit request
SRC: 192.168.1.1 DST: 192.168.2.10 DATA: HTTP Response
SRC: 192.168.2.10 DST: 192.168.1.20 DATA: Retransmit request
SRC: 192.168.1.1 DST: 192.168.2.10 DATA: HTTP Response
SRC: 192.168.2.10 DST: 192.168.1.20 DATA: FIN Give Up

At this point the original connection isn’t happy because the sources for the responses is getting re-written and it doesn’t think it is getting any data.

SRC: 192.168.1.20 DST: 192.168.1.10 DATA: TCP SYN/ACK → typo here? target should be “.2.10”

You seem to have somewhere NAT translation active with that forwarding. You’ll need to disable that and then it will work fine.

SRC: 192.168.1.1 DST: 192.168.2.10 DATA: HTTP Response

The strange part is, if there was some nat rule, it should apply to the initial tcp handshake too! That is not the case here. So something else is at play.

Yea that was a typo good catch. I edited the post to correct.

I agree! Which is why it kinda works but not exactly :slight_smile:

The main router is a FIOS router and there isn’t really much I can do settings wise. So who knows what they are doing under the covers…

Another option: have MT as default gw, and have it forward to FIOS/main router if needed

I tried setting that up but the device I’m trying to get to is an IoT device that boots only from DHCP. So I cannot change any IP settings :-/ making all of this more difficult.

can you disable dhcp on main router? your internal lan range if fixed anyway, have dhcp server active on MT.

I ended up adding a bridge, changing subnets, and moving the port I wanted to pass through the VPN onto that bridge and doing all the appropriate routing. That is working perfectly. Not quite the setup I was aiming for but it works.

Thanks for the ideas!