Details
-
Type: extRequest
-
Status: Closed
-
Priority: Major
-
Resolution: Done
-
Fix Version/s: 2021
-
Component/s: FIWARE-LAB-HELP
-
Labels:None
-
Sender Email:
-
HD-Node:Spain
Description
Hello Fiware Lab help.
We are setting up a VPN between our resources in Trento node and Spain node
using OpenVPN.
We have a OpenVPN server running on Spain node and a OpenVPN client on
Trento node connected to Spain server.
Everything works fine between client and server: they can ping each other
through VPN tunnel (interface TUN0).
When we want to ping machines between the two subnets the packets are
dropped as they leave the client/server connected through TUN0.
We have set up static routes consistent to the VPN:
Spain LAN --> Trento Lan use the OpenVPN Server on Spain lan as a gateway
Trento Lan --> Spain Lan use the OpenVPN Client on Trento lan as a gateway.
It seems that there is a firewall rule on nodes that blocks trafic coming
from a different private network than the one set up in the node itself. So
when we ping a machine on Spain from Trento LAN. the ping reaches the
SpainOPENVPN server and drops immediately after, probably because SPAIN
node firewall it sees trafic coming from our Trento LAN which has a
different network addres than our Spain LAN.
The same if we do the contrary.
A strong evidence that a node firewall rule could be the cause is found if
we use IP Masquerading on SpainOPENVPN Server on trafic coming from Trento
Lan, faking as if they come from SpainOPENVPN Server.
With masquerading they aren't dropped anymore on Spain, but they get lost
on the way back, when Trento see answers coming from Spain node, dropping
as they leave the Trento OPENVPN client.
Double masquerading (Spain and Trento OPENVPN tunnel endopints) isn't a
solution, cause it violates the Same Origin Policy and consequently the
answering packets are dropped cause they are seen as if they come from a
Man In The Middle (TRENTO01 ping request --> SPAIN Server Masquerading -->
SPAIN01 ping reply ---> SPAIN Server UNMasquerading – > Trento Client
MASQUERADING --> SOP policy on TRENTO01 --> drop.)
We are clueless.
Can you give us some insights to elaborate a workaround? Is it possible to
accept packets from a different private network on a node?
My FWLa account is:
luca.silvestri@ecogriddy.com <luca.silvestri@ecogriddy.com>
Many thanks,
–
Luca Silvestri - Founder & CEO @ Ecogriddy
_______________________________________________
Fiware-lab-help mailing list
Fiware-lab-help@lists.fi-ware.org
https://lists.fi-ware.org/listinfo/fiware-lab-help
[Created via e-mail received from: Luca Silvestri - Ecogriddy <luca.silvestri@ecogriddy.com>]
Hi, let me try to give you more information about this topic.
We have a private network on node Spain2 with address 192.168.148.0/27.
The other private network on node Trento has address 192.168.149.0/27.
On the Spain2’s node we have an instance of OPENVPN server, on the machine
called proxy with address 192.168.148.5.
On the Trento’s node there’s an instance of OPENVPN client, on the machine
called ecogriddy_proxy with address 192.168.149.12.
VPN tunnels is working well, from the machine with OPEN VPN SERVER (SPAIN
NODE) we can ping (or make http request) every machine on the Trento’s
network (and viceversa).
IP forwarding is enabled on OPENVPN server and OPENVPN client, the machines
that actually do the forward between tun0, eth0 and other machines.
On every host on Spain, static routes are defined to drive all the trafic
destined to Trento (192.168.149.0/27.) through the gateway 192.168.148.5.
On every host on trento, static routes are defined to drive all the trafic
destined to Spain (192.168.148.0/27 <http://192.168.149.0/27>.) through the
gateway 192.168.149.12
On the OpenVPN’s server and client there’s two iptables’s rules for
masquerading traffic.
ON SPAIN OPENVPN SERVER
Chain POSTROUTING (policy ACCEPT 681 packets, 47057 bytes)
pkts bytes target prot opt in out source
destination
19 1548 MASQUERADE all – any eth0 10.8.0.0/24
anywhere
9 756 MASQUERADE all – any eth0 192.168.149.0/27
anywhere
ON TRENTO OPENVPN CLIENT
41 3132 MASQUERADE all – any eth0 10.8.0.0/24
anywhere
10 840 MASQUERADE all – any eth0 192.168.148.0/27
anywhere
Every machine has a static route to address the remote network.
Now let’s go with an real example:
from machine 192.168.148.10 try to ping Trento’s openvpn client (the
endpoint of tunnel) 192.168.149.12
if I sniff the traffic on Spain’s open vpn server (192.168.148.5) I see
icmp echo request and reply, like this (ns1.spain.ecogriddy.com is
192.168.148.10, host on spain network).
16:09:08.515088 IP ns1.spain.ecogriddy.com > 192.168.149.12: ICMP echo
request, id 2327, seq 81, length 64
16:09:08.592832 IP 192.168.149.12 > ns1.spain.ecogriddy.com: ICMP echo
reply, id 2327, seq 81, length 64
16:09:09.523047 IP ns1.spain.ecogriddy.com > 192.168.149.12: ICMP echo
request, id 2327, seq 82, length 64
16:09:09.598805 IP 192.168.149.12 > ns1.spain.ecogriddy.com: ICMP echo
reply, id 2327, seq 82, length 64
16:09:10.531014 IP ns1.spain.ecogriddy.com > 192.168.149.12: ICMP echo
request, id 2327, seq 83, length 64
16:09:10.607809 IP 192.168.149.12 > ns1.spain.ecogriddy.com: ICMP echo
reply, id 2327, seq 83, length 64
Obviously, if I sniff tun0 i see the same messages, so I know tunnel is
working, forwarding to remote client is working, forwarding between
interfaces is working both side of the tunnel.
What happened is that the replies of the packets is not delivered to the
host who made the request by his openvpn’s endpoint.
We think that the replies, sent by the host who I called with the ping,
once arrived on the other side’s endpoint, are masked with the address of
the vpn server and therefore no longer be recognized by those who made the
initial request. If we *remove *the masquerading, packets have *source
address of the other network* and are no longer delivered.
Hope it helps.
Thanks in advance for your efforts.
Sincerely,
–
Luca Silvestri - Founder & CEO @ Ecogriddy
–
Luca Silvestri - Founder & CEO @ Ecogriddy