Virtual Mikrotik RouteOS CHR with ip public, EoIP not work.

[trabogano]

Hi, i have a dedicated server on Ionos with Proxmox.

Server wan interface is enp35s0
Has a public ip 217.xxx.xxx.10/32
Gateway 10.255.255.1

I have an additional ip address that ionos delivered me via vlan1010 for using it in virtual machine.
217.xxx.xxx.164/32

My /etc/network/interface:

auto lo
iface lo inet loopback

auto enp35s0
iface enp35s0 inet static
address 217.xxx.xxx.10/32
gateway 10.255.255.1
#Wan

iface enp36s0 inet manual

iface enx2ecbfb84894d inet manual

auto vmbr0 <-----RouerOS has his ether1 in this bridge with ip 217.xxx.xxx.164/32 and work it can go in internet and receive all ports and protocols
iface vmbr0 inet manual
bridge-ports vlan1010
bridge-stp off
bridge-fd 0
post-up ip link set vmbr0 promisc on
post-down ip link set vmbr0 promisc on
#Br-Wan

auto vmbr1
iface vmbr1 inet manual
bridge-ports none
bridge-stp off
bridge-fd 0
bridge-vlan-aware yes
bridge-vids 2-4094
#Br-VMs

auto vlan1010
iface vlan1010 inet manual
vlan-raw-device enp35s0

In RouterOS CHR i am able to receive gre connection, i have set a pptp server and from a remote side i am able to connect on it with a pptp client, seems everything work ok except EoIP tunnels... in ip firewall connections i can see outgoing eoip gre connection stuck in "confirmed state". I don't have any in/out firewall rule.
I have read around about try to set Promiscuous Mode in interfaces and bridges for solve this problem, i have do some test but still not work

Is my first time approaching promiscuous mode on linux, the interfaces all seem to be in promiscuous mode right?

root@proxmox:~# ip a | grep PROMISC
2: enp35s0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
6: vlan1010@enp35s0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
7: vmbr0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
8: tap100i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr0 state UNKNOWN group default qlen 1000
9: tap100i1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr1 state UNKNOWN group default qlen 1000


Thank You.

 

[trabogano]

I have changed my network configuration in the hope something changes:
auto lo
iface lo inet loopback

iface enp35s0 inet manual
#Wan

iface enp36s0 inet manual

iface enx2ecbfb84894d inet manual

auto vmbr1
iface vmbr1 inet manual
bridge-ports none
bridge-stp off
bridge-fd 0
bridge-vlan-aware yes
bridge-vids 2-4094
#Br-VMs

auto vmbr0
iface vmbr0 inet static
address 217.xxx.xxx.10/32
gateway 10.255.255.1
bridge-ports enp35s0
bridge-stp off
bridge-fd 0
bridge-vlan-aware yes
bridge-vids 2-4094
post-up ip link set enp35s0 promisc on
post-up ip link set vmbr0 promisc on
post-down ip link set enp35s0 promisc off
post-down ip link set vmbr0 promisc off
#Br-Wan

In Virtualized RouterOS i have created vlan 1010 and moved public ip address from ether1 to vlan1010, navigation ok, i can receive pptp clients ovpn clients but eoip tunnels cant go UP state

Edit:
Gre tunnels works perfectly eoip no.

 

[guletz]

Hi,

Could be a mtu problem. Vlan 1010 must have a smaller mtu then enp3s0(1500 - vlan header) if you want to be on the safe side.

You could test your actual mtu in CHR, using ping with different package size, using checkbox "do not fragment".
Start with 1200 size and rise until you start to lose packages.

After you find the actual mtu, then on eoip settings, adjust mtu with this real mtu value(discovered with ping as I allready explain)

As a side note, eoip is not the best solution(it use a lot of cpu), and the tunnel is not secure(no encryption layer).

A better solution is to use others variants:
- zerotier, suported by CHR, and any linux/android
- vxlan over ipsec

Good luck/ Bafta !

 

[trabogano]

Hi,

Could be a mtu problem. Vlan 1010 must have a smaller mtu then enp3s0(1500 - vlan header) if you want to be on the safe side.

You could test your actual mtu in CHR, using ping with different package size, using checkbox "do not fragment".
Start with 1200 size and rise until you start to lose packages.

After you find the actual mtu, then on eoip settings, adjust mtu with this real mtu value(discovered with ping as I allready explain)

As a side note, eoip is not the best solution(it use a lot of cpu), and the tunnel is not secure(no encryption layer).

A better solution is to use others variants:
- zerotier, suported by CHR, and any linux/android
- vxlan over ipsec

Good luck/ Bafta !

Very stange... I can ping with 1500 size without fragmentation the remote side, Mtu seems perfect. Yes i know there is other L2 link but i need eoip for retrocompatibility.