Community discussions

MUM Europe 2020
 
michaelcarey
newbie
Topic Author
Posts: 41
Joined: Thu May 11, 2006 8:03 am
Location: Port Lincoln, South Australia

EoIP & IPsec... trying to get it going again.

Sat Oct 07, 2017 12:05 pm

Hi Everybody,

Some time ago I successfully had an encrypted EoIP tunnel between two Mikrotik routers (together with IPsec encryption) working over a public WiFi network.
Since V6.37 (I think), I've not been able to get it working with IPsec.

I'm using the IPsec Secret field in the EoIP Interface to enable this function, Remove the IPsec Secret the EoIP tunnel works fine. The EoIP interfaces have their own IP addresses on the public WiFI network. Each end also has a working L2TP + IPsec Server that I can use to get access to each network when I am connected via the public Wifi Network.

As soon as I fill in the IPsec Secret field in each EoIP Interface, the tunnel "collapses". The IP addresses at each end of the tunnel are 192.168.50.12 and 192.168.50.14

0 ;;; EoIP via PLWireless
name="eoip-tunnel1" mtu=1500 actual-mtu=1500 l2mtu=65535
mac-address=00:00:5E:80:00:02 arp=proxy-arp arp-timeout=auto
loop-protect=on loop-protect-status=on loop-protect-send-interval=5s
loop-protect-disable-time=5m local-address=192.168.50.12
remote-address=192.168.50.14 tunnel-id=1 keepalive=2s,2 dscp=inherit
clamp-tcp-mss=no dont-fragment=no ipsec-secret="ABC123"
allow-fast-path=no

0 name="eoip-tunnel1" mtu=1500 actual-mtu=1500 l2mtu=65535
mac-address=00:00:5E:80:00:03 arp=proxy-arp arp-timeout=auto
loop-protect=on loop-protect-status=on loop-protect-send-interval=5s
loop-protect-disable-time=5m local-address=192.168.50.14
remote-address=192.168.50.12 tunnel-id=1 keepalive=2s,2 dscp=inherit
clamp-tcp-mss=no dont-fragment=no ipsec-secret="ABC123"
allow-fast-path=no

The entries in the log are;

19:27:36 ipsec,info initiate new phase 1 (Identity Protection): 192.168.50.14[500]<=>192.168.50.12[500]
19:28:36 ipsec,error phase1 negotiation failed due to time up 192.168.50.14[500]<=>192.168.50.12[500] ef338c157e915b1b:0000000000000000
19:28:46 ipsec,info initiate new phase 1 (Identity Protection): 192.168.50.14[500]<=>192.168.50.12[500]
19:29:46 ipsec,error phase1 negotiation failed due to time up 192.168.50.14[500]<=>192.168.50.12[500] fba3644a1fe6d8bb:0000000000000000
19:29:56 ipsec,info initiate new phase 1 (Identity Protection): 192.168.50.14[500]<=>192.168.50.12[500]
19:30:56 ipsec,error phase1 negotiation failed due to time up 192.168.50.14[500]<=>192.168.50.12[500] d70f3b2b3a969f6f:0000000000000000
19:31:05 ipsec,info initiate new phase 1 (Identity Protection): 192.168.50.14[500]<=>192.168.50.12[500]

The other end shows the same entries with the IP addresses swapped around. The string at the end of the "ipsec, error" message changes each time.

I can see a Dynamic Policy appearing in IP/IPsec/Policies, a Dynamic IPSec Peer appearing in /IP/IPsec/Peers... it all looks like it should be working, but it just doesn't.

I have an Input Chain Firewall rule accepting Protocol 47 GRE. I also have rules for UDP 500, 1701, 4500 and Protocol 50 (ipsec-esp) that are needed for incoming L2TP connections.

It used to work fine... now it doesn't. What am I missing? I am open to any ideas. :-)

Michael.
 
idlemind
Forum Guru
Forum Guru
Posts: 1112
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: EoIP & IPsec... trying to get it going again.

Sat Oct 07, 2017 5:52 pm

MTU changes when you enable IPSec but the default value should function.

The addresses you gave are private IPs. If they are really private IPs can you draw a picture of how these devices connect. EoIP (GRE) doesn't place nice with NAT but it is possible to traverses it (1:1 NAT). IPSec however will not without something like L2TP which is a NAT traversable tunneling tech.
 
michaelcarey
newbie
Topic Author
Posts: 41
Joined: Thu May 11, 2006 8:03 am
Location: Port Lincoln, South Australia

Re: EoIP & IPsec... trying to get it going again.

Sat Oct 07, 2017 11:26 pm

MTU changes when you enable IPSec but the default value should function.

The addresses you gave are private IPs. If they are really private IPs can you draw a picture of how these devices connect. EoIP (GRE) doesn't place nice with NAT but it is possible to traverses it (1:1 NAT). IPSec however will not without something like L2TP which is a NAT traversable tunneling tech.
I've attached a quick (crudely) hand drawn diagram of how my gear is set up and connected. This Public WiFi network has no internet connectivity, it is purely used to link remote sites together.

Your reply also gave me a clue as to where the problem might lie!!

Each Mikrotik Ethernet interface that faces the Public WiFi network has two IP addresses, one is used for the L2TP server and the other for the EoIP tunnel, both are on the same IP subnet. BUT, the one used for the L2TP server also has a Source NAT firewall rule so I can access devices on the Public WiFi network from inside the private networks behind each Mikrotik router, essentially treating the Public WiFi network like it's the internet. I think this is where the problem will be found.

I think I will have to place the EoIP interface on a different IP subnet than the ones used for L2TP/NAT traversal, or specifically exclude the IP addresses used for the EoIP tunnel from the Source NAT firewall rule.

I'll do some more experimentation later today.

Michael.
You do not have the required permissions to view the files attached to this post.
 
idlemind
Forum Guru
Forum Guru
Posts: 1112
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: EoIP & IPsec... trying to get it going again.

Sun Oct 08, 2017 3:13 pm

Add a specific route for each remote IP to use the EoIP interface and make sure you source NAT only targets traffic leaving (out) the other interface with dst address of 0.0.0.0/0 (default).

This will make the routing side source the EoIP traffic to originate from the right IP and prevent it from being SNATd
 
michaelcarey
newbie
Topic Author
Posts: 41
Joined: Thu May 11, 2006 8:03 am
Location: Port Lincoln, South Australia

Re: EoIP & IPsec... trying to get it going again.

Mon Oct 09, 2017 3:45 am

Add a specific route for each remote IP to use the EoIP interface and make sure you source NAT only targets traffic leaving (out) the other interface with dst address of 0.0.0.0/0 (default).

This will make the routing side source the EoIP traffic to originate from the right IP and prevent it from being SNATd
Thanks again for the input into my EoIP problem. I changed the EoIP interfaces to use different IP addresses/subent (192.168.51.0/24 instead of 192.168.50.0/24) and the EoIP tunnel came up with IPsec security... it is working!! ;-)

I'm happy to use the soution of using a different IP subnet for the EoIP interface, but I was wondering if you could clarify your solution mentioned above? Not quite sure I understand it.

On the remote end (with the RB750) the EoIP interface is bridged directly to Ether5. The idea of this setup is that I can plug my laptop into Ether5 and it then appears to be physically connected to the 192.168.0.0/24 network on the RB750UP end of the setup.

Michael.

Who is online

Users browsing this forum: msatter, nasirhafeez and 182 guests