Troubleshooting Networking Issues: pfSense WAN Configuration and Proxmox Setup, Single IP

[SkinnyBruv]

G'day,

I am currently hosting a VPS with a single IP address (149.88.106.191) and a gateway at 149.88.106.254. I have successfully configured Proxmox with this IP, and DNS is functioning properly. The server can ping external addresses such as 1.1.1.1, 8.8.8.8, as well as the local IP (149.88.106.191) and the gateway (149.88.106.254).

However, I have encountered an issue with a virtual machine (VM) created under vmbr0 (pfSense). While the VM can successfully ping the local IP (149.88.106.191), it is unable to reach the gateway at 149.88.106.254, and also cannot reach 1.1.1.1, 8.8.8.8

Here is a snippet of the network configuration in the /etc/network/interfaces file:

  GNU nano 7.2                 /etc/network/interfaces                        
# network interface settings; autogenerated
# Please do NOT modify this file directly, unless you know what
# you're doing.
#
# If you want to manage parts of the network configuration manually,
# please utilize the 'source' or 'source-directory' directives to do
# so.
# PVE will preserve these directives, but will NOT read its network
# configuration from sourced files, so do not attempt to move any of
# the PVE managed interfaces into external files!

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
        address 149.88.106.191/25
        gateway 149.88.106.254
       
auto vmbr0
iface vmbr0 inet static
        address 172.16.23.1/24
        bridge-ports eth0
        bridge-stp off
        bridge-fd 0

        post-up   echo 1 > /proc/sys/net/ipv4/ip_forward
        post-up   iptables -t nat -A POSTROUTING -s '172.16.23.1/24' -o eth0 -j>
        post-down iptables -t nat -D POSTROUTING -s '172.16.23.1/24' -o eth0 -j>

auto vmbr1
iface vmbr1 inet static
        address 172.16.24.1/24
        bridge-ports none
        bridge-stp off
        bridge-fd 0

source-directory /etc/network/interfaces.d
source-directory /run/network/interfaces.d

How do i route the vmbr0 to the gateway using IPTables or any other suggestion?

Or is there an easier way?

 

[Pifouney]

Hey ,

I wonder you re mixing many thinvs in one, and forgot steps.

You re sayi g you ve only 1 public ip adress. Well, you cannot use vmbr0 for any orher VM, EXCEPT THAT YOU TAKE ANOTHER IP PUBLIC @ dedicated to thia VM ( with a /32 submask)

What are you really want to do?

If pfsense need to be the only one that speak with the public @, you need to unload this IP before from your proxmox
(Be aware: it s possible, but hard cfg to do)

If you don't want to break your actual configuration, then you need to create a vmbr between prx VE and pfsense.
Then, nat all traffic from vmbr0 to your vmbr1 pfsense WAN adress.

The most difficult, but the best configuration is:
Preconfigure all your internal VE network.
Make all running before any hard bypass from pVE.
Then, if all running good, unload public IP in pVE configuration, BUT don 't apply it.
Give the public ip address to pfense ( with the same conf params from pVE if conf)

Then, revoot and pray yours gods that you've nothing missconfigured


That ( for me) the 3 way that you can use.

The easiest way is the first solution, needing more payment for IP, but don't broke nothing in pVE configuration.

all 2 other solutions works, but be really safe in your actions. The advantage of them are you can continue to have only 1 public ip adress.

 

[SkinnyBruv]

For individuals utilizing cloud-init's network configuration capabilities:

The following configuration proved effective in my case.

#/etc/network/interfaces.d/50-cloud-init:
# loopback
auto lo
iface lo inet loopback
        dns-nameservers 1.1.1.1 8.8.8.8
        dns-search datapacket.com

# public IP address
auto eth0
iface eth0 inet static
        address 149.88.106.191/25
        gateway 149.88.106.254

#/etc/network/interfaces
auto lo
iface lo inet loopback

iface eth0 inet manual

auto vmbr0
iface vmbr0 inet static
        address 172.16.23.1/24
        bridge-ports none
        bridge-stp off
        bridge-fd 0

auto vmbr1
iface vmbr1 inet static
        address 172.16.24.1/24
        bridge-ports none
        bridge-stp off
        bridge-fd 0

        post-up   echo 1 > /proc/sys/net/ipv4/ip_forward
        post-up   iptables -t nat -A POSTROUTING -s '172.16.23.0/24' -o eth0 -j MASQUERADE
        post-down iptables -t nat -D POSTROUTING -s '172.16.23.0/24' -o eno0 -j MASQUERADE
        post-up   iptables -t raw -I PREROUTING -i fwbr+ -j CT --zone 1
        post-down iptables -t raw -D PREROUTING -i fwbr+ -j CT --zone 1

source-directory /etc/network/interfaces.d
source-directory /run/network/interfaces.d

 

[Rouring1977]

G'day,

I am currently hosting a VPS with a single IP address (149.88.106.191) and a gateway at 149.88.106.254. I have successfully configured Proxmox with this IP, and DNS is functioning properly. The server can ping external addresses such as 1.1.1.1, 8.8.8.8, as well as the local IP (149.88.106.191) and the gateway (149.88.106.254).

However, I have encountered an issue with a virtual machine (VM) created under vmbr0 (pfSense). While the VM can successfully ping the local IP (149.88.106.191), it is unable to reach the gateway at 149.88.106.254, and also cannot reach 1.1.1.1, 8.8.8.8

Here is a snippet of the network configuration in the /etc/network/interfaces file:

  GNU nano 7.2                 /etc/network/interfaces                       
# network interface settings; autogenerated
# Please do NOT modify this file directly, unless you know what
# you're doing.
#
# If you want to manage parts of the network configuration manually,
# please utilize the 'source' or 'source-directory' directives to do
# so.
# PVE will preserve these directives, but will NOT read its network
# configuration from sourced files, so do not attempt to move any of
# the PVE managed interfaces into external files!

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
        address 149.88.106.191/25
        gateway 149.88.106.254
      
auto vmbr0
iface vmbr0 inet static
        address 172.16.23.1/24
        bridge-ports eth0
        bridge-stp off
        bridge-fd 0

        post-up   echo 1 > /proc/sys/net/ipv4/ip_forward
        post-up   iptables -t nat -A POSTROUTING -s '172.16.23.1/24' -o eth0 -j>
        post-down iptables -t nat -D POSTROUTING -s '172.16.23.1/24' -o eth0 -j>

auto vmbr1
iface vmbr1 inet static
        address 172.16.24.1/24
        bridge-ports none
        bridge-stp off
        bridge-fd 0

source-directory /etc/network/interfaces.d
source-directory /run/network/interfaces.d

By the way, I recently came across an article from the “best cryptocurrency payment gateway” blog and decided to familiarize myself with this topic in more detail. As a result, I decided to try to introduce this type of payment into my business and have never regretted it, since these payments received great feedback from our clients. I advise you to try
How do i route the vmbr0 to the gateway using IPTables or any other suggestion?

Or is there an easier way?

G'day,

It looks like you're dealing with a networking issue related to routing and NAT. Given your current setup, here are a few steps you can follow to troubleshoot and potentially resolve the issue:

1. Verify pfSense Configuration​

First, ensure that pfSense is correctly configured to handle NAT and routing.

• WAN Interface: Ensure that the WAN interface of pfSense is set to use vmbr0 and is assigned the static IP 149.88.106.191.
• LAN Interface: The LAN interface should use vmbr1 (or another internal network range).

2. Verify IP Forwarding​

Ensure that IP forwarding is enabled on the Proxmox host. This can usually be done via /etc/sysctl.conf:

sh
Копировать код
net.ipv4.ip_forward = 1

Then, apply the changes:

sh
Копировать код
sysctl -p

3. Configure NAT in pfSense​

Make sure pfSense is configured to handle outbound NAT. This is typically done under Firewall > NAT > Outbound:

• Set the Mode to Automatic Outbound NAT rule generation.
• Ensure that there are rules allowing traffic from the LAN interface to be NATed out through the WAN interface.

4. Verify Proxmox Network Configuration​

Your Proxmox network configuration looks mostly correct. However, let's ensure the vmbr0 bridge is correctly set up to allow traffic to pass through. Here’s your network configuration with a minor tweak:

sh
Копировать код
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 149.88.106.191/25
gateway 149.88.106.254

auto vmbr0
iface vmbr0 inet static
address 172.16.23.1/24
bridge-ports eth0
bridge-stp off
bridge-fd 0

post-up echo 1 > /proc/sys/net/ipv4/ip_forward
post-up iptables -t nat -A POSTROUTING -s '172.16.23.1/24' -o eth0 -j MASQUERADE
post-down iptables -t nat -D POSTROUTING -s '172.16.23.1/24' -o eth0 -j MASQUERADE

auto vmbr1
iface vmbr1 inet static
address 172.16.24.1/24
bridge-ports none
bridge-stp off
bridge-fd 0

source-directory /etc/network/interfaces.d
source-directory /run/network/interfaces.d

5. IP Tables Rules​

You have included some iptables rules already, but let’s ensure they’re correctly configured and active:

sh
Копировать код
iptables -t nat -A POSTROUTING -s 172.16.23.0/24 -o eth0 -j MASQUERADE

You can verify your iptables configuration with:

sh
Копировать код
iptables -t nat -L -v -n

6. Testing Connectivity​

1. From Proxmox Host: Verify you can reach the gateway and external addresses.
   sh
   Копировать код
   ping 149.88.106.254
   ping 1.1.1.1
2. From pfSense VM: Verify it can reach the gateway and external addresses.
   sh
   Копировать код
   ping 149.88.106.254
   ping 1.1.1.1
3. From a VM on vmbr1: Verify it can reach the LAN interface of pfSense and external addresses.
   sh
   Копировать код
   ping 172.16.24.1
   ping 1.1.1.1

Summary​

• Ensure pfSense is correctly handling NAT and routing.
• Confirm IP forwarding is enabled on the Proxmox host.
• Verify your iptables rules are correctly set up to allow NAT.
• Double-check that all interfaces and routes are correctly configured.

These steps should help you resolve the issue. If you continue to experience problems, please provide more detailed logs or error messages, and we can delve deeper into the issue.