Uploaded image for project: 'Help-Desk'
  1. Help-Desk
  2. HELP-3510

FIWARE.Request.Lab.Spain.Problem with VPN between nodes.

    Details

    • Type: extRequest
    • Status: Closed
    • Priority: Major
    • Resolution: Done
    • Fix Version/s: 2021
    • Component/s: FIWARE-LAB-HELP
    • Labels:
      None

      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>]

        Activity

        Hide
        aristi Aristi Galani (Inactive) added a comment -

        Dear Luca

        We forwarded your issue to Trento & Spain node helpdesk teams in order to
        provide help.

        Kind regards
        IWAVE team, on behalf of helpdesk team

        _______________________________________________
        Fiware-lab-help mailing list
        Fiware-lab-help@lists.fi-ware.org
        https://lists.fi-ware.org/listinfo/fiware-lab-help

        Show
        aristi Aristi Galani (Inactive) added a comment - Dear Luca We forwarded your issue to Trento & Spain node helpdesk teams in order to provide help. Kind regards IWAVE team, on behalf of helpdesk team _______________________________________________ Fiware-lab-help mailing list Fiware-lab-help@lists.fi-ware.org https://lists.fi-ware.org/listinfo/fiware-lab-help
        Hide
        fw.ext.user FW External User added a comment -

        Hi Ignacio.

        Spain2 Node:
        proxy (VPN endpoint on Spain - OpenVPN Server) - 192.168.148.5
        ns1 (generic machine on Spain node that we tested for ping) - 192.168.148.10
        ns2 (generic machine on Spain node that we tested for ping) - 192.168.148.11

        Trento Node:
        VPN endpoint on Trento (client OpenVPN): ecogriddy_proxy - IP 192.168.149.12
        context_broker (generic machine on Trento node that we tested for ping) -
        IP 192.168.149.7

        You can see that from endpoints ping works perfectly well when directed to
        any of the remoted machines, even across nodes.

        Please since i'm off office today, CC ticket answers or other requests to
        my collaborator aldo.biasi@gmail.com that I instructed to help you further
        on this topic.
        Best regards,
        Luca Silvestri

        Show
        fw.ext.user FW External User added a comment - Hi Ignacio. Spain2 Node: proxy (VPN endpoint on Spain - OpenVPN Server) - 192.168.148.5 ns1 (generic machine on Spain node that we tested for ping) - 192.168.148.10 ns2 (generic machine on Spain node that we tested for ping) - 192.168.148.11 Trento Node: VPN endpoint on Trento (client OpenVPN): ecogriddy_proxy - IP 192.168.149.12 context_broker (generic machine on Trento node that we tested for ping) - IP 192.168.149.7 You can see that from endpoints ping works perfectly well when directed to any of the remoted machines, even across nodes. Please since i'm off office today, CC ticket answers or other requests to my collaborator aldo.biasi@gmail.com that I instructed to help you further on this topic. Best regards, Luca Silvestri
        Hide
        fw.ext.user FW External User added a comment -

        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

        Show
        fw.ext.user FW External User added a comment - 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

          People

          • Assignee:
            jicg José Ignacio Carretero Guarde
            Reporter:
            fw.ext.user FW External User
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: