OpnSense not getting WAN IP from modem

[ajeun]

Hi, posting to ask for help. I've been reading a bunch of different posts and trying different configurations without any success. I'm trying to setup my proxmox node to run OpnSense as a VM and use it as router and firewall. The main problem is that the WAN does not assign an IP from my modem Arris SB6190 using Comcast internet.

Here are a bunch of things I've tried:

• Connecting my computer directly to the modem works fine, or connecting through a dumb switch works too. The computer gets a public IP address (comcast ip space).
• I've tried quickly changing different directly connected devices and it works fine so I don't think the MAC address is sticky.
• I've tried assigning an IP address to the proxmox vmbr1 connection. I am able to reach the internet from proxmox host if I do that. Pinging the modem 192.168.100.1 or the comcast upstream gateway 73.140.226.1 from proxmox works, but OpnSense still does NOT work.
• Connecting my computer and the modem to an easy managed switch TL-SG1016PE does NOT work.
• Rebooting the modem, does NOT help.
• I tried checking "Disable Gatway Monitoring" for the WAN gateway as per some other post about comcast, but that doesn't help.
• I unchecked "Block private networks" and "Block bogon networks" in OpnSense WAN interface
• Pinging the modem 192.168.100.1 or the comcast upstream gateway 73.140.226.1 from OpnSense does NOT work.
• Tried getting an IP address from my computer connected to the modem, then setting it as the static IP for OpnSense with mac mirroring. Does NOT work.
• Tried to set modem to bridge mode, but it does NOT have a setting for that.

Relevant Proxmox `ip a`:

2: enxa0cec894b02e: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr0 state UP group default qlen 1000
    link/ether xx:xx:xx:xx:b0:2e brd ff:ff:ff:ff:ff:ff
3: enxa0cec8731c07: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast master vmbr1 state DOWN group default qlen 1000
    link/ether xx:xx:xx:xx:1c:07 brd ff:ff:ff:ff:ff:ff
5: vmbr1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether xx:xx:xx:xx:1c:07 brd ff:ff:ff:ff:ff:ff
6: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether xx:xx:xx:xx:b0:2e brd ff:ff:ff:ff:ff:ff
    inet 10.0.1.3/16 scope global vmbr0
       valid_lft forever preferred_lft forever
    inet6 fe80::xx:xx:xx:b02e/64 scope link
       valid_lft forever preferred_lft forever

Proxmox /etc/network/interfaces

auto lo
iface lo inet loopback

iface enxa0cec8731c07 inet manual
#WAN

iface enxa0cec894b02e inet manual
#LAN

auto vmbr1
iface vmbr1 inet manual
        bridge-ports enxa0cec8731c07
        bridge-stp off
        bridge-fd 0
#WAN

auto vmbr0
iface vmbr0 inet static
        address 10.0.1.3
        netmask 255.255.0.0
        gateway 10.0.0.1
        dns-nameservers 10.0.0.1
        bridge-ports enxa0cec894b02e
        bridge-stp off
        bridge-fd 0
#LAN

OpnSense VM network devices:

• net0 virtio=xx:xx:xx:xx:85:2C,bridge=vmbr1,queues=4
• net1 virtio=xx:xx:xx:xx:5A:51,bridge=vmbr0,queues=4

OpnSense config:

• LAN
  • Interface xx:xx:xx:xx:5A:51
  • IP address 10.0.0.1
• WAN
  • Interface xx:xx:xx:xx:85:2C
  • Using DHCP
  • Block priovate networks unchecked
  • Block bogon networks unchecked

 

[ajeun]

Got this to work after blocking 192.168.100.1 in DHCP leases and rebooting the modem for 60s

 

[mrwizardno2]

I ran into a similar problem, but this approach didn’t solve it for me.

My modem is plugged directly into a switchport with native vlan 999 which is also tagged on the switchport and corresponding bridge my opnsense wan is linked to. OPNSense WAN is set to the TAG 999. This should work, but the modem was seeing a MAC address other than that of my OPNSense VM thanks to LLDP configured on the switchport. My provider seemingly disables and rejects the initial DHCP lease if there are multiple MAC visible to the modem. Once LLDP was disabled, no other configuration changes were necessary and this setup has worked reliably for months, surviving reboots of all gear in the network path.