Score:1

deploying pfSense in OVH public cloud as a DHCP server in HA

za flag

I am trying to deploy two pfSense in the OVH public cloud (OpenStack). Each has its own public IPs and public connectivity works without any problem.

Things become more complicated on the vRack part (private network).

A network was created using both regions and subnets as defined below (no DNS nor routes are defined):

  "GRA": {
    "start":"10.127.0.1",
    "end":"10.127.127.254",
  },
  "SBG": {
    "start":"10.127.128.1",
    "end":"10.127.255.254",
  },
  "network":"10.127.0.0/16",
  "vlanId": 37
  "enableDhcp":False,
  "enableGatewayIp":False,

Each pfSense is in its region as follows:

  "pf1": {
    "ip":"10.127.0.1/16",
    "MTU": 9000,
    "region":"GRA",
  },
  "pf2": {
    "ip":"10.127.128.1/16",
    "MTU": 9000,
    "region":"SBG",
  },

Even thought DHCP is disabled on the network, an IP is attributed on each port of the network. (by OpenStack, only visible from OVH's horizon interface). It is possible to assign a static address to the port being assigned to the VM. (Which I did for the pfSense 1 and 2) If I assign corresponding IPs to each pfSense, communication works (ping, curl, probably everything).

If, on the other hand, I add a third machine (named CL1) in the same region/network (pf1 is the DHCP server).

Using DHCP:

  • DHCP request is received by the firewall
  • DHCP reply is sent by the firewall
  • DHCP reply is not received by the client.
  • Using a static IP assigned by the firewall (static ARP) results in the same behavior

Using static IP:

  • Using a static IP assigned by the firewall (static ARP) to the client, but manually or a random IP (within the network) results in the same behavior:
    • ping from pf2 to CL1:
      • tcpdump from pf1 sees ping request but no replies.
      • pf2 does not receive any replies.
      • CL1 receive and reply.
    • ping from CL1 to pf2:
      • CL1 send ping.
      • pf1 and pf2 sees nothing.
  • Using OpenStack assigned IP address:
    • CL1 ping and curl works:
      • if CL1 ping pf1 => only pf1 sees traffic, ping works.
      • if CL1 ping pf2 => both pf1 and pf2 see traffic, ping works.
      • if pf2 ping CL1 => pf1 does not see traffic, ping works.

From which I conclude:

  • pf1 and pf2 can communicate because they use OpenStack assigned IP.
  • CL1's traffic only works if it is using OpenStack assigned address.
  • If CL1 is making an ARP request on the network, it is not received by either pf1 nor pf2.

FYI:

  • vRack is a layer 2 network provided by OVH.
  • OpenStack requires a VLAN ID to work (according to OVH documentation).
  • Though I am using JSON to express some information, this is not the code that was used to create said network or interface instances.
  • Rules in the pf1&2 LAN: accept everything coming and going to the LAN (all protocols, only IPv4 traffic).
  • Security Groups: authorize everything IN and OUT (all protocols, only IPv4 traffic).

What I am trying to achieve here:

  • DHCP network managed by pfSense.
  • later on: use's vRack multicast capabilities in the vRack (across region) required for HA
  • later on: enable pfSense HA on the vRack (another cross region network will be created at that time)

All of this is achievable from a bare-metal machine, but is not what I want : I am only using OVH public cloud VMs.

If you can give me any tips, things to try or anything to solve this. Thank you in advance.

If you require any more information, please ask. Regards, Dboy

I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.