The SDN / VXLAN Proxmox saga continues...

After posting this I noticed some strange behavior. I was getting ping packets fine and nmap was showing the https service for my new firewall. The problem was when I would navigate to my new firewall's management site it wouldn't work. I would get ssl_error_rx_record_too_long on Firefox and timeouts on Chrome.

I opened up Wireshark and noticed the return traffic for SSL was severely delayed and appeared malformed.

What I missed in my instructions is that VXLAN takes up 50 bytes for encapsulation, so for the endpoints within the internal network I had to set a custom MTU of 1450 so that the VXLAN encapsulation could happen within the 1500 limit of the interface on the Proxmox nodes.

After configuring this on one of the internal machines and it worked to get to the site I thought maybe I had to also configure the 1450 MTU on the firewall's internal interface. I did that and was immediately getting some rapid drop-connect-and-drops repeatedly on my home network so I reverted that change. I really don't know why changing the MTU on the internal interface of the firewall would cause that on my main network but it did, so I reverted it. It seems any device on that internal LAN will need the MTU change other than the firewall, for all the traffic to work properly.

Now it looks like the next thing to do is to start putting various machines behind the new routers to start segmenting my lab network, and get it off of the flat network for increased security and traffic isolation and control.

The Proxmox guide I linked earlier will give more details on the 50 byte allocation for VXLAN.

@zrail @r3pek @junq @train

#homelab #proxmox #networking #sdn #vxlan #ovs #selfhosted #selfhostingmastodon #MTU